Authentication: Risk vs. Readiness, Challenges & Solution

1
Authentication Risk vs. Readiness, Challenges
Solutions

• Burt Kaliski, RSA Security
• BITS Protecting the Core Forum, October 6, 2004

2
Alice Logs in to her Bank

• How does Alice securely login to her bank?
• Password-based approach
• Alice visits banks Web site
• Alice clicks login and is taken to an
  SSL-protected page
• Alices browser sets up a server-authenticated
  SSL session with bank
• Alice enters her username and password, then
  clicks submit
• Bank receives Alices credentials, then
  authenticates her
• Is this secure enough? Why or why not? If not,
  how can it be made more secure?

3
The Usual Answers

• Is this secure enough?
• Maybe
• Maybe not
• Why or why not?
• Passwords are secure enough, if managed properly
  
• Passwords cannot be managed properly
• If not, how can it be made more secure?
• Strong authentication, e.g., one-time passwords,
  PKI tokens
• these are Levels 3 and 4 of NIST SP 800-63
• All good answers, but this is not the whole story

4
More of the Story

• Is this secure enough?
• Maybe not, but for different reasons
• Why or why not?
• What if the Web site isnt really the bank?
• What if the browser isnt really the browser?
• If not, how can it be made more secure?
• One-time passwords, PKI tokens help
• But Alice needs more than cryptographic assurance

5
Non-Cryptographic Authentication Assurances

• NISTs SP 800-63, with its four levels of
  authentication strength, motivates the question
• What makes one authentication type stronger than
  another?
• Non-cryptographic assurances play a key role in
  three areas
• Trust decisions
• Client authentication interfaces
• Authentication success indicators
• Banks have been addressing some of these
  assurances already, e.g., through user education

6
Trust Decisions

• Authentication assures a partys identity, but
  does not directly verify that the party is the
  right one!
• Example
• Alice authenticates with a password over
  server-side SSL
• But what if server is the attacker?
• Alice will securely give away her password!
• User education is one way to develop trust
  lists, e.g.
• DO bookmark the banks Web page
• DONT click through emails claiming to be from
  the bank
• But trust lists in general are hard to manage
  properly

7
Client Authentication Interfaces

• Authentication device at client can provide
  strong authentication but only if its used
  correctly
• Example
• Alice mutually authenticates using a PKI token
• e.g., Browser obtains PIN, sends PIN to token,
  requests token to sign a protocol message
• But what if attacker has control of token
  interface?
• Attacker can perhaps cause token to sign a
  message that can be used to impersonate Alice
  elsewhere
• Virus protection, personal firewalls, PIN pads
  help, but token interface must be properly
  integrated with the actual protocol

8
Authentication Success Factors

• Authentication successful message itself
  doesnt mean that user has been authenticated
  nor that server is authentic
• Example
• Alice authenticates with challenge-response token
  over server-side SSL
• Server is the attacker, and pretends to have
  successfully authenticated her
• Alice may now be lured into revealing other
  personal data
• Authentication protocol improvements are needed
  to address these concerns particularly, better
  integration with session setup

9
Risk vs. Readiness

• Authentication approaches are readily available
  that provide reasonable non-cryptographic
  assurances in some cases
• e.g., users authenticate to trusted sites only,
  with one-time password or properly integrated PKI
• The technologies are not quite ready in others
• e.g., users authenticate to dynamically changing
  set of sites, some of which might turn out to be
  untrusted
• phishing attacks represent a growing threat
• Bottom line Substantial readiness, but
  significant risks remain

10
Conclusions

• Authentication technologies with reasonable
  assurances are available but challenges remain
• Mutual authentication needs to be integrated with
  secure session setup
• And users need a safer place from which to
  authenticate
• Is Alices login secure enough?
• Banks leadership in security, together with
  products and infrastructure improvements from the
  industry, will ensure the answer is yes without
  reservation

11
Addendum Protecting One-Time Passwords from
Real-Time Phishing Attacks

• Phishers employ online social engineering to lure
  users to reveal passwords and other sensitive
  information, exploiting one or more of the
  non-cryptographic areas above
• User education, filtering are basic
  countermeasures yet phishers may still override
  users caution and/or circumvent detection
• Phishers essentially exploit shortcomings in the
  non-cryptographic assurances discussed above
• One-time passwords, e.g., RSA SecurID, deter
  offline (phishing-net) attacks but real-time
  (phishing-line) attacks are a growing concern

12
Password Hashing

• Password can be hashed with application
  identifier to protect against reuse with a
  different application
• standard security protocol engineering
• identifier IP address, URL, public key, etc
• This can protect one-time passwords against
  real-time phishing, provided that password is
  hashed before phishers application gets it
• User interface is a problem passwords typically
  entered into phishers application like any other
  form data
• New PwdHash browser plug-in from Stanford hashes
  password field before sending but must know
  that the field has a password, and the phisher
  could circumvent the plug-in

13
Password-Protection Module

• Passwords preferably should not be treated as
  other form data, but instead entered into special
  password protection module
• User enters password into module, which hashes it
  before sending
• Since user interface can be simulated by an
  attacker, module should only be accessible via a
  reserved control sequence
• e.g., function key not available to Web
  applications
• secure attention sequence (SAS) such as
  Ctrl-Alt-Del
• The approach is a major paradigm shift for
  authentication, which would benefit the whole
  industry by giving a safe place back to the
  user from which to enter authentication data
• Joint work with Magnus Nyström, RSA Securitys
  CTOs office

14
Example User Experience

• User browses to application requesting password
• User invokes password-protection module via
  control sequence
• User enters password into module
• Module hashes password with application
  identifier
• Module provides hashed password to application
• e.g., in original form field that requested it
  from user
• Security benefit Phisher receives hashed
  password cannot directly reuse with legitimate
  application
• economically unattractive to solve for password
  by trial-and-error
• an RSA SecurID one-time password, if recovered,
  would have long expired

15
Mutual Authentication

• Hashing protects the password against misuse
  but doesnt confirm to the user that the server
  is trustworthy
• As noted above, phisher could pretend to
  authenticate user, then request other sensitive
  data
• Mutual authentication helps provide this
  assurance Password can be hashed by server in a
  different way to provide a confirmation code to
  the password-protection module
• Password protection module verifies the code and
  then indicates to the user that the server also
  knows the users password

16
Contact Information

• Burt KaliskiChief Scientist, RSA
  SecurityDirector, RSA Laboratories1 781 515
  7073bkaliski_at_rsasecurity.comwww.rsasecurity.com