3 ms·

> NEVER hash passwords with MD5/SHA-1/Hash-of-the-day > PHPass will make life easy for yourself and keep your users' passwords secure. MD5/3DES/SHA-1 are rela

> NEVER hash passwords with MD5/SHA-1/Hash-of-the-day > PHPass will make life easy for yourself and keep your users' passwords secure. MD5/3DES/SHA-1 are relatively broken. But saying "use this magical library" is really far from a solution. Who's to say that that library won't be broken tomorrow and then someone else won't write an article next week saying "don't use PHPass!" Programmers just need to stay up-to-date with the latest trends and adjust their approaches accordingly. > MD5/SHA-1/Hash-of-the-day is not, was not, and never will be acceptable. MD5 was very much acceptable for the longest time. Back when everyone was using 3DES, MD5 was seen as the Bcrypt of the time. So saying that it "never was acceptable" is simply nonsense. It was even what was implemented by the standard libraries and APIs of the time.

chacham15 14y ago
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-linkedins-new-salted-hashes-useless http://www.itworld.com/security/280813/expert-calls-linkedin...
- UnoriginalGuy 14y ago
  > 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!"
  - rmrfrmrf 14y ago
    > "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.
  - Piskvorrr 14y ago
    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.)
Dylan16807 14y ago
MD5 for password storage isn't broken. It's still incomparably better than encrypting passwords. The problem is that it requires you to have a very strong password to start out with. This is 'acceptable' in that the security works with MD5, but 'unacceptable' in that it makes security much harder than it should be for no benefit. And it has always been this way, regardless of what people have thought about it in the past. That's the benefit of hindsight. Nothing has actually changed MD5's security. Finding a broken library is a completely different and more easily fixed issue.
- Joeri 14y ago
  Hashcat can do 5 billion md5 hashes per second on a single gpu. Even difficult passwords are crackable in md5.
  - Dylan16807 14y ago
    Adding six lowercase characters/numbers increases the difficulty by a factor of a billion. So if you look at a typical 8 character rule and go up to 14 random characters you're perfectly safe on md5.
    - Piskvorrr 13y ago
      ...which, sadly, will lead to a proliferation of yellow stickies. Depending on the physical security of the individual workstation, this may not necessarily be a bad thing (but in the most common case "anyone has physical access" probably will be)
thaumaturgy 14y ago
You're right that today's algorithms or libraries might be broken at some distant point in the future, but I don't see how that would change today's recommendations. Today's best practices are the same regardless of what will happen in ten years. When something better comes along, then people should move to that; until then, PHPass and bcrypt are reasonable suggestions. > But saying "use this magical library" is really far from a solution. PHPass is managed by OpenWall. They're some pretty smart people. The only niggle I can think of with PHPass is that they read from /dev/urandom without trying /dev/random; theoretically /dev/urandom is unsuitable for cryptographic applications, but using /dev/random is tricky and error-prone, especially in VPS environments. (You can install haveged on Debian to feed /dev/random if you're interested in that sort of thing.) Given the choice between using OpenWall's PHPass bcrypt implementation or rolling my own, I'd use theirs without a doubt. What alternative would you suggest? > MD5 was very much acceptable for the longest time. Back when everyone was using 3DES, MD5 was seen as the Bcrypt of the time. So saying that it "never was acceptable" is simply nonsense. True, but sort of pointless. My best recollection is that MD5 was last considered OK back in 1997 or thereabouts, but I might have early-onset alzheimer's or something.

chacham15 14y ago

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-linkedins-new-salted-hashes-useless http://www.itworld.com/security/280813/expert-calls-linkedin...

UnoriginalGuy 14y ago
> 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!"
- rmrfrmrf 14y ago
  > "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.
- Piskvorrr 14y ago
  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.)

Dylan16807 14y ago

MD5 for password storage isn't broken. It's still incomparably better than encrypting passwords. The problem is that it requires you to have a very strong password to start out with. This is 'acceptable' in that the security works with MD5, but 'unacceptable' in that it makes security much harder than it should be for no benefit. And it has always been this way, regardless of what people have thought about it in the past. That's the benefit of hindsight. Nothing has actually changed MD5's security. Finding a broken library is a completely different and more easily fixed issue.

Joeri 14y ago
Hashcat can do 5 billion md5 hashes per second on a single gpu. Even difficult passwords are crackable in md5.
- Dylan16807 14y ago
  Adding six lowercase characters/numbers increases the difficulty by a factor of a billion. So if you look at a typical 8 character rule and go up to 14 random characters you're perfectly safe on md5.
  - Piskvorrr 13y ago
    ...which, sadly, will lead to a proliferation of yellow stickies. Depending on the physical security of the individual workstation, this may not necessarily be a bad thing (but in the most common case "anyone has physical access" probably will be)

thaumaturgy 14y ago

You're right that today's algorithms or libraries might be broken at some distant point in the future, but I don't see how that would change today's recommendations. Today's best practices are the same regardless of what will happen in ten years. When something better comes along, then people should move to that; until then, PHPass and bcrypt are reasonable suggestions. > But saying "use this magical library" is really far from a solution. PHPass is managed by OpenWall. They're some pretty smart people. The only niggle I can think of with PHPass is that they read from /dev/urandom without trying /dev/random; theoretically /dev/urandom is unsuitable for cryptographic applications, but using /dev/random is tricky and error-prone, especially in VPS environments. (You can install haveged on Debian to feed /dev/random if you're interested in that sort of thing.) Given the choice between using OpenWall's PHPass bcrypt implementation or rolling my own, I'd use theirs without a doubt. What alternative would you suggest? > MD5 was very much acceptable for the longest time. Back when everyone was using 3DES, MD5 was seen as the Bcrypt of the time. So saying that it "never was acceptable" is simply nonsense. True, but sort of pointless. My best recollection is that MD5 was last considered OK back in 1997 or thereabouts, but I might have early-onset alzheimer's or something.