4 ms·

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 syste

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.
  - tptacek 17y ago
    You are sending a crackable password hash on every request. Stop doing that. Create a session table, key it off a 48-byte random string from /dev/random, and store authenticators in that. In other words, JSESSIONID or RACK.SESSION or PHPSESSIONID or ASPSESSIONID are all stronger approaches than the one you've chosen. You are going through extra effort to make your system less secure. If the config salt is the second term hashed, the scheme has a basic crypto flaw, one you can't make if you just use BCrypt or PBKDF like a reasonable developer instead of designing your own vanity scheme.
    - heresy 17y ago
      thanks. every time someone uses the password as input to some "secure" hash, i cry inside. why is the password even relevant to a user session identifier? it's not.
      - ars 17y ago
        And the next time someone logs in as you, and clicks "keep me logged in" - and you have no way to un-log them in, you should also cry inside. If the password is changed, all session identifiers must be invalidated. If it's a session table, delete all entries, if it's a hash - well your hash had better include the password somehow (a hash of the password hash, i.e. the one stored in the db, is fine, as long as changing the password changes the final hash).

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.
- tptacek 17y ago
  You are sending a crackable password hash on every request. Stop doing that. Create a session table, key it off a 48-byte random string from /dev/random, and store authenticators in that. In other words, JSESSIONID or RACK.SESSION or PHPSESSIONID or ASPSESSIONID are all stronger approaches than the one you've chosen. You are going through extra effort to make your system less secure. If the config salt is the second term hashed, the scheme has a basic crypto flaw, one you can't make if you just use BCrypt or PBKDF like a reasonable developer instead of designing your own vanity scheme.
  - heresy 17y ago
    thanks. every time someone uses the password as input to some "secure" hash, i cry inside. why is the password even relevant to a user session identifier? it's not.
    - ars 17y ago
      And the next time someone logs in as you, and clicks "keep me logged in" - and you have no way to un-log them in, you should also cry inside. If the password is changed, all session identifiers must be invalidated. If it's a session table, delete all entries, if it's a hash - well your hash had better include the password somehow (a hash of the password hash, i.e. the one stored in the db, is fine, as long as changing the password changes the final hash).