On the Evolution of Authentication Factors

1
On the Evolution of Authentication Factors

• Moti Yung, Columbia University

2
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).
  

3
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

4
These Factors

• Are in all security textbooks
• Students If you want to learn security, be
  suspicious of textbook and of common beliefs.

5
Observe!!

• All the factors are bilateral (usersystem)
• Observe No other parties are involved.. !!!!
• Were identified in the time of time-sharing
  machines when IT security notions were developed
  (red books, etc.)

6
Time-sharing stand alone Computers vs. The
Internet

• But. in modern computing environment the user is
  rarely alone (user and PC). There is Internet of
  people and machines around!
  
• Can we use this fact?

7
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.
  

8
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 complete fraud elimination
  necessarily (5) users are not the most trusted
  entity.

9
User Authentication Model
User
Agent
Resource
Evidence
Auth.Protocol
Auth. Factors

• Forward Authentication Steps
• User and Users Devices present Evidence to
  Agent demonstrating possession of Authentication
  Factors
  
• Agent conveys Evidence to Resource in
  Authentication Protocol
  
• ? Many Players in the game !!!

Users Devices
10
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

11
In This Talk

• I will briefly 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

12
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
  

13
Underlying Idea

• Many ways to authenticate the
• users computing environment,
• user, knowledge of the user
• User mobile device, etc.
• NAMELY The modern environment (machines and
  software) can possess factors!
  
• Users computer IP address/ A cookie in browser
  as examples
  
• If not the usual IP address then extra
  authentication (call the users mobile phone)
  security as needed not as an over-kill.
  

14
This means

• Basic Design Point If a user gave away his/ her
  usual credentials like password, account number
  and all details to a Phishing email attack in an
  attackers Phishing site
• Then Still, the security is not lost against
  off-line Phishers which are the majority (only
  man in the middle remains and needs more
  efforts). The computing environment factors do
  not change!!

15
Have systems that

• 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...
  
• Build other security issues (risk assessment) on
  this basic fact.
  
• The ideas are also usable ? commercial success
  and acceptability
  

16
Second Scenario

• User in an organization a company where users
  are in groups, and there is well defined
  relationships among users (organizational chart).

17
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!
  
• Overall system needs flexibility!

18
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
  

19
Social Relationships and Authentication

• Break also here the bilateral constraint at the
  very basic factor level!
  
• Relying on Somebody You Know isan age-old
  mechanism for humanity (people used introduction
  letters in old times), a relatively new tool for
  user authentication (PGP) .

20
Steps

• We Formalize a simple Model for claiming
  correctness/ security of authentication
  ceremonies
  
• It has helped in verifying and defining the
  goals, and reviewing the design of the protocol
  and assumptions about components

21
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

22
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

23
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.
• There are various steps registration of helpers,
  helping scenario (separated from usual
  authentication) vouching for a user, user log in
  via the help, etc.

24
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.
  

25
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
  
• We also examined properties of actual channels
  of auth. Beyond the formal model to deal with
  further user guidance issues..
  

26
Conclusions

• Reviewed non-bilateral factors of authentication
  available in modern settings
  
• Presented idea of a model for passive factors
• Designed vouching tool for emergencies
• Show how this comes from a new look at factors
  in modern settings
  
• Security Design/ Validation (1) formally and
  carefully in the model getting what we need to
  achieve (using probability), and (2) further
  issues in the systems setting (components are not
  perfect)

27
Conclusions II

• Extensions of both passive 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) especially as
  the computing environment changes.

28
Thank you!
29
BACKUP SLIDES

30
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)

31
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.
  

32
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).

33
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
  

34
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.

35
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 Alices own
  computer.
  

36
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).

37
Continuation

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

38
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)

39
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

40
Pragmatic Considerations

• - Investigated pragmatic channels for delivery of
  requests/ codes e.g., how to discourage the
  helper from using the users machine in the
  session! (keyboard-logger on user machine can get
  helpers 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 users
  real name)

41
Even Further Voucher Demo

• Simple Web-based Application
• Performed also usability study with 12 users.