Alice Logs in to her Bank. How does Alice" securely login to her bank?Password-based approach:Alice visits bank's Web siteAlice clicks login" and is taken to an SSL-protected pageAlice's browser sets up a server-authenticated SSL session with bankAlice enters her username and password, then c
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
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?
Alice visits bank’s Web site
Alice clicks “login” and is taken to an SSL-protected page
Alice’s browser sets up a server-authenticated SSL session with bank
Alice enters her username and password, then clicks “submit”
Bank receives Alice’s 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 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 isn’t really the bank?
What if the “browser” isn’t 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 NIST’s 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:
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 party’s identity, but does not directly verify that the party is the right one!
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 bank’s Web page
DON’T: 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 it’s used correctly
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 doesn’t mean that user has been authenticated — nor that server is authentic
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 Alice’s 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 phisher’s application gets it
User interface is a problem: passwords typically entered into phisher’s 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 Security’s CTO’s 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 doesn’t 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 user’s password
16. Contact Information Burt Kaliski Chief Scientist, RSA Security Director, RSA Laboratories +1 781 515 7073 [email protected] www.rsasecurity.com