Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use an HMAC, not a simple MD5 hash #3

Open
codahale opened this issue Sep 29, 2013 · 3 comments
Open

Use an HMAC, not a simple MD5 hash #3

codahale opened this issue Sep 29, 2013 · 3 comments

Comments

@codahale
Copy link

The code, as-is, simply generates an MD5 hash of the data, which is trivially forgeable by an attacker.

Because the authenticity of the session cookie is not guaranteed, the CBC encryption used by this module is vulnerable to padding oracle attacks, which can trivially recover the plaintext of a session cookie.

You should:

  1. Use an HMAC construction, not a simple MD5 hash. OpenSSL provides this.
  2. Use a different key than the key used for encryption.
  3. Create an HMAC of the encrypted data, not of the plaintext.
  4. Use a constant-time comparison algorithm when validating the HMAC to avoid timing attacks.

(Or use an authenticated AES mode like GCM, but this will require OpenSSL 1.0.1+.)

For more details, please see Moxie's blog post on the 'doom principle'.

@agentzh
Copy link
Member

agentzh commented Sep 29, 2013

@codahale Recovering the clear text of the encrypted session here does not matter. Basically the user should only put a user ID, a number, into it. The user should never put a password or something like that into the encrypted session. What matters here is to avoid faking valid encrypted sessions from arbitrary clear text on the attacker side.

And yeah we can always make the current encryption method stronger :)

@codahale
Copy link
Author

Believe me, I understand that, but the module as it exists uses literally none of the cryptographic primitives for providing authentication. You're hoping that CBC mode's confidentiality guarantees are sufficient, which they most certainly aren't.

The fact that session cookies are malleable means there are a variety of adaptive chosen-ciphertext attacks which would allow attackers to take advantage of everyday program features to forge session cookies (e.g., Passki & Ritter's separator oracle).

The fact that the MD5 hash is both completely unauthenticated and of the plaintext data gives attackers an advantage in that they can, after using Vaudenay's adaptive chosen-plaintext attack to decode the contents of their non-admin session cookie, determine the appropriate plaintext for an admin session cookie and know that their forged session cookie works when it passes the MD5 check.

Also, I'm not even a cryptographer. I'm just a guy who's read a few books and was walking past this repo when I got curious. An actual cryptographer—white or black hat—would be able to really dig into this stuff.

Thankfully, the solution here is pretty straight-forward, as I pointed out above.

@agentzh
Copy link
Member

agentzh commented Sep 29, 2013

@codahale Thank you for the info! I'll look into this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants