Hacker News new | past | comments | ask | show | jobs | submit login

No.

>MD5 was very much acceptable for the longest time.

MD5 was never a good password hash. Neither is SHA1,256,etc. The reason is that they are crypto hashes optimized for speed. This is bad for passwords. What you should be using is the opposite: an expensive hash to compute. This is bcrypt which has been in use since 1999 (and what the PHPass is based on). This is a clear example of "Dont do your own crypto" because you dont know all the details.

>It was even what was implemented by the standard libraries and APIs of the time.

Yes, and this was a mistake. But to be fair DES used to take a full second to compute and bcrypt wasnt invented until 1999. This is why current password hashes use variable rounds so that we can increase the cost as computers get faster. When the algorithm is DESIGNED to be computed quickly it is fundamentally broken for passwords.

This is the reason that LinkedIn's passwords were vulnerable[1].

[1]http://www.itworld.com/security/280813/expert-calls-linkedin...




> MD5 was never a good password hash. Neither is SHA1,256,etc. The reason is that they are crypto hashes optimized for speed.

That's strange to hear you say that, because I remember people having huge arguments in the 1990s about how they couldn't use MD5 because it was /so/ slow and how 3DES was the only way to go!

I swear people love to re-write history.

> This is a clear example of "Dont do your own crypto" because you dont know all the details.

That doesn't even make any sense. MD5 is a standard cryptographic function. If someone had used it they wouldn't be making their own crypto.

Hell, many of the standard libraries implemented MD5 when you asked them to protect a password by default. That's so far from rolling your own it isn't even logical to try and make the argument you're making.

Your entire post reads like someone who knows nothing about the history and is just spouting "OMG USE bcrypt IT IS THE BESTEST AND WILL BE SECURE FOREVER!"

bcrypt too will fall from grace and then you'll have someone making a post like yours saying "how could anyone use bcrypt, it is SOOO fast!"


You obviously have no idea how bcrypt works; go search for "bcrypt work factor". In other words, making bcrypt slower while remaining secure is a matter of changing the work factor.

(This doesn't preclude bcrypt falling from grace for having - as of yet undiscovered - other security flaws; but it is designed with Moore's Law in mind. Saying "I don't know why everyone praises bcrypt, but HEY LOOK AT ME REBELLING, BCRYPT SUXXORZ!" is not very effective.)


> "OMG USE bcrypt IT IS THE BESTEST AND WILL BE SECURE FOREVER!"

5000 people in a room all shouting this repeatedly -- pretty much how I envision every Rails dev conference.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: