4 ms·

I think the main problem with this scheme is encrypting without authentication. You need to authenticate the data not encrypt it! (you can use a HMAC scheme for

I think the main problem with this scheme is encrypting without authentication. You need to authenticate the data not encrypt it! (you can use a HMAC scheme for this) Encrypting is useful if you don't want clients to see the ID but that is not really a problem. For comparison Rails using the scheme by default for its session storage. http://guides.rubyonrails.org/security.html#session-storage http://guides.rubyonrails.org/security.html#session-storage Also, it is kind of pointless to have a HMAC cookie scheme and still use a database :) The point of a HMAC cookie scheme is to avoid using a database. But the problem of not rotating keys is also something that is commonly overlooked. Rails doesn't even have an option to rotate keys which is slightly annoying. It would be nice to introduce a new key without invalidating every session. For example someone might leave the company. You could introduce the new key for a day then revoke the old key which would be much more seamless [but more risky if you believe they are going to attack straight away. since they could continue to use a compromised session after the old keys have been revoked].

mgkimsal 14y ago
Good point. I may have even thought of that all those years ago, but I can't remember that far back. I eventually was just appalled that something so basic (and basically flawed) would be so sacrosanct and beyond discussion. Even after demonstrating - "look, if I have this key, I can identify as a different user" - I was essentially dismissed as a crank. At some point you get a label, and regardless of the validity of what you say, you're ignored, and that's a lesson I learned the hard way. IIRC, doing any sort of validation on the PHP side was deemed to be too computationally expensive (you know, cause it's PHP) but somehow calling a webservice over a network that then connected to a database across a network as well was somehow 'performant'. An HMAC approach on the PHP side could have been done just fine, but I think it would have left the Java guys with less control over the process (which brings up again that this was less technical and more political).
AnIrishDuck 14y ago
The biggest problem with the scheme described is what you point out: encryption is not authentication. They are designed to provide two entirely different guarantees (confidentiality vs. integrity). To provide a more concrete attack scenerio: if they used CBC encryption and stored the IV with the encrypted value (both very common practices with block cipher crypto), it would be trivial to spoof any user id by flipping IV bits. On a more general note, the main problem appears to be basic lack of cryptographic knowledge. These "experienced developers" need to buy a crypto book and read it. Talented mathematicians have already solved their "problems" with academic rigor (in this scenario, using HMAC).
- tptacek 14y ago
  Flipping bits in CBC ciphertexts works just fine without the IV.
  - AnIrishDuck 14y ago
    Right... I was assuming in this case that the message size would be < 1 block considering it's just a database id. In that case you'd have to modify the IV to flip id bits.
- benmmurphy 14y ago
  It's definitely way too easy to get crypto wrong especially if you don't have the basic cryptographic knowledge as you note. I think it is much better for developers to just try and use existing proven solutions and not try to make their own crypto solutions. I've worked on one project where it was possible to use the sessions that came with the web server (tomcat) which were implemented securely. however, instead we decided to do extra work to roll our own sessions which were implemented incorrectly using the database rand() function.

mgkimsal 14y ago

Good point. I may have even thought of that all those years ago, but I can't remember that far back. I eventually was just appalled that something so basic (and basically flawed) would be so sacrosanct and beyond discussion. Even after demonstrating - "look, if I have this key, I can identify as a different user" - I was essentially dismissed as a crank. At some point you get a label, and regardless of the validity of what you say, you're ignored, and that's a lesson I learned the hard way. IIRC, doing any sort of validation on the PHP side was deemed to be too computationally expensive (you know, cause it's PHP) but somehow calling a webservice over a network that then connected to a database across a network as well was somehow 'performant'. An HMAC approach on the PHP side could have been done just fine, but I think it would have left the Java guys with less control over the process (which brings up again that this was less technical and more political).

AnIrishDuck 14y ago

The biggest problem with the scheme described is what you point out: encryption is not authentication. They are designed to provide two entirely different guarantees (confidentiality vs. integrity). To provide a more concrete attack scenerio: if they used CBC encryption and stored the IV with the encrypted value (both very common practices with block cipher crypto), it would be trivial to spoof any user id by flipping IV bits. On a more general note, the main problem appears to be basic lack of cryptographic knowledge. These "experienced developers" need to buy a crypto book and read it. Talented mathematicians have already solved their "problems" with academic rigor (in this scenario, using HMAC).

tptacek 14y ago
Flipping bits in CBC ciphertexts works just fine without the IV.
- AnIrishDuck 14y ago
  Right... I was assuming in this case that the message size would be < 1 block considering it's just a database id. In that case you'd have to modify the IV to flip id bits.
benmmurphy 14y ago
It's definitely way too easy to get crypto wrong especially if you don't have the basic cryptographic knowledge as you note. I think it is much better for developers to just try and use existing proven solutions and not try to make their own crypto solutions. I've worked on one project where it was possible to use the sessions that came with the web server (tomcat) which were implemented securely. however, instead we decided to do extra work to roll our own sessions which were implemented incorrectly using the database rand() function.