7 ms·
If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong
- cperciva 17y agoI am a proud member of the doing-it-wrong society.
- Shamiq 17y agoMan, I love the banter between you and Thomas.
- ckripoff 17y agoThey ripped it off from Louis C.K. It's from his bit, "That nigger made the shit out of my coffee!" from Chewed Up.
- tptacek 17y agoAnd you deserve every picodollar you earn for doing it that way, Colin.
- notauser 17y agoThis is the same in every profession though. Once you know the rules, and the reasons behind the rules, and the consequences of breaking the rules, you can consider the trade-offs of not sticking to the rules in this specific case because it buys you some big benefits. Then, when it burns you horribly, you can write a informative blog post about why even the experts should follow the rules :-) (Btdt, although in my case it was with documented project scope. It was probably the right decision, but that didn't make taking the kicking any more fun.)
- hga 17y agoHeh; 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). 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). Final note: these protocols are fragile. If e.g. Microsoft implements Kerberos but changes one little thing without explanation, let alone a serious and public security review, don't trust it!!! - Harold, a proud member if the Do It Right Society.
- cperciva 17y agoan authentication system based on public keys (I've read they didn't get it right until the mid-80s). Make that mid-90s. How to do public key signatures wasn't really settled until Bellare and Rogaway published PSS at Eurocrypt 96.
- hga 17y agoSorry, I wasn't clear/precise, I meant an "authentication server" type protocol/system, e.g. like Kerberos.
- NateLawson 17y agoAlso, don't trust Kerberos. It was built long before things like SRP existed and hasn't caught up with the times. It hasn't fallen apart yet, but it's creaky.
- cpach 17y agoOlder HN thread for this article: http://news.ycombinator.com/item?id=639647 http://news.ycombinator.com/item?id=639647
- lr 17y agoMy answer: I'd implement a real SSO solution, like CAS: http://www.jasig.org/cas http://www.jasig.org/cas -- Open Source, started at Yale, and supported by an amazing team of people.
- tibbon 17y agoAnyone got a TL;DR version? Basically encryption isn't authentication?
- judofyr 17y agoBasically you shouldn't use a library which provides AES-support - you should use a library which provides encryption/authentication/crypo-support.
- NateLawson 17y agoYes. And cryptographers are culpable for not finishing this critical handoff by assisting in production and review of such libraries.
- sapphirecat 17y ago1: Encryption isn't magic pixie dust: people can tamper with the ciphertext and fool you. Sometimes they can even mess with the padding and decrypt the entire message. 2: A rule of thumb that falls out of this: never try to decrypt ciphertext that you can't verify is authentic. Consequence: compute the MAC over the ciphertext, not the plaintext, so you don't have to decrypt to check the MAC. I've done my message format in the past as "{version}{hmac-md5}{ciphertext}". This is suitably secure, to the best of my knowledge. And thanks to the version, it lets me alter the algorithms or keys without service disruption. Once all sessions using it would be expired, the old version can be assumed to be expired.
- NateLawson 17y agoIf the version is not covered by the HMAC, you may be subject to rollback attacks. Compare the SSLv2 and v3 protocols to see what was done to address this. Really, it's very easy to make a mistake.
- holygoat 17y agoI think this proves the point, doesn't it? :)
- jqueryin 17y agoI 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.
- msie 17y agoI agree. I found the narrative "intimidating" and stopped reading after a short while. I'm turned off by all the crypto-testosterone. :D Ah, if only I could write another Notepad and make money off that.
- dlytle 17y agoI'd say it didn't detract from the narrative; it made the narrative accessible to a different audience. The screenplay format both presented a story-based framework for understanding the progression of the argument, and humor (unicorn with laser horn) to provide a contrast to the fairly complex topic. I'm clueless when it comes to crypto, and if I were to read a very well written paper about it, I'd probably get sidetracked, or accept the conclusion without understanding the steps taken to reach it. The format of this article was perfect for driving the point (and its reasonings) home to the uneducated masses such as myself.
- DomesticMouse 17y agoIt was stupidly tl;dr. About the only audience this made it accessable to are the bored and those who like reading romance fiction.
- JimmyL 17y agoMy takeaway from the article wasn't "don't use AES" - it was "use a sufficiently high-level cryptography library such that someone smarter than you is deciding which algorithm to use and with which options".
- NateLawson 17y agoUsually people focus on "which algorithm" (you may have heard endless debates about key length) when "which options" is what actually ends up biting you. But one argument seems fun and the other mundane, so the latter doesn't get the attention it requires.
- jrussbowman 17y agoOk, 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. 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.
- mrcharles 17y agoThe real answer is that you sound like you'd benefit from reading the whole damn article.
- jrussbowman 17y agoWell, I read the entire article, and it's quite interesting that there are things like Keyczar and cryptlib out there, I still think it's a poor example. Other than a brief note on encryption does not equal authentication, they never touched on the fact that encrypting the cookie data itself isn't a real solution, as the encrypted cookie can be sniffed, and replayed to the server. So, while standard user can't hack their own cookie for escalation, they can sniff admin cookies to get that escalation. If the cookie is used for authentication or authorization, encrypting it's content is providing a false sense of security, no matter what nifty library you choose or not choose to do it with.
- zmimon 17y ago> as the encrypted cookie can be sniffed, and replayed to the server I think the whole article is premised on requiring a level of security that would presume TLS is being used.
- NateLawson 17y agoYes, the focus is on preventing cookie forgery for pre-auth account compromise or privilege escalation.
- achille 17y agoWhy encrypt the cookie at all? Why not just have server1 sign it and haver server2 verify server1's signature?
- NateLawson 17y agoThe point of the article is that some people use encryption to try to achieve authentication, which doesn't work. You're right. Signatures are appropriate for providing authentication. HMAC is a form of symmetric authentication.
- bartl 17y agoIf the idea of the article was to make me feel inadequate, it did a remarkably good job.
- NateLawson 17y agoI don't think that was the goal. This whole crusade is just to get people to realize the true cost of getting crypto right. It costs time and money to build a resilient protocol. How many person-hours went into the AES competition? What was the proportion of time spent on creating the algorithms versus analyzing them? In crypto, review costs much more than design. If you understand that tradeoff and the benefits of your own design are worth spending this effort on, congratulations, you are Qualcomm, Netscape, or Intel. All of these companies had staff cryptographers. More likely, your problem is close enough to other problems that you don't need to spend the time or money to DIY. If that path is available, take it!
- aschobel 17y agoWe use the AES cipher for user authentication, we use the Rijndael variant since we want 192-bit block size. Our userIds are 64-bit with a 128-bit secret. We generate the authentication cookie as follows: Rijandael(64-bit userId + 128-bit secret, 192-bit key) = 192-bits of cipher text If you tamper with the cipher text the 128-bit secret won't be the same. I don't see a practical cipher text tampering attack against this scheme. There are authorization issues like how do expire a specific user login.
- NateLawson 17y agoThis is a great example of warning signs. Note the number of times sizes (bits) and algorithm (AES/Rijndael) are mentioned. Note the lack of clarity in the specification (is "+" addition, XOR, or concatenation?) Note the overly-large UID space which has nothing to do with security (will you really have more than 4 billion users?) Now look at how useful this design is. You've created a single-purpose authenticator that just says "someone at some point in time has seen this exact UID/authenticator pair". All other features (expiration, privileges, source of the authenticator, version, system name the UID is for) are left out. Maybe it's "secure", but it doesn't do anything.
- fasthead 17y agoAnd your post, sire, is a great example of not understanding the intent of security. There's always a tradeoff between the requirement on the level of security and cost in implementing it. Security is a matter of tradeoff. Even with your proposed solution, there are still security breach. How does your solution handle the situation where someone hijacks the user's machine and uses his browser session? How does your solution handle the case of keylogger stealing the user's userid/password and start a valid session? See there are always ways to make any security solution fall short. The security is always a balance between a number of competing goals. If the solution satisfies the requirement, it's a sound solution.
- NateLawson 17y agoI don't understand how you get "computers are insecure" from "Arbitrary-MAC(UID) is not a useful protocol".
- joe_the_user 17y agoI love the narrative account. Making a point dramatically is great and a pseudo-mystery story is great way to talk about encryption. The narrative is right that AES is a wrong solution. But really, any encryption at all is a wrong, bass-ackwards solution to keeping the user from modifying their account information. A single cookie or argument that's a randomly generated user id with all the information server-side is much better. 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. 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.