Authentication: Risk vs. Readiness, Challenges & Solution - PowerPoint PPT Presentation

Loading...

PPT – Authentication: Risk vs. Readiness, Challenges & Solution PowerPoint presentation | free to view - id: 3e6961-NTQ5Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Authentication: Risk vs. Readiness, Challenges & Solution

Description:

Authentication: Risk vs. Readiness, Challenges & Solutions Burt Kaliski, RSA Security BITS Protecting the Core Forum, October 6, 2004 Alice Logs in to her Bank How ... – PowerPoint PPT presentation

Number of Views:23
Avg rating:3.0/5.0
Slides: 17
Provided by: rsaComrsa3
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com