Authentication in Modern Computing Environments

Moti Yung, Columbia University

Authentication

• We have been very successful in Cryptography in designing authentication– Kerberos: building on the NS model– IPSEC building on various authentication

protocol works (I had some contributions in Crypto 90 paper)

– SSL/TLS (I had some contributions suggesting the server only public key model in Crypto 85)

User Authentication starts at the User

• While, IPSEC, SSL/TLS, etc. are major authentication tools, in reality, user authentication starts at the user level (web computing, user sign-on, etc.). Thus, PASSWORD is the most prevalent tool….

• Many issues in authentication are open and simple concepts have been left out and ignore advancements in computing environments.

• Phishing for example, exploits the look-alike of a phishing site and original bank site (uses social engineering).

The Three Traditional Factors & Evidence in Authentication

• Something you know:– Password / PIN– Knowledge-based authentication

Answer

• Something you have:– One-time password token– Smart card / USB token Signature/ mobile

phone

• Something you are / can do:– Biometrics: Fingerprints, voice

Observe!!

• All the factors are bilateral (user—system)

• Observe: No other parties are involved….. !!!!

• But in modern computing environment the user is rarely alone (user and PC). There is Internet of people and machines around!

• Fundamental Issue: Can we use this fact?

What we Claim

• The 3-factor is based on bilateral relationships typical of time-sharing machines

• In modern Internet time we can exploit other computing devices and users in designing factors.

From FFIEC 2005 Guidelines:

• Regarding user authentication:• "The agencies consider single-factor

authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.”

Password Not Enough

• US Government asked for compliance by year-end 2006

• US banks were required to enhance one-factor authentication.

Authentication in real life comes in many shapes and

forms……• User Type (enterprise employee, client) –

flexibility, usability• System Setting (internal, open commerce,

Internet banking)• Type of Action (Financial/ non-financial/

Financial value)• Parties Trust relationships [I am not even

talking about two-way auth., phishing, etc.]

ISSUES

• Most authentication issues are a result of: (1) poor computing and networking infrastructure that has no security; (2) ultimate solutions are costly; (3) usability and business needs are not necessarily security-friendly; (4) financial transactions are controlled by “risk management” not elimination of all fraud; (5) users are not the most trusted “entity.”

User Authentication Model

User Agent Resource

User’s Devices

Auth. Factors

Evidence

Auth.Protocol

Forward Authentication Steps

• User and User’s Devices present Evidence to Agent demonstrating possession of Authentication Factors

• Agent conveys Evidence to Resource in Authentication Protocol

Variations on the Model• Local authentication: User authenticates directly

to resource, without agent– e.g.: Log into PC; Unlock smart card

• Authentication server: User authenticates once to authentication server, which relays ticket or authentication assertion to resource– e.g.: Kerberos; Identity providers

• Validation server: Resource relies on separate validation server for part or all of authentication– e.g.: Credential federation

Describing an Authentication Mechanism

• An authentication mechanism is a ceremony* involving:– Selected authentication factors– Particular evidence about those factors;

and a– Specific protocol for conveying the

evidence

“Ceremony” by Carl Ellison / Jesse Walker protocol model involving human users, their systems, machines, etc. .

In This Talk

• I will cover two scenarios: – User of on-line banking with no special

authentication device (no smartcard, usb token, etc.)

– User in an organization with a separate hardware token that lost/ forgot the token

Casual User: a client of a bank

• Financial Institutes have consumer who engage in transactions

• Consumer usage of hardware tokens/ smartcards in their many banks is a problem (in the US market and others, less of a problem in Asia)

• Not all transactions need high level of authentication

Idea

• Many ways to authenticate the – user’s computing environment, – user, knowledge of the user– User mobile device, etc.

• User’s computer IP address/ A cookie in browser as examples

• If not the usual IP address then extra auth: call the user’s mobile phone, or ask him from a list of questions.

This means

• If a user gave away his/ her usual credentials like password, account number and all details to a Phishing email attack in an attacker’s Phishing site…

• Then: Still, the security is not lost for off-line Phishers (only “man in the middle” remains and needs more efforts)

Approach:

• Increase Authentication Factors (using the computing environment, knowledge about user) for flexibility and usability and minimizing extra efforts of consumers– in particular no need for hardware token devices etc. USE PASSIVE FACTORS of the environment

• Now collecting credentials by faked sites (regular phishing) may not be enough for attackers and they will attack elsewhere...

Second Idea

• Connect authentication method to risk-value of the transaction based on model of fraud (adaptive authentication). Use more authentication factors as needed.

• This will balance the needs of authentication against usability and will make reactive authentication based on risk level as the bank manages it.

Possible Approach I• Risk Assessment Tool to:

– Monitor Transactions– Keep track of bad transaction– Run a model of transactions performed by

fraudster (from various sources) and “learn” their behavior as in anti-fraud systems in general

Possible Approach II

• Authentication Tool– Assess a given transaction against model

and determine level of risk– Based on risk decide: let transaction go on

or invoke extra authentication methods

• Overseeing Tool: – Coordinate actions across different locations,

from different sources (global effort)

Overall secure the user

• Based on PC device and user profile, assesses risk of all transactions and invokes additional authentication for risky transactions. Invisible to majority of users most of the time…

• Above is increased by action based on “learned fraud pattern.”

• This tools and methods are employed in industry (RSA is a leader in this space)

What is achieved

• New methods to assess risk in transactions • It is working in a world of active and adaptive

attackers• It requires constant learning of model of

attacks/ fraud (even across various banks)• Integration of credential methods and risk

based authentication/ protection is an adaptive solution that can be merged with risk management tools.

First Scenario Morale

• Exploit user’s machines as factors

• Have graded authentication levels taking into account risk vs. applicability/usability

Second Scenario

• User in an organization: a company where users are in groups, and there is well defined relationships among users (organizational chart). [Based on paper published in ACM’s CCS 2006]

Primary vs. Secondary Methods

• Credentials or credential processing unit may not be available

- our motivating example: user forgets her authentication token, or the biometrics reader is out of service…

• Users need an a backup alternative to log into the machine: productivity and usability may be more important than security alone!

Backup Methods• Common Alternatives

- E-mail: (the security relies on email security an having an alternative account)

- Life questions: (security in answer entropy, over time degradation)

- In an enterprise: call a help-desk (social engineering backdoor) typically the user and the help-desk operator “do not know each other”…

Social Relationships and Authentication

• Break also here the bilateral constraint at the very basic “factor level”!

• Relying on “Somebody You Know” is…an age-old mechanism for humanity (people used introduction letters in old times), a relatively new tool for user authentication ….

Further…

The notion has been used to rely on other credentials based on human relationships:

- Credentials are trusted (in PGP SPKI/SDSI PKI’s (relying on web of trust), Trust Management Systems and reputation systems based on social relationships

- Here: How to employ the notion as a factor by itself (formalize the notion and employ in ceremonies)

Steps I

• We Formalize a Model for claiming correctness and security of authentication ceremonies, based on simple probabilistic assumptions about the ability of Entities to present Factors. The model use simple probabilistic assertions

• It has helped in verifying and defining the goals, and reviewing the design of the protocol and assumptions about components

Steps II

• Our goal was exploiting social relationship in a simple, usable way, so we designed and implemented (assuming formal properties of communication channels)

• We then look at systems and attack variations beyond the formal model, to assure the factor has right properties for deployment in an extended systems setting

Basic Idea: Voucher Systems

• Users authenticate themselves to the system via a ceremony session where they simply present their factors:

-- Example: User presents password and,

for example, a token-code: the one-time value for evidence that his token (device) outputs for the session [but can also be a signature from his USB token]

Basic Idea: Voucher Systems (ii)

• If a user does not have his token (device), then there are pre-assigned group of other users who may vouch for that user. Namely, there is an alternative ceremony by which a user contacts a “helper” who interacts with the system and aid the user in its authentication.

Define properties

• Correctness and Security properties will be derived from differences between the probability of the “correct claiming by presenting a factor” [X(x)] and that of an impersonation attempt, namely [X(y), where y is not x].

• Correctness defines the fact that a honest entity can claim its own identity at all times with very high probability (1-epsilon)

Security Properties

• We assume the system tries to prevent impersonation with some high probability.

• We also assume independent logging/ audit trails (not under the user control) and thus detection of small probability bad events is possible.

The properties

• Formalizing the events, probabilities, interactions, system components and ceremony actions we now realized that “Security” has to do with two properties:

• Prevention: Impersonation (by dishonest parties) has low probability from basic assumptions about factors and success of events.

• Detection: If the low probability event do occur, the log reveals it if checked w.v.h. probability.

Voucher System

• We have users presenting passwords and token-codes as the basic factors in their primary authentication sessions

• If token device is not available, we allow users to get helped by other users vouching for them

(I will not further use the formal notation, if interested see the paper…)

Voucher System: Enrollment

• For a vouching to take place, the helper Harry has to establish relationships with the user Alice, thus there is an enrollment process where “Harry meets Alice”…. and the mechanisms/ policy by which help will be asked are established as well (i.e., Alice may call Harry from her office phone or mobile phone).

Rules

• Which users can help whom is a system policy (in an enterprise it can use the organizational chart to determine the relation).

• Users are carefully notified of their responsibilities (e.g., getting an independent email from the system) and the policy regarding vouching: e.g., “You must identify by phone the voice of the user asking for help and verify the caller id”..

• Policy is driven by probability of identification

Voucher System Ceremony:

• 1. Alice Contacts Harry: out-of-band call, say, asking for help

• 2. Harry authenticates Alice: verifying her identity (system must assure the method gives high enough probability p1)

• 3. Harry authenticates to the System: Using a specific and separate authentication session where he is designated as a helper.

Continuation:

• 4. Harry obtains a “Vouch-code”: the system verifies that Harry and Alice are indeed a designated helper-user pair, if so a user specific large enough value is given as a vouch-code (so it is hard to guess, only with a small probability p2)

• 5. Vouch-code is delivered to Alice• 6. Alice enters vouch-code: It is delivered to the

system in a session from Alice’s own computer.

Voucher System (cont.)• 7. System authenticates Alice: Checks the factors

(e.g., password), and checks the vouch-code against a database of recently issued codes.

• 8. Alice chooses Temporary Password: If step 7 is successful the system accepts from Alice a temporary password, to be useful for the day, say (this neutralizes the fact that Harry knows the vouch-code, and makes it easier for Alice to sign on during the day based on memorizable value).

Continuation

• 9. Logging: Events are audited (audit is available and under the system’s control) and notifications are sent to involved parties.

What is achieved:• We show correctness• We show Security (low probability of

impersonation based on basic probability of getting the token code, vouch-code, and password), considering all attacks we extracted from the system and its structure: -- Outsider, --Unregistered Helper, --Helper against User, and --User against Helper

• We show detection of all bad (low prob.) events in the logs.

Note:

• The formal tools were used to reflect carefully on requirements, assumptions, needs and design decisions (interactive design and analysis, moving between protocol and claims…). The final claims of properties validates the design under the assumptions (see the paper…)

Further: Pragmatic Considerations Beyond the

Model• Always in design of systems there is

residual analysis left due to the gap between the formal setting and the deployment setting since the model only captures part of the actual setting; we considered such issues here:

Pragmatic Considerations

• - Investigated pragmatic channels for delivery of requests/ codes: e.g., how to discourage the helper from using the user’s machine in the session! (keyboard-logger on user machine can get helper’s password!)

• Social engineering issues: e.g., how to design the system so that undesirable channels are not easy to employ (asking for help over a gmail account on something that looks like the user’s real name…)

Even Further: Voucher Demo• Simple Web-based Application• Performed also usability study with

12 users.

Second Scenario Morale

• Exploit multi-user relationships for authentication

• Have backup methods since authentication is not a goal but rather a means.

Conclusions• Formally looked at non-bilateral factors of

authentication

• Demonstrated using passive factors of computer, mobile phone, etc. and also introduced the notion of “vouching” in user authentication, again breaking the strictly bilateral nature of authentication factors

• Designed simple working tools for “risk based authentication” by mixing factors

• Designed vouching tool for emergencies

Conclusions II

• Security considerations: formally and carefully in the model getting what we need to achieve (using probability), and further issues in the systems setting (where components are not “perfect”)

• Extensions of both risk-based authentication and vouching are possible , e.g., in a vouchcode or risk-level mode where user gets restricted privileges, richer policy……

• Further exploiting the notions and the tools is open…. • Morale: Always room to think about new simple yet

highly effective issues, concepts and solutions (non bilateral factors in this case and their analysis for a specific factor…)

Further

• As computing environment evolve we cannot and should not stick by old paradigms (here: that there are three basic factors)

• When looking beyond bilateral relationships there are plenty more factors.

Thank you!