4 ms·

It's from a database from 2012. Wasn't that cutting edge in 2012? What kind of sick shit will we be encoding our stuff 6 years from now, that bcrypt will seem l

It's from a database from 2012. Wasn't that cutting edge in 2012? What kind of sick shit will we be encoding our stuff 6 years from now, that bcrypt will seem laughably ill-suited.

meditationapp 9y ago
SHA-1 has been known to be vulnerable since 2005, and even in 2012 SHA-2 and SHA-3 were recommended. Nonetheless, you have a point!
- gruez 9y ago
  >SHA-1 has been known to be vulnerable since 2005, and even in 2012 SHA-2 and SHA-3 were recommended. FYI, the requirements for a password hash function is significantly different than for a cryptographic hash function. the vulnerabilities you're talking about doesn't affect any of those properties. password hashes only need to have preimage resistance, and (more importantly) be slow as to limit offline attacks.
  - tptacek 9y ago
    This is pretty much correct. It doesn't much matter what cryptographic hash you use to store secrets, and all of the general-purpose cryptographic hashes are bad password hashes. Salted SHA-3 would not be materially better than salted SHA-2 here.
tylersmith 9y ago
It was not at all cutting edge. In 2012 I helped a number of companies move from bcrypt to scrypt.
- pwg 9y ago
  Which is what the article says Discus did, they moved /from/ sha1 /to/ bcrypt in 2012. Same as the companies you helped, in 2012.
  - tylersmith 9y ago
    No, those companies did not use SHA1 in 2012 or any time close to then. They used bcrypt until they upgraded to scrypt. SHA1 was useless for passwords long before then.
JulianMorrison 9y ago
It was never cutting edge. It was half informed lazy coder homemade crypto in 2012. SHA1 is a fast hash. It's designed to be tractable to calculate lots of SHA1 in a small time. This is independent of whether it has collisions and is considered broken. It was fast from day 1. Fast hashes are not suitable for protecting passwords. They were never suitable for protecting passwords.
- sergiotapia 9y ago
  I can only speak to what was mainstream. In my sphere at the time SHA1 was cutting edge, most of my peers were on MD5. The best among us recommending SHA1.
  - tptacek 9y ago
    I don't want to be too much of a jerk about this because I get that this is an expert subject but if the best among you were recommending salted SHA-anything in 2012, the best among you were committing professional malpractice. Honestly, I feel like when we wrote that dumb bcrypt post in 2007, it was already a bit negligent to be using unstretched general purpose hashes for password storage. The BSD's used better hashes in the 1990s.
tptacek 9y ago
The most popular post that ever ran on Matasano's security blog was the one where I encouraged people to migrate to bcrypt. In 2007. Bcrypt, of course, is much older; Niels and David invented it as the standard password format for OpenBSD back in 1999 --- and bcrypt was a response to FreeBSD's iterated salted hash format, which also had a work factor, and is years older still. Today, in 2017, bcrypt remains a sound recommendation. You can do better, but for password databases on websites, not materially better. Salted SHA-1 hashes (salted SHA-anything hashes) were malpractice in 2012.
- sillysaurus3 9y ago
  Malpractice? Someone using SHA-1 for password storage wouldn't even be a medium severity issue on a modern pentest. I agree with you, but it was very strange to discover that password storage is basically ignored in pentests. Especially after years of you drumming it up as a big deal.
  - tptacek 9y ago
    Using SHA-1 for password storage would be sev:low in a pentest. There are a lot of other sev:low things that you would certainly agree are signs of incompetence. Unsoundness of engineering and vulnerability impact are almost orthogonal.
    - sillysaurus3 9y ago
      The issue is that companies can basically ignore sev:low findings. "Malpractice" implies that they need to care; they do not. I wish they did. It would be nice if they were forced to care. But it wouldn't block them from being declared secure by a pentest. Low-severity findings are findings, yes, but they don't have the same pull as medium or high severity vulns. All of this is true for storing passwords in plaintext, too. If some company leaked plaintext passwords, people would be outraged. Yet pentests would still give that company a pass, because plaintext password storage is sev:low.
      - 9y ago

It's from a database from 2012. Wasn't that cutting edge in 2012? What kind of sick shit will we be encoding our stuff 6 years from now, that bcrypt will seem laughably ill-suited.

meditationapp 9y ago

SHA-1 has been known to be vulnerable since 2005, and even in 2012 SHA-2 and SHA-3 were recommended. Nonetheless, you have a point!

gruez 9y ago
>SHA-1 has been known to be vulnerable since 2005, and even in 2012 SHA-2 and SHA-3 were recommended. FYI, the requirements for a password hash function is significantly different than for a cryptographic hash function. the vulnerabilities you're talking about doesn't affect any of those properties. password hashes only need to have preimage resistance, and (more importantly) be slow as to limit offline attacks.
- tptacek 9y ago
  This is pretty much correct. It doesn't much matter what cryptographic hash you use to store secrets, and all of the general-purpose cryptographic hashes are bad password hashes. Salted SHA-3 would not be materially better than salted SHA-2 here.

tylersmith 9y ago

It was not at all cutting edge. In 2012 I helped a number of companies move from bcrypt to scrypt.

pwg 9y ago
Which is what the article says Discus did, they moved /from/ sha1 /to/ bcrypt in 2012. Same as the companies you helped, in 2012.
- tylersmith 9y ago
  No, those companies did not use SHA1 in 2012 or any time close to then. They used bcrypt until they upgraded to scrypt. SHA1 was useless for passwords long before then.

JulianMorrison 9y ago

It was never cutting edge. It was half informed lazy coder homemade crypto in 2012. SHA1 is a fast hash. It's designed to be tractable to calculate lots of SHA1 in a small time. This is independent of whether it has collisions and is considered broken. It was fast from day 1. Fast hashes are not suitable for protecting passwords. They were never suitable for protecting passwords.

sergiotapia 9y ago
I can only speak to what was mainstream. In my sphere at the time SHA1 was cutting edge, most of my peers were on MD5. The best among us recommending SHA1.
- tptacek 9y ago
  I don't want to be too much of a jerk about this because I get that this is an expert subject but if the best among you were recommending salted SHA-anything in 2012, the best among you were committing professional malpractice. Honestly, I feel like when we wrote that dumb bcrypt post in 2007, it was already a bit negligent to be using unstretched general purpose hashes for password storage. The BSD's used better hashes in the 1990s.

tptacek 9y ago

The most popular post that ever ran on Matasano's security blog was the one where I encouraged people to migrate to bcrypt. In 2007. Bcrypt, of course, is much older; Niels and David invented it as the standard password format for OpenBSD back in 1999 --- and bcrypt was a response to FreeBSD's iterated salted hash format, which also had a work factor, and is years older still. Today, in 2017, bcrypt remains a sound recommendation. You can do better, but for password databases on websites, not materially better. Salted SHA-1 hashes (salted SHA-anything hashes) were malpractice in 2012.

sillysaurus3 9y ago
Malpractice? Someone using SHA-1 for password storage wouldn't even be a medium severity issue on a modern pentest. I agree with you, but it was very strange to discover that password storage is basically ignored in pentests. Especially after years of you drumming it up as a big deal.
- tptacek 9y ago
  Using SHA-1 for password storage would be sev:low in a pentest. There are a lot of other sev:low things that you would certainly agree are signs of incompetence. Unsoundness of engineering and vulnerability impact are almost orthogonal.
  - sillysaurus3 9y ago
    The issue is that companies can basically ignore sev:low findings. "Malpractice" implies that they need to care; they do not. I wish they did. It would be nice if they were forced to care. But it wouldn't block them from being declared secure by a pentest. Low-severity findings are findings, yes, but they don't have the same pull as medium or high severity vulns. All of this is true for storing passwords in plaintext, too. If some company leaked plaintext passwords, people would be outraged. Yet pentests would still give that company a pass, because plaintext password storage is sev:low.
    - 9y ago