1 / 15

One-way Authentication and Client Authentication on the Web

This lecture covers topics such as one-way authentication, mutual authentication, encrypt-then-MAC approach, and client authentication on the web using cookies. It also discusses the dos and don'ts of client authentication and provides security hints for implementing secure authentication schemes.

jcabrera
Download Presentation

One-way Authentication and Client Authentication on the Web

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMSC 414Computer and Network SecurityLecture 18 Jonathan Katz

  2. One-way authentication • If only the server has a known public key (e.g., SSL) • Server sends R • Client sends Epk(R, password, session-key) • Insecure in general!!! • But secure if encryption scheme is chosen appropriately • Can extend to give mutual authentication

  3. Authenticated Diffie-Hellman • Add signatures/MACs and nonces to Diffie-Hellman protocol • Note: achieves forward secrecy • What if we had used encryption instead?

  4. Using session keys • Generally, want to provide both secrecy and integrity for subsequent conversation • Use encrypt-then-MAC • Use sequence numbers to prevent replay attacks • Use a directionality bit • Periodically refresh the session key

  5. “Dos and Don’ts of Client Authentication on the Web” (Fu, et al.)

  6. Authentication using “cookies” • “Single sign-on” for users accessing a site • Full-fledged key-exchange not practical due to limited client (and server!) computation • No public keys, no third parties… • Idea: use “authenticators” stored as cookies • No client-side computation at all • But…must do this securely!

  7. Minimal level of security? • Any such scheme must be secure against “interrogative attacks” • These are trivial to mount • Eavesdropping, server impersonation, and man-in-the-middle attacks are more difficult • Confidentiality is an orthogonal issue…

  8. Security “hints”… • Use appropriate amount of security • Do you need fine-grained knowledge of the user-id or not? • Is confidentiality, etc. required or not? • Use published schemes… • No security through obscurity… • Use cryptographic tools appropriately • E.g., don’t use crypt( ) as a MAC…

  9. More “hints” • Be careful of composing security schemes • E.g., using two authentication systems… • Protect user passwords • Don’t send in the clear • Don’t include in cookie • Re-authenticate before changing password • Avoid predictable session identifiers • Expiration…

  10. A simple and secure approach… • Cookie = (username/data, expiration, MAC)

  11. Mediated authentication

  12. Mediated authentication • E.g., using KDC • Simple protocol: • Alice requests to talk to Bob • KDC generates KAB and sends it to Alice and Bob, encrypted with their respective keys • Note: no authentication here, but impostor can’t determine KAB

  13. Improvement… • Have KDC send to Alice the encryption of KAB under Bob’s key • Reduces communication load on KDC • Resilient to message delays in network

  14. Needham-Schroeder • AKDC: N1, Alice, Bob • KDCA: KA(N1, Bob, KAB, ticket), where ticket = KB(KAB, Alice) • AB: ticket, KAB(N2) • BA: KAB(N2-1, N3) • AB: KAB(N3-1)

  15. Analysis? • N1 assures Alice that she is talking to KDC • Prevents key-replay, helps prevent attack when Bob’s key is compromised and then changed • Important: authenticate “Bob” in message 2, and “Alice” in ticket • Uses encryption to authenticate…  • Leads to actual flaw if, e.g., ECB mode is used! • Vulnerable if Alice’s key is compromised • Bob’s ticket is always valid • Use timestamps, or request (encrypted) nonce from Bob at the very beginning of the protocol

More Related