Not that it's Zed's fault that this is true†, but it's actually harder to safely host something like AUTHO.ME on a website than it is to simply use a reasonable hashing algorithm.
† I both believe this and also have to say it to avoid a sharks/jets rumble with him on HN.
I think most anyone who looks at KDFs probably both likes scrypt and also doesn't obsess too much about them. The problem with scrypt is that it doesn't have a lot of language bindings; you can get bcrypt anywhere.
Personally, I think any serious KDF is better than just using SHA1 (or SHA256, and note that the difference between SHA1 and SHA256 is not super relevant to SRP), so as long as you're doing something --- PBKDF1, PBKDF2, bcrypt, scrypt, hand-hacked 1000-iterations-of-SHA1 --- I'm happy.
1. Remove the worry of security. Look at 90% of the security/password questions on SO/reddit. Almost all the answers are SHA1+Salt.
2. Remove the resource requirement from development. Writing these things takes time and research if you don't know the proper solution. These services can reduce it to an install or a copy and paste.
3. Removing needless database structure. We manage the database (including any sort of movement or upgrading), the customer doesn't have to.
That's fair but I'm using OpenID (and developing a new Django OpenID authentication system) partially because I'm reasonably sure I've kept up with crypto best practices to store passwords safely but I'm also reasonably sure that most developers haven't. I'd rather people just use OpenID rather then fuck everything up.
Best practices for secure password storage really --- and I'm not being hyperbolic --- haven't changed much since the '90s. Poul Henning-Kamp wrote the FreeBSD MD5-based password hash and captured the main problem with secure password storage on his first try. The requirement here is not really evolving.
The reason people (mostly me, admittedly) raise such a stink about this is that using SHA1 or MD5 directly to create password hashes is SO. BAD.; it's actually worse than the original DES crypt(3) function. Web apps created a new instance of the original vulnerability, of people creating terrible new password hashes all the time that are vulnerable to problems addressed in the 1970s.
I can see why, given that stink, you might think it's hard to store passwords. bcrypt is new-ish (it's roughly a decade old), but you don't have to use bcrypt; it's just the best recommendation you can give someone starting from scratch on this problem.
Sure, but I still think you overestimate the general security knowledge of web developers. I wouldn't be terribly surprised to see that most people aren't even hashing the passwords.
I'm not worried, I was merely clarifying what the OP didn't quite understand. The article (and sentiment) is good though, and I've read it before, but apparently there's some interest in a product like Autho.me. Time will tell.
http://codahale.com/how-to-safely-store-a-password/
Not that it's Zed's fault that this is true†, but it's actually harder to safely host something like AUTHO.ME on a website than it is to simply use a reasonable hashing algorithm.
† I both believe this and also have to say it to avoid a sharks/jets rumble with him on HN.