4 ms·

50% of the leaked hashes were bcrypt and the other 50% were salted sha1. So, asking the HNers who crack passwords or follow the tech closely and have a good fe

50% of the leaked hashes were bcrypt and the other 50% were salted sha1. So, asking the HNers who crack passwords or follow the tech closely and have a good feel: Salted sha1 can be brute forced much quicker, but in practical terms what kind of complexity of password is vulnerable today if it was stored salted sha1 vs bcrypt? And how can this be projected to change in the next couple of years?

cm2187 10y ago
Mostly what Troy says is that the sha1 were salted with a salt not available in the files he was provided. That doesn't mean the salt wasn't leaked. But if it wasn't, and the salt was a 128bit, unique to each password, cryptographic random salt, I'd say they are not really vulnerable. So it depends on the strength, randomness and availability of the salt.
- tonicoto 10y ago
  How come the salts aren't available? Did the attacker choose not to release them, or were they stored elsewhere?
  - Klathmon 10y ago
    Or were they really bad salts? Like a hash of the username?
    - mnw21cam 10y ago
      That wouldn't really be a proper salt, although technically it would fulfil the purpose of a salt, which is to prevent lookup tables being used.
      - Klathmon 10y ago
        Oh I agree, but I've seen too many "clever" systems which derive the salt from something like the username or another field or fields in the DB. Just because there is no obvious salt now doesn't mean it's not there. Only Dropbox knows how it worked at this point.
        tonicoto 10y ago
        We will have to wait for a code leak ;-)
    - bvinc 10y ago
      Uh oh. You might be on to something. Salts are pretty much always stored right next to the hash, right? If the hack doesn't contain them, maybe they were doing something "clever" like that.
mmaunder 10y ago
The salts for the sha1 passwords weren't leaked. So they're hard to crack in practical terms. Depends how random they were. See hashcat docs and benchmarks for complete answers to your questions. The GPU versions of hashcat.
- willvarfar 10y ago
  I actually googled before asking my question, and couldn't come up with a good feel for just how crackable these are with hashcat... I guess I don't know the terms or the prices. Is anyone able to make any sense of the GPU hashcat benchmarks that are posted? Something distilled down to "if you spend $xxx, then you can crack any salted sha1 under 12 letters+digits+punctuation in n hours if you knew the salt; if its bcrypt, that would take x hours". Something like that ;) Added: I'm a bit confused how the attackers know the hash and not the salt though; normally they are stored side-by-side. Or were dropbox using a site-wide salt? (I've seen systems with a site-wide salt hardcoded into the codebase and a per-user salt in the db with the hash; This means attackers have to compromise both sourcecode and db to get far.)
  - 8draco8 10y ago
    Hash can be stored somewhere else. I also saw systems where some kind of constant for the user was used as a salt. For example first 5 characters of username or timestamp of registration.
  - Dylan16807 10y ago
    A rough estimate for using spot instances on EC2 says you can get maybe 40 trillion SHA1 hashes per dollar. (700MH/s and just under $.07/hour) So one dollar will crack a password 7 characters long. A million dollars will crack a password 10 characters long. Switch to bcrypt and you're now at 25 million hashes per dollar on those same instances. Now you can barely crack passwords that are 4 characters long, or for a million dollars you get 7 characters. That's if you know the salt, of course. Otherwise that gets added on to the length you're cracking. None of this is very exact but it gets you in the right ballpark. And you can compare it to a password manager spitting out 20 character passwords that are completely immune to brute forcing.
viraptor 10y ago
It depends how many rounds of sha1 were used and what was the load setting on bcrypt. You can make either one harder to break by playing with those parameters.
imaginenore 10y ago
SHA1 is not necessarily weaker. They might have used many rounds of hashing, which could have made them even stronger.

cm2187 10y ago

Mostly what Troy says is that the sha1 were salted with a salt not available in the files he was provided. That doesn't mean the salt wasn't leaked. But if it wasn't, and the salt was a 128bit, unique to each password, cryptographic random salt, I'd say they are not really vulnerable. So it depends on the strength, randomness and availability of the salt.

tonicoto 10y ago
How come the salts aren't available? Did the attacker choose not to release them, or were they stored elsewhere?
- Klathmon 10y ago
  Or were they really bad salts? Like a hash of the username?
  - mnw21cam 10y ago
    That wouldn't really be a proper salt, although technically it would fulfil the purpose of a salt, which is to prevent lookup tables being used.
    - Klathmon 10y ago
      Oh I agree, but I've seen too many "clever" systems which derive the salt from something like the username or another field or fields in the DB. Just because there is no obvious salt now doesn't mean it's not there. Only Dropbox knows how it worked at this point.
      - tonicoto 10y ago
        We will have to wait for a code leak ;-)
  - bvinc 10y ago
    Uh oh. You might be on to something. Salts are pretty much always stored right next to the hash, right? If the hack doesn't contain them, maybe they were doing something "clever" like that.

mmaunder 10y ago

The salts for the sha1 passwords weren't leaked. So they're hard to crack in practical terms. Depends how random they were. See hashcat docs and benchmarks for complete answers to your questions. The GPU versions of hashcat.

willvarfar 10y ago
I actually googled before asking my question, and couldn't come up with a good feel for just how crackable these are with hashcat... I guess I don't know the terms or the prices. Is anyone able to make any sense of the GPU hashcat benchmarks that are posted? Something distilled down to "if you spend $xxx, then you can crack any salted sha1 under 12 letters+digits+punctuation in n hours if you knew the salt; if its bcrypt, that would take x hours". Something like that ;) Added: I'm a bit confused how the attackers know the hash and not the salt though; normally they are stored side-by-side. Or were dropbox using a site-wide salt? (I've seen systems with a site-wide salt hardcoded into the codebase and a per-user salt in the db with the hash; This means attackers have to compromise both sourcecode and db to get far.)
- 8draco8 10y ago
  Hash can be stored somewhere else. I also saw systems where some kind of constant for the user was used as a salt. For example first 5 characters of username or timestamp of registration.
- Dylan16807 10y ago
  A rough estimate for using spot instances on EC2 says you can get maybe 40 trillion SHA1 hashes per dollar. (700MH/s and just under $.07/hour) So one dollar will crack a password 7 characters long. A million dollars will crack a password 10 characters long. Switch to bcrypt and you're now at 25 million hashes per dollar on those same instances. Now you can barely crack passwords that are 4 characters long, or for a million dollars you get 7 characters. That's if you know the salt, of course. Otherwise that gets added on to the length you're cracking. None of this is very exact but it gets you in the right ballpark. And you can compare it to a password manager spitting out 20 character passwords that are completely immune to brute forcing.

viraptor 10y ago

It depends how many rounds of sha1 were used and what was the load setting on bcrypt. You can make either one harder to break by playing with those parameters.

imaginenore 10y ago

SHA1 is not necessarily weaker. They might have used many rounds of hashing, which could have made them even stronger.