I would have much preferred if the post wasn't acted out as a narrative as it detracted from the powerful message of not using AES and why it's flawed.
I love the narrative account. Making a point dramatically is great and a pseudo-mystery story is great way to talk about encryption.<p>The narrative is right that AES is a wrong solution.<p><i>But really, any encryption</i> at all <i>is a wrong, bass-ackwards solution to keeping the user from modifying their account information.</i><p>A single cookie or argument that's a randomly generated user id with all the information server-side is much better.<p>I mean, consider any scenario where you pass the user data you'll later use. Will you not keep track of that data yourself but expect that the user's encrypted cookie will do it for you? This is one way of simulating statefulness in the stateless http protocol but it's a clearly an inferior, dumshit of doing it and it doesn't matter what encryption you use for the purpose. Giving someone encrypted information they can't use is essentially analogous to copy-protection and similar unwinnable scenarios whereas the unique id approach is pretty much the standard and works well for many, many apps of all sorts.<p>Having unique user-ids and user-information is only costly in terms of accessing the information. But there isn't a point where decrypting information coming from the user becomes less costly than getting it from the database. Indeed, the higher the traffic, the more different brute-force attacks make sense.
Ok, grant it I'm new here, and could be missing the point. I didn't actually go through the full article because I'm not really that much into crypto, and really, didn't the guy fail the interview at the point where he suggest that encryption was the answer for a cookie used for individual identification? I mean, encrypt it all you want, if I can be behind the same NAT as you, and spoof your user agent, all I need to do is get that cookie and put it in my browser, and I've stolen that session.<p>The real answer is you need to either encrypt the transport, or at the very least minimize the amount of time that cookie is valid for.
My answer: I'd implement a real SSO solution, like CAS: <a href="http://www.jasig.org/cas" rel="nofollow">http://www.jasig.org/cas</a> -- Open Source, started at Yale, and supported by an amazing team of people.
We use the AES cipher for user authentication, we use the Rijndael variant since we want 192-bit block size.<p>Our userIds are 64-bit with a 128-bit secret.<p>We generate the authentication cookie as follows:<p>Rijandael(64-bit userId + 128-bit secret, 192-bit key) = 192-bits of cipher text<p>If you tamper with the cipher text the 128-bit secret won't be the same.<p>I don't see a practical cipher text tampering attack against this scheme.<p>There are authorization issues like how do expire a specific user login.
Heh; an illustration that the real art here is in cryptographic protocols, not crypto black boxes like AES (well, as long as your "random" numbers are random enough, which turns out to be an issue in the VPS world).<p>I was lucky enough to learn this in 1979 while in a group trying to puzzle out how to make an authentication system based on public keys (I've read they didn't get it right until the mid-80s).<p>Final note: these protocols are <i>fragile</i>. If e.g. Microsoft implements Kerberos but changes one little thing without explanation, let alone a serious and public security review, <i>don't trust it</i>!!!<p>- Harold, a proud member if the Do It Right Society.