Authentication: Risk vs. Readiness,  Challenges  Solutions

Authentication: Risk vs. Readiness, Challenges Solutions PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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 Presentation

Authentication: Risk vs. Readiness, Challenges Solutions

An Image/Link below is provided (as is) to download presentation

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

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 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 … 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: 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 party’s 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 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 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 doesn’t 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 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]

  • Login