3 ms·

What's wrong with using a salted hash? Assuming a competent implementation, it should be computationally infeasible to brute-force any digests in less than a fe

What's wrong with using a salted hash? Assuming a competent implementation, it should be computationally infeasible to brute-force any digests in less than a few billion years using current models of computation. I'm particularly curious about how using (for example) BCrypt will prevent brute-forcing "12345", "password", or any of the other simple strings many people use.

deleted 17y ago
[deleted]
tptacek 17y ago
That first paragraph is a funny statement, since every Unix security book ever written explains how to use Crack, a tool written before I even got into high school, to rip through Unix salted passwords. I don't think it even bears arguing. The second point is valid but not particularly meaningful. You could also try "12345" and "password" over the network using the login page as an oracle, given a list of usernames. But with SHA1, you can feasibly do large combinations of phonemes with numbers and punctuation across millions of accounts. People with passwords like "ugh8&eat" will lose their accounts. You can tune BCrypt so that just "12345", by itself, is too painful to run across 32MM rows to be worth a PR stunt.
- jmillikin 17y ago
  I said "competent"; the UNIX crypt() and Windows LanMan schemes do not count. If you have any information about defeating a properly implemented salt+hash system, I (and every other developer in the world) would be eager to hear it. For example, I just generated a salt/digest combination for a simple example password. It is digested using SHA-1, and the password is four ASCII digits. Here is the database row -- '|' is a delimiter between the fields. algo | user_salt | digest ---------------------------------------------------------------------- sha1 | lyhsus1eizh815xz69pv | d418a6088847d6f2e5b0e3d2ecf2e300454a0885 If you (or, anybody) can determine the original password from this database row, I will mail you a check for a thousand dollars.
  - deleted 17y ago
    [deleted]
  - bigmac 17y ago
    Does this include a config file salt as well?
    - jmillikin 17y ago
      The config salt isn't present in my post -- I'm assuming a database breach, like that which usually occurs. The digest does include a config salt, of course -- this isn't the '70s.
  - ars 17y ago
    It's traditional to also including a testing row, revealing the password (along with the digest), so that people can verify that their cracking code works.
  - tptacek 17y ago
    [Updated: You're not using SHA1, you're using keyed SHA1 with a secret random key. Presumably it's long, because you made your per-password salt ludicrously long, because you don't really understand how salts work. Note that every "read any file the web app can" vulnerability on your system is now "recover tens of thousands of passwords". It would be extra funny if you hashed your config file salt second instead of first, but I'll leave it up to the experts on your team to figure out why that is.]. It takes 5us on this system to do one SHA1 calculation. You're not using ASCII "digits" (if you were, I'd know, because brute forcing all the 4-digit numeric strings took less than a second); you meant characters. There are ~130MM 4-digit character combinations in standard ASCII. Maybe I'm misunderstanding something about this challenge, but, if I'm not, post the code you used to generate this comment so I don't waste my time attacking a salt that is secretly Base64'd, and in 10 hours, you can mail your check to Amnesty International.
    - ars 17y ago
      > You're not using SHA1, you're using keyed SHA1 with a secret random key. Does that mean that doing so is OK, except for the read any file breach? Because I've been doing that cookie authentications. Database and file reads are not something I'm worried about (for this situation), but I don't want the cookie to be easy to crack. I.e. auth = sha1('long secret string' . 'user_id' . 'password') /* I include the password to invalidate existing cookies if someone changes their password */ I then set a cookie to the user_id, and another cookie to auth, and check them on every page. Also, I'm not him, so I'd like to know why doing the config salt second instead of first is bad. I thought you could do a partial hash, i.e. hash the config salt once, then just keep updating it with the rest. Meaning, the config salt should go second, not first.
shrughes 17y ago
What's wrong with using a salted hash? Because you've been assuming that the database will be breached and that no other kind of attack can happen.

deleted 17y ago

[deleted]

tptacek 17y ago

That first paragraph is a funny statement, since every Unix security book ever written explains how to use Crack, a tool written before I even got into high school, to rip through Unix salted passwords. I don't think it even bears arguing. The second point is valid but not particularly meaningful. You could also try "12345" and "password" over the network using the login page as an oracle, given a list of usernames. But with SHA1, you can feasibly do large combinations of phonemes with numbers and punctuation across millions of accounts. People with passwords like "ugh8&eat" will lose their accounts. You can tune BCrypt so that just "12345", by itself, is too painful to run across 32MM rows to be worth a PR stunt.

jmillikin 17y ago
I said "competent"; the UNIX crypt() and Windows LanMan schemes do not count. If you have any information about defeating a properly implemented salt+hash system, I (and every other developer in the world) would be eager to hear it. For example, I just generated a salt/digest combination for a simple example password. It is digested using SHA-1, and the password is four ASCII digits. Here is the database row -- '|' is a delimiter between the fields. algo | user_salt | digest ---------------------------------------------------------------------- sha1 | lyhsus1eizh815xz69pv | d418a6088847d6f2e5b0e3d2ecf2e300454a0885 If you (or, anybody) can determine the original password from this database row, I will mail you a check for a thousand dollars.
- deleted 17y ago
  [deleted]
- bigmac 17y ago
  Does this include a config file salt as well?
  - jmillikin 17y ago
    The config salt isn't present in my post -- I'm assuming a database breach, like that which usually occurs. The digest does include a config salt, of course -- this isn't the '70s.
- ars 17y ago
  It's traditional to also including a testing row, revealing the password (along with the digest), so that people can verify that their cracking code works.
- tptacek 17y ago
  [Updated: You're not using SHA1, you're using keyed SHA1 with a secret random key. Presumably it's long, because you made your per-password salt ludicrously long, because you don't really understand how salts work. Note that every "read any file the web app can" vulnerability on your system is now "recover tens of thousands of passwords". It would be extra funny if you hashed your config file salt second instead of first, but I'll leave it up to the experts on your team to figure out why that is.]. It takes 5us on this system to do one SHA1 calculation. You're not using ASCII "digits" (if you were, I'd know, because brute forcing all the 4-digit numeric strings took less than a second); you meant characters. There are ~130MM 4-digit character combinations in standard ASCII. Maybe I'm misunderstanding something about this challenge, but, if I'm not, post the code you used to generate this comment so I don't waste my time attacking a salt that is secretly Base64'd, and in 10 hours, you can mail your check to Amnesty International.
  - ars 17y ago
    > You're not using SHA1, you're using keyed SHA1 with a secret random key. Does that mean that doing so is OK, except for the read any file breach? Because I've been doing that cookie authentications. Database and file reads are not something I'm worried about (for this situation), but I don't want the cookie to be easy to crack. I.e. auth = sha1('long secret string' . 'user_id' . 'password') /* I include the password to invalidate existing cookies if someone changes their password */ I then set a cookie to the user_id, and another cookie to auth, and check them on every page. Also, I'm not him, so I'd like to know why doing the config salt second instead of first is bad. I thought you could do a partial hash, i.e. hash the config salt once, then just keep updating it with the rest. Meaning, the config salt should go second, not first.

shrughes 17y ago

What's wrong with using a salted hash? Because you've been assuming that the database will be breached and that no other kind of attack can happen.