cs161 Lecture 21: Practical Client Authentication

What's the problem?
 HTTP is stateless, so something must be presented each time: authenticator
 Can't expect computation on the client
 Why doesn't SSL solve these problems?
   SSL has certificates
    Incompatibile
    Awful user experience (which is a VERY bad thing, for security)
   Authenticator still needed because of HTTP model
   Authenticator still must be unforgeable (fatbrain)
   SSL too expensive for many sites
 Ok, use cookies and SSL (without client certs).
  Why not "user=u"? (easily forged)
  Why not "user=u&pass=p"? (cookies sit on HD, check must hit DB)
  Don't want to use SSL everywhere


Threat Model:
 Three types of attackers
   Interrogative - can only query website
   Eavesdropping - can also see others' data
   Active - can see and manipulate others' data

Usage scenarios (note the difference between whose valuable data is at risk)
 subscription (all users the same)
 configurable (users must be disambiguated)
 sensitive client data (user should make longevity decisions)

Hints
 Appropriate amount of crypto
 Do not invent (About 30% were broken)
 Do not rely on secrecy of protocol
 Understand your crypto tools
  crypt() ALMOST did the right thing
  salt was used wrong
  input truncating killed them
 Do not compose schemes (Fatbrain.  Leverage the weak to break the strong)

Being careful with authenticators
 Unforgeable (must be secret, but MAC is right)
 SSL flag
 Don't put into URLs (referrers can leak)

Security/Usability tradeoff
 Unguessable passwords: (aside: passwords are often used on multiple sites)
 Persistent/ephemeral cookies
 Longevity of authenticator
 Bind authenticator to address
 Rekey often
 Require password to change password

Cookie Recipe
 exp=t&data=s&digest=MAC_k(exp=t&data=s)
 MAC EXACTLY the first part of cookie (forces you to MAC what you mean)
 Why is exp needed? (can't trust client, also, acts as a salt)
 Why better than exp=t&data=s&digest=randomSID ? (randomSID check in DB)
 What goes in s?
  Just a unique key?
  Real info?
 Maybe extend the recipe to contain some encrypted data?


More to think about:
 Right way to mix normal/SSL
  relogin when going secure?
  use SSL to exchange user/pass, then normal for performance? (tie to IP)
 Longevity based on operation (yahoo requires relogin for checking mail)
 Constantly update authenticator, but use short expiration?
  Then attacker can keep it updated too.
  Maybe in combo with IP address check.