HTTP authentication methods

Is your API communication safe enough?

Josep Jaume Rey (@josepjaume) - Twitter, GitHub

Fact: API's are awesome

• Split responsibilities
• Escalate
• End-users can talk to your app programmatically
• [...] hope @oriolgual is gonna tell us more about this someday :)

Round 1: HTTP's basic access authentication

1. Client asks GET /secret
2. Server: 401 WWW-Authenticate: Basic realm="Codegram"
3. Client sends credendials:
   Client: basic-credentials = "Basic" SP basic-cookie basic-cookie = base64encode(username+":"+password)
4. Server returns 200 OK with the document

Wrong!

• Attacker can obtain user's plain text password
• The server must know user's password in plain text
• Replay: If intercepted, requests can be reproduced on the future
• Reflection attack: Attacker could fake server, get authorization, and fake client
• Man-in-the-middle: Attacker could fake identity and modify requests

Round 2: Use an API token in the header

1. Client asks GET /secret
2. Server: 401 WWW-Authenticate: Basic realm="Codegram"
3. Client sends credendials:
   X-AuthToken = "secret_long_string"
4. Server returns 200 OK with the document

Still Wrong!

• Attacker can obtain user's plain text password - still has access to the token
• The server must know user's password in plain text - still the token...
• Replay: If intercepted, requests can be reproduced on the future
• Reflection attack: Attacker could fake server, get authorization, and fake client
• Man-in-the-middle: Attacker could fake identity and modify requests

Round 3: Combined with SSL

Hypothesis: If the channel can be trusted, then the underlying authentication mechanism shouldn't be something to worry about.

Wronger!

• SSL Handshake is expensive
• SSL communication has a performance hit (cyphering/decyphering)
• Bloated: Certifications
• We just lost HTTP shared cache and probably client-side cache

HTTP Digest access authentication

1. Client: GET /secret
2. Server 401. sends:
• realm: Authentication domain (codegram)
• nonce (unique random value)
3. Client request:
   
   • HA1 = MD5(A1) = MD5(username:realm:password)
   • HA2 = MD5(A2) = MD5(method:URI)
   • returns: MD5(HA1:nonce:HA2), realm

4. Server can reproduce the same operations on its side.
   (it can store HA1 or MD5(password), etc - depends on the implementation)
HTTP/1.0 200 OK
next-nonce = "another nonce"

   Then, discards the nonce

Good!

• Attacker can obtain user's plain text password
• The server must know user's password in plain text
• Replay: If intercepted, requests can be reproduced on the future
• (partially) Reflection attack: Attacker could fake server, get authorization, and fake client
• Man-in-the-middle: Attacker could fake identity and modify requests

Downsides

• Client cannot pipeline requests

Extended version (qop)

Client adds these fields:

• nc = request counter (000001, 000002...)
• cnonce = Random value

Those are added in the response hash: MD5(HA1:nonce:cnonce:nc:HA2), nc, cnonce

With qop-value = auth-int it also includes a hash of the request body.

Notes

• Subsequent requests can use the same nonce but must increment nc (nonce count)
• The server must keep track of the number of uses of a nonce.

Awesome!

• Attacker can obtain user's plain text password
• The server must know user's password in plain text
• Replay: If intercepted, requests can be reproduced on the future
• Reflection attack: Attacker could fake server, get authorization, and fake client
• Man-in-the-middle: Attacker could fake identity and modify requests
• Bonus: Safe from cryptoanalysis

Downsides

• Client cannot pipeline requests

THE END

Further reading:

• Read the RFC2617 (Basic and Digest Access authentication)
• Read the RFC2617 again, bro
• For servers: Rails' built-in authentication mechanisms
• For clients: HTTParty can use digest authentication
• Your web server might not be RESTful if...