Here’s how I imagine a security troll works: Google for “md5″ or “sha1″. Look for blog posts that discuss those hashing algorithms in some security context, like storing passwords or checking file integrity. Then post a comment that’s barely more than this: “md5 is insecure!”, replacing “md5″ accordingly. Make sure to never add anything useful, like details, context or alternatives.
Pretty simple, isn’t it? So what’s wrong with just saying that “md5 is insecure”? Isn’t it true? Hasn’t md5 failed in all kinds of ways?
Sure, but does that matter? If you need a hashing algorithm to secure your root SSL certificates, yeah, don’t use md5, use a better algorithm like SHA-256 where its not as easy to produce hash collisions. If you store passwords (which you shouldn’t), use a really slow algorithm to hash the password, along with a salt, like BCrypt (more below) – Jeff also recommends this (at the end of his post).
But if all you need is a simple checksum to verify that the files you got from your FTP server aren’t corrupted by network traffic, and speed is really important, then md5 might be the right choice, as its really, really fast. Which is exactly the reason why it sucks for passwords, because you can brute force a 7 character password on a modern GPU in a few minutes.
If you’ve read this far, you hopefully don’t think that I’m anything near an authority on these questions. Yet in my experience, finding someone who really knows about this stuff and getting him to share his knowledge in a useful way is really tough. Here’s an example of that.
How To Throttle Login Attempts
Back in 2009, I posted a question on Stack Overflow about throttling login attempts. The question came up after reading another one of Jeff’s posts, which didn’t really provide any answers about properly implementing the throttling. What I was looking for, which may not have been made clear by the question, was an algorithm which would do this properly: Do you filter by user session? By IP address? A mix? A fixed increment, or an expontential one?
Basically, my assumption was: Someone must’ve implemented this before and figured out a good approach. One that holds up in a security audit. I’m fine with reimplementing the actual solution, but I really don’t want to reinvent the wheel in this security-sensitive context. Screwing it up might mean that regular users get pissed off because they get kicked out the system for a typo in their password while logging in. And with a product that is just getting started, putting security over user experience is a pretty bad deal. I’m fine with jumping through a few hoops to get into my online banking account, but logging into this random site should really be as simple as possible, as far as username/password logins go anyway.
Since I posted it, the question has got more then 3,000 views. So I’m certainly not the only one interested. Too bad there’s still no satisfying answer…
Advanced Trolling with BCrypt
I’ve mentioned BCrypt before: It’s a hash function specifically designed for passwords, and you’ll find it recommended in various places. The unfortunate aspect: The Wikipedia page on the topic is pretty thin, only providing an overview, the algorithm and implementation links, but nothing about the usage context or its limitations. In other words, if you see someone like Jeff recommending BCrypt, then try to research more about it, you almost feel like you’re getting trolled again. Why is this one function supposed to be any better than other hash functions? Why does the Java implementation include a salt generator, where the salt is stored inside the resulting hash? Are there more security issues in that implementation, like the pre-0.3 character encoding one? Without the knowledge of a cryptographer, how can we evaluate if this function is any better then md5? Here’s hoping for less security trolls, for more useful security evangelism, like OWASP is providing (even though their Password Storage Cheat Sheet mentions BCrypt only on the side).