41–50 of 144 posts
If you happen to have a web app that stores passwords in clear text or SHA-1 hashed, all is not lost. You can apply further secure hashes to the existing value stored on db and update your authentication validator.
Or invalidate and send an email.
Earlier quoted context omitted.
There are no known good implementation of scrypt in php ( http://stackoverflow.com/questions/10149554/are-there-any-ph... ) So I don't know how "production ready" that is considering php is the most popular platform for the web as much as I hate the language.
Even opting for bcrypt can be sketchy. Native support only appeared a few years ago, older versions rely on the OS - many of which didn't support blowfish without a patch. Fine if you control the server.
An even better way of securely storing your passwords would be to mix them around on entry to your bcrypt hash function in a unique way that makes it impossible to brute force your leaked password hashes without having access to the code that did them.
This only really protects against SQL injection attacks, though/when there is actually a separation between where you store the bcrypt digests and where you store the pepper. (Granted, there are a lot of SQL injection attacks.)
There are a multitude of sophisticated third-party solutions to authentication. Facebook, Twitter, and Google all offer competent solutions. Don't like those? Use BrowserID.
Integrating any of these is actually quite a bit easier than rolling your own solution. It reduces hack risk, provides a better experience for your customers (what was my password again?), and almost certainly will be more reliable than your website.
If you happen to have a web app that stores passwords in clear text or SHA-1 hashed, all is not lost. You can apply further secure hashes to the existing value stored on db and update your authentication validator.
Or do the easy thing and perform a chinese fire-drill whenever the user logs in and bump them to the new encryption schema. Or invalidate and send an email.
http://reddit.com/r/changelog/comments/lj0cb/reddit_change_p...
How about this: Don't store passwords at all. There are a multitude of sophisticated third-party solutions to authentication. Facebook, Twitter, and Google all offer competent solutions. Don't like those? Use BrowserID. Integrating any of these is actually quite a bit easier than rolling your own solution. It reduces hack risk, provides a better experience for your customers (what was my password again?), and almost…
Someone, somewhere will be storing user passwords/digests for the foreseeable future. And they will do it incorrectly.
Earlier quoted context omitted.
Or do the easy thing and perform a chinese fire-drill whenever the user logs in and bump them to the new encryption schema. Or invalidate and send an email.
Interestingly, when reddit upgraded to bcrypt, they refused to do this because so many users don't know their passwords and it would lock lots of people out of their accounts forever (remember, reddit doesn't require email addresses to register). http://reddit.com/r/changelog/comments/lj0cb/reddit_change_p...
SRP note was very nice: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol On a more esoteric note: If you are looking to resist quantum algorithms attacks, there are post-quantum algorithms for that[1] (they are computed on normal machines, but the problems behind the crypstosystems are hard to solve even for quantum computers). [1] http://crypto.stackexchange.com/questions/494/what-is-the-po...
SRP also has tunable work-factor knobs, although they aren't as explicit as the ones in bcrypt, scrypt, or PBKDF2. But I'd strongly recommend against re-implementing SRP, since it's treacherous to get right.
[With the obvious caveat: Advice not for production use, If you have to ask...]
I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…
How about this: Don't store passwords at all. There are a multitude of sophisticated third-party solutions to authentication. Facebook, Twitter, and Google all offer competent solutions. Don't like those? Use BrowserID. Integrating any of these is actually quite a bit easier than rolling your own solution. It reduces hack risk, provides a better experience for your customers (what was my password again?), and almost…
OpenID and OAuth really did a lot, but there's just nothing called "don't use passwords." Fingerprint readers suck. Anything biometric that doesn't suck costs too much, and 99% of people don't have them. A good KDF is not bad in comparison to a centralized authentication server considering other factors. Someone, somewhere will be storing user passwords/digests for the foreseeable future. And they will do it incorrec…
HN is full of web developers rolling unnecessary username/password solutions. The fact that this is such a hot issue - as opposed to esoterica like TCP frame size - shows that far too many developers are homebrewing solutions rather than outsourcing.