Web Defenses

Authentication and Session Management #

Pre-history: HTTP auth #

  • HTTP request: GET /index.html
  • HTTP response contains: WWW-Authenticate: Basic realm="Password Required"
  • Browser sends hashed password on all subsequent HTTP requests
  • Caveats:
    • User cannot log out other than by closing browser
      • What if user has multiple accounts?
    • Site cannot customize password dialog
    • Confusing dialog to users
    • Easily spoofed

Modern session management #

Login #

  • When visiting website, site creates anonymous session and hands session ID back in a cookie
  • User will POST with username and password, website checks credentials and elevates token to logged-in

Logout #

  • Delete session token from client
  • Mark session token as expired on server

Authenticating users #

  • First idea: plaintext passwords (terrible)
    • Store password and check match against user input
    • Don’t trust anything that provides you your password
  • Second idea: store password hash (bad)
    • Store SHA-1(pw) and check match against SHA-1(input)
    • Weak against attacker who has hashed common passwords
  • Third idea: store salted hash (better)
    • Store (r, SHA-1(pw + r)) and check against SHA-1(input + r)
    • Prevents attackers from precomputing password hashes
    • Need to make sure to choose a hash function that is expensive to compute
    • In practice: use bcrypt, scrypt, or pbkdf2 when building an application

Phishing attacks #

  • Attacker sends a fraudulent message that tricks user into revealing sensitive data (e.g. login, credit card)
  • Almost all take place over the web - difficult to know if you’re in the right place as a user
  • SMS-based 2-factor auth does little good; mostly protect against stolen credentials

Partial panacea: U2F and physical security keys

  • Browser malware cannot steal user credentials
  • U2F should not enable tracking across sites