5 ms·

SHA1 hash? You’ve gotta be fucking kidding

sergiotapia 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
akeck 9y ago
In the 2007-2012 era, SHA1 was common. Also, the salts will slow down cracking a little for passwords not already known.
- tptacek 9y ago
  No, they won't.
- wolf550e 9y ago
  Nobody uses rainbow tables or cares to mitigate them. People care that GPU rigs get hundreds of billions of hashes-per-second[1] against a single-iteration salted hash. So all 8-char case-sensitive alphanumeric combinations can be checked in 18 minutes[2]. 1 - https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... 2 - (pow(26+26+10, 8) / 2*pow(10, 11)) / 60
  - akvadrako 9y ago
    If you are attacking just one password, that makes sense. But if you want to check all the compromised accounts for easy to guess passwords, a salt will increase the cost.
    - wolf550e 9y ago
      Salt won't save you. For checking most common passwords against stolen database, you try the top one million most common passwords against each hash, at a rate of 200,000 hashes per second. A dictionary-based attack that tries variants and inserts digits and spends one second per hash will catch the less common passwords.
pwg 9y ago
Significantly better than using MD5 or storing in plaintext in 2012 (both of which would have been likely in 2012). And in 2012 the current breaks from this year were not yet known. Some considered sha1 to be in its twilight, but it was not 'broken' yet at that time.
- tptacek 9y ago
  It is in fact not significantly better, for this purpose, than MD5.
  - pwg 9y ago
    That assertion is much easier to make now, with the knowledge we have in 2017, five years later. But without knowledge of what was coming for sha1 in five years, back in 2012 it would have been a much better choice than either MD5 or plaintext storage. However, even today, with the knowledge we now have regarding sha1, if ones choices are limited (for some strange reason) to only sha1 or MD5, sha1 is still a better choice than MD5. Yes, sha1 is weak, and it should clearly not be used for any new designs, but sha1 is still stronger than MD5. Also note, the 2012 date was when they last used sha1, not when they started using it. That fact is somewhat critical to keep in mind. They last used sha1 in 2012. What got leaked were some leftover hashed passwords that never got updated to bcrypt that were still hanging around in their database (probably because those accounts have never logged in for the last five years and been forced through a password change).
    - tptacek 9y ago
      No. For similar reasons, salted SHA-2 is also not materially better than MD5. You think this is about the strength of the underlying cryptographic hash, but that has in fact very little bearing on the strength of the password hash construction.
      - pwg 9y ago
        Clearly there is some critical piece of knowledge that I'm lacking, so please help me understand where my misunderstanding lies. The article announcing the breach contains the term "SHA1" in exactly two places: "passwords (hashed using SHA1 with a salt;" and "password hashing algorithm from SHA1 to bcrypt". Absent evidence to the contrary (of which the article provides no such evidence), I am reading "hashed using SHA1 with a salt" to mean they used this construction: Hp = H(S||P) or Hp = H(P||S) where: S is a salt (derivation method unstated) P is the plaintext password || is byte concatenation H( ) is a hash function (sha1 in this specific case) applied only once to the input bytes Hp is the "hashed salted password" How does the strength of the construction H(S||P) (or H(P||S)) not have a direct bearing on the strength of the chosen hash? It is nothing but the chosen hash. What am I misunderstanding here?

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

akeck 9y ago

In the 2007-2012 era, SHA1 was common. Also, the salts will slow down cracking a little for passwords not already known.

tptacek 9y ago
No, they won't.
wolf550e 9y ago
Nobody uses rainbow tables or cares to mitigate them. People care that GPU rigs get hundreds of billions of hashes-per-second[1] against a single-iteration salted hash. So all 8-char case-sensitive alphanumeric combinations can be checked in 18 minutes[2]. 1 - https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... 2 - (pow(26+26+10, 8) / 2*pow(10, 11)) / 60
- akvadrako 9y ago
  If you are attacking just one password, that makes sense. But if you want to check all the compromised accounts for easy to guess passwords, a salt will increase the cost.
  - wolf550e 9y ago
    Salt won't save you. For checking most common passwords against stolen database, you try the top one million most common passwords against each hash, at a rate of 200,000 hashes per second. A dictionary-based attack that tries variants and inserts digits and spends one second per hash will catch the less common passwords.

pwg 9y ago

Significantly better than using MD5 or storing in plaintext in 2012 (both of which would have been likely in 2012). And in 2012 the current breaks from this year were not yet known. Some considered sha1 to be in its twilight, but it was not 'broken' yet at that time.

tptacek 9y ago
It is in fact not significantly better, for this purpose, than MD5.
- pwg 9y ago
  That assertion is much easier to make now, with the knowledge we have in 2017, five years later. But without knowledge of what was coming for sha1 in five years, back in 2012 it would have been a much better choice than either MD5 or plaintext storage. However, even today, with the knowledge we now have regarding sha1, if ones choices are limited (for some strange reason) to only sha1 or MD5, sha1 is still a better choice than MD5. Yes, sha1 is weak, and it should clearly not be used for any new designs, but sha1 is still stronger than MD5. Also note, the 2012 date was when they last used sha1, not when they started using it. That fact is somewhat critical to keep in mind. They last used sha1 in 2012. What got leaked were some leftover hashed passwords that never got updated to bcrypt that were still hanging around in their database (probably because those accounts have never logged in for the last five years and been forced through a password change).
  - tptacek 9y ago
    No. For similar reasons, salted SHA-2 is also not materially better than MD5. You think this is about the strength of the underlying cryptographic hash, but that has in fact very little bearing on the strength of the password hash construction.
    - pwg 9y ago
      Clearly there is some critical piece of knowledge that I'm lacking, so please help me understand where my misunderstanding lies. The article announcing the breach contains the term "SHA1" in exactly two places: "passwords (hashed using SHA1 with a salt;" and "password hashing algorithm from SHA1 to bcrypt". Absent evidence to the contrary (of which the article provides no such evidence), I am reading "hashed using SHA1 with a salt" to mean they used this construction: Hp = H(S||P) or Hp = H(P||S) where: S is a salt (derivation method unstated) P is the plaintext password || is byte concatenation H( ) is a hash function (sha1 in this specific case) applied only once to the input bytes Hp is the "hashed salted password" How does the strength of the construction H(S||P) (or H(P||S)) not have a direct bearing on the strength of the chosen hash? It is nothing but the chosen hash. What am I misunderstanding here?