OK, here's the real problem that NOBODY seems to be grasping. The point of failure is the few sites that are already storing someone's email, username, and password in plain text.
Every other site on the planet can start encrypting, using salts, hashing, etc, but the site that will be attacked is the site that emails back passwords to their users in plain text when they use the "forgot my password" page.
Why would a hacker waste their time elsewhere? They will create an account, use the "forgot" form, and if they get their password back in plain text, they know they have a target rich database.
The ONLY true form of password protection once again lies in the hands of the USER who MUST create different passwords at every site if they really want their identity protected. Sorry. If you don't know how to keep your passwords in a protected database on your PC, learn.
After all, if a hacker is already in the database stealing passwords, they've got your data too if they want it. Might as well spend your time protecting your identity elsewhere.
When I was interviewing, an applicant showed me some code that didn't hash passwords -- that's exactly what I expect in a co-op student. I think there's two problems:
-it's too easy to take sample code off the web, and it's easier to take exactly what you want rather than some general pseudo code written by BSchneier
I fail to see how the second example is more secure due to the abstraction. Simply adding a salt to the MD5 call would have around the same effect (probably that's even what Authen::Passphrase does...).
So is this a rant about abstraction or security? It is possible to make the original example safer without using abstraction. But the abstraction is important to make the applogic neater...
I feel like the author is making 2 separate points at the same time - and confusing them slightly.
There is a culture of not using libraries in PHP, because the built-in functionality is "good enough". People make the same mistakes again and again and again. (Just today there was a Rails "best practices" article saying how to roll your own salted digest authentication from scratch. WTF!?)
And anyway, I don't see a bcrypt implementation there. People will do what's easy; if it's as easy to do the (significantly more secure) bcrypt, they will. If it's easiest to do an unsalted MD5 digest, they will.
Someone certainly could write a library exactly like Authen::Passphrase for PHP or Ruby or whatever; but they haven't, so people do it wrong. They have gotten used to not having libraries, so they don't even look. (They search for blogs instead, and cut-n-paste years-old code. The culture practically insists on it.)
Still a horrible API, though. (How do you control which algorithm will be used? How do you model "this password is the lack of a password"? Etc., etc.)
My blog does not need any readers. There are no ads, and everyone that needs to know about me knows about me.
I wrote this because I think the ideas are important to share -- abstraction is critical to having secure and maintainable code, and your language choice affects how you think about problems.
Every other site on the planet can start encrypting, using salts, hashing, etc, but the site that will be attacked is the site that emails back passwords to their users in plain text when they use the "forgot my password" page.
Why would a hacker waste their time elsewhere? They will create an account, use the "forgot" form, and if they get their password back in plain text, they know they have a target rich database.
The ONLY true form of password protection once again lies in the hands of the USER who MUST create different passwords at every site if they really want their identity protected. Sorry. If you don't know how to keep your passwords in a protected database on your PC, learn.
After all, if a hacker is already in the database stealing passwords, they've got your data too if they want it. Might as well spend your time protecting your identity elsewhere.