The AES / CBC algorithm used in the cookie session store _might_ be insecure about ring HOT 3 CLOSED

My inclination in this case is not to allow customization. Rather, I think there's a benefit to focusing on having a single correct way of producing a secure cookie. This removes the possibility of creating a security vulnerability through misconfiguration.

However, as the SessionStore protocol is available, people are free to create third-party session stores using whatever encryption algorithm they wish.

from ring.

The encrypted cookie is protected by an associated SHA256 HMAC. My understanding is that this prevents a padded oracle attack, or any form of plaintext oracle attack, as an attacker cannot change the encrypted data without invalidating the associated HMAC.

from ring.

This makes sense. I'm not experienced enough in cryptography to be 100% sure, but as far as I understand this particular attack vector, yes, HMAC over the whole cookie should eliminate the risk.

I still think that it'd be nice if the middleware would allow for more flexibility in terms of cryptography used. I might be 99.99% sure that AES-CBC with HMAC is sufficient, but if given a choice, I'd happily use AES-GCM.

Other possible advantages:

• It would also allow for keys longer than 128 bits
• It would allow larger apps to use the same crypto algorithms and key infrastructure everywhere.

Would you be open to a PR that would allow for more flexibility?

Maybe a protocol like this?

(defprotocol CookieStoreEncryption
  (encrypt [key data])
  (decrypt [key data])

For backward compatibility, the current implementation would then implement this protocol. E.g. encrypt would do AES-CBC with HMAC. But it could be overwritten like:

(ring.middleware.session.cookie/cookie-store
  {:key ...some bytes...
   :encryption-impl my-own-encryption})

I'd be happy to provide a PR like this, if the approach is sound in your opinion.

from ring.