4 ms·

> That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt. I don't understand why you'd add extr

> That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt. I don't understand why you'd add extra content to the password unless you keep it secret. The whole point of a salt/nonce is to prevent attackers from attacking the digest, right? You need some per-user data, to defend against rainbow tables, and some per-site data, to protect weak passwords. My fundamental objection to schemes like bcrypt/scrypt is that they impose a heavy performance penalty on authentication to avoid a relatively rare case; besides, any theoretical entity capable of reversing a typical salted-password implementation is also capable of reversing bcrypt/scrypt.

tptacek 16y ago
"Reversing" bcrypt? "Reversing" salted hashes? You're exactly the guy I'm talking about. "Oh, I use AES, but I don't just use AES; I store the secret IV for AES in a cookie so even my server can't decrypt it unless the client comes back with the IV so it's like two guys in the silo with the missile keys". Seriously, I just found that piece of code yesterday. Did you write it? Stop writing that stuff.
- jmillikin 16y ago
  No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used. I know there's lots of ways to screw up security, but most of them derive from lazy people taking shortcuts. They run the httpd, database, and authentication all off the same server so a vulnerability in one compromises all. They store secrets in the database because figuring out secure storage would take half an hour of research. Replacing a poorly-implemented SHA1-based system with a poorly-implemented bcrypt-based one won't help security.
  - tptacek 16y ago
    SHA1(salt || password) is an incompetent design that is debatably even easier to crack than the Gawker hashes. The insecurity of that construction is why we have PBKDF2. If the entire knowledge you have of cryptography comes from _Applied Cryptography_ --- wait; let me extend that: if you even feel the need to cite _Applied Cryptography_ --- you should be careful debating crypto constructions. You're not going to end up happy.
    - Xk 16y ago
      I'm curious what the attack is that makes that easier to crack than the Gawker way. (I'm sure you're right, I just didn't know that it would be easier.)
      - tptacek 16y ago
        SHA1 might (I think it is, but I'm not sure) be faster than DES; among other differences, DES crypt(3) has to run the DES key schedule before producing a hash. Data slips through SHA1 like a greased seal.
        Xk 16y ago
        Ah, alright. I was thinking there was some kind of length-extension weakness (which doesn't apply here, which is why I was confused) or some other attack in the cryptographic sense. Thanks.
        tptacek 16y ago
        SHA1(salt || password) does have a length-extension property; you can easily compute SHA1(salt || password || junk || arbitrary-data) for any given hash. That's not very useful for password hashes, but is devastating for the kinds of SHA1-based authentication schemes that people who write their own password hashes seem to come up with.
        Xk 16y ago
        Yeah, by "doesn't apply" I meant "that's not very useful for password hashes".
        bhousel 16y ago
        Looks like you're right.. these benchmarks show SHA1 about 5x faster than DES: http://www.cryptopp.com/benchmarks.html http://www.cryptopp.com/benchmarks.html
      - getsat 16y ago
  - defen 16y ago
    > No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used. Anyone can create an input that hashes to a given value. The relevant factor is how long it takes to create that input. I hope you can see the difference between that process taking 3 seconds vs 40 years.
- nkurz 16y ago
  I can probably top you: some many years ago, I discovered that Network Solutions (the original domain name provider) was using the first two characters of the password as the salt for their user accounts, presumably so that the salt could also be secret. Of course, this had the side-effect of making the first two characters of the password visible in plain text if you looked at the hashes. I reported this as a bug and never heard back. I've also never done business with Network Solutions since then.
  - wolfhumble 16y ago
    So the salt was just added to the hash without hashing the concatenated hash + salt, i.e was this the method they chose?: saltedhash(password)=hash(password).salt A part from the obvious flaw of including part of the password in plain text, how secure is this method compared to the following method were the salt is not a secret and were the concatenated hash + salt is hashed?: saltedhash(password)=hash(hash(password).salt)
  - StavrosK 16y ago
    Using two-character salts might be as big of a wtf here.
    - nkurz 16y ago
      Perhaps in retrospect, but this was standard for the Unix crypt() function and passwd files of the time: http://linux.die.net/man/3/crypt http://linux.die.net/man/3/crypt The dangers of rainbow table attacks weren't well considered at the time. The real error was misreading the man page and using the first two characters as the salt, which is then published as the first two characters of the hash. It's sort of an easy error to make, because to decrypt, you do use the first two characters of the hash. Understandable for a beginner working on a school project, but pretty ludicrous for a large company holding control over most of the domains on the internet at the time.
- deleted 16y ago
  [deleted]
azernik 16y ago
The point of the salt is not to add extra complexity to the secret information; it is to make your transformation of the password into a hash different from everyone else's such transformation. This prevents attackers from getting a supercomputer or two, calculating a mondo rainbow table, and using it to crack every password hash in existence. The salt forces them to perform this computational feat separately each time they want to crack a password.
Xk 16y ago
> they impose a heavy performance penalty on authentication to avoid a relatively rare case You're authenticating over the internet. What is 1/10th of a second to authenticate the first time you want to log in relative to everything else? It's like complaining you have to put the key into your car before starting a five hundred mile road trip. Yes, it takes a few seconds. But worth it? Most definitely.
- codexon 16y ago
  If you have 10 people logging in per second, you put a 1 second delay on future requests which is certainly noticeable. Maybe the correct thing to do is to make the key derivation executed on the client side, but then this would erode the experience of mobile phone users.
  - tptacek 16y ago
    There is no way to securely do this clientside. It's hard to imagine a situation in which login overhead is painful where scaling in general isn't already a huge concern; presumably, anything you do after login is going to be more painful than bcrypt.
    - Xk 16y ago
      I would imagine some kind of zero-knowledge proof would work here, but that would require more server interaction than just doing the hashes in the first place.
    - deleted 16y ago
      [deleted]
  - Xk 16y ago
    If you have ten people logging in per second, you've got to have more than one server. Distribute the login requests. And if it really kills you to make it take a full second, then make it take 1/10th of a second: there, now your hashing is faster than the time it takes to dynamically generate a page. People really need to learn that security doesn't come free, and some times you just need to bite down and say "You know what? I never plan on getting broken into, but just in case I do I'll take the tenth of a second extra computation in exchange for doing the right thing."
dguido 16y ago
Basic version: The salt prevents an attacker from being able to pre-compute a mapping from password <-> hash value. It's most effective when it changes per-password and it doesn't matter if it's public. http://en.wikipedia.org/wiki/Salt_(cryptography) http://en.wikipedia.org/wiki/Salt_(cryptography)
- nitrogen 16y ago
  To make it even more obvious, it's to prevent this (I haven't done SQL in a long while so this may be broken): SELECT username FROM users WHERE password=HASH('secret'); I've seen systems where that statement will give a list of all usernames with the password "secret".
  - rmc 16y ago
    If you use a salt you could still do this 'attack. SELECT username FROM users WHERE password = HASH(salt||'secret'); This is academic because you already know the password ('secret'). Salts make rainbow tables (essentially precomputed hash values of (say) all english words) hard and infesiable.

tptacek 16y ago

"Reversing" bcrypt? "Reversing" salted hashes? You're exactly the guy I'm talking about. "Oh, I use AES, but I don't just use AES; I store the secret IV for AES in a cookie so even my server can't decrypt it unless the client comes back with the IV so it's like two guys in the silo with the missile keys". Seriously, I just found that piece of code yesterday. Did you write it? Stop writing that stuff.

jmillikin 16y ago
No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used. I know there's lots of ways to screw up security, but most of them derive from lazy people taking shortcuts. They run the httpd, database, and authentication all off the same server so a vulnerability in one compromises all. They store secrets in the database because figuring out secure storage would take half an hour of research. Replacing a poorly-implemented SHA1-based system with a poorly-implemented bcrypt-based one won't help security.
- tptacek 16y ago
  SHA1(salt || password) is an incompetent design that is debatably even easier to crack than the Gawker hashes. The insecurity of that construction is why we have PBKDF2. If the entire knowledge you have of cryptography comes from _Applied Cryptography_ --- wait; let me extend that: if you even feel the need to cite _Applied Cryptography_ --- you should be careful debating crypto constructions. You're not going to end up happy.
  - Xk 16y ago
    I'm curious what the attack is that makes that easier to crack than the Gawker way. (I'm sure you're right, I just didn't know that it would be easier.)
    - tptacek 16y ago
      SHA1 might (I think it is, but I'm not sure) be faster than DES; among other differences, DES crypt(3) has to run the DES key schedule before producing a hash. Data slips through SHA1 like a greased seal.
      - Xk 16y ago
        Ah, alright. I was thinking there was some kind of length-extension weakness (which doesn't apply here, which is why I was confused) or some other attack in the cryptographic sense. Thanks.
        tptacek 16y ago
        SHA1(salt || password) does have a length-extension property; you can easily compute SHA1(salt || password || junk || arbitrary-data) for any given hash. That's not very useful for password hashes, but is devastating for the kinds of SHA1-based authentication schemes that people who write their own password hashes seem to come up with.
        Xk 16y ago
        Yeah, by "doesn't apply" I meant "that's not very useful for password hashes".
      - bhousel 16y ago
        Looks like you're right.. these benchmarks show SHA1 about 5x faster than DES: http://www.cryptopp.com/benchmarks.html http://www.cryptopp.com/benchmarks.html
    - getsat 16y ago
- defen 16y ago
  > No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used. Anyone can create an input that hashes to a given value. The relevant factor is how long it takes to create that input. I hope you can see the difference between that process taking 3 seconds vs 40 years.
nkurz 16y ago
I can probably top you: some many years ago, I discovered that Network Solutions (the original domain name provider) was using the first two characters of the password as the salt for their user accounts, presumably so that the salt could also be secret. Of course, this had the side-effect of making the first two characters of the password visible in plain text if you looked at the hashes. I reported this as a bug and never heard back. I've also never done business with Network Solutions since then.
- wolfhumble 16y ago
  So the salt was just added to the hash without hashing the concatenated hash + salt, i.e was this the method they chose?: saltedhash(password)=hash(password).salt A part from the obvious flaw of including part of the password in plain text, how secure is this method compared to the following method were the salt is not a secret and were the concatenated hash + salt is hashed?: saltedhash(password)=hash(hash(password).salt)
- StavrosK 16y ago
  Using two-character salts might be as big of a wtf here.
  - nkurz 16y ago
    Perhaps in retrospect, but this was standard for the Unix crypt() function and passwd files of the time: http://linux.die.net/man/3/crypt http://linux.die.net/man/3/crypt The dangers of rainbow table attacks weren't well considered at the time. The real error was misreading the man page and using the first two characters as the salt, which is then published as the first two characters of the hash. It's sort of an easy error to make, because to decrypt, you do use the first two characters of the hash. Understandable for a beginner working on a school project, but pretty ludicrous for a large company holding control over most of the domains on the internet at the time.
deleted 16y ago
[deleted]

azernik 16y ago

The point of the salt is not to add extra complexity to the secret information; it is to make your transformation of the password into a hash different from everyone else's such transformation. This prevents attackers from getting a supercomputer or two, calculating a mondo rainbow table, and using it to crack every password hash in existence. The salt forces them to perform this computational feat separately each time they want to crack a password.

Xk 16y ago

> they impose a heavy performance penalty on authentication to avoid a relatively rare case You're authenticating over the internet. What is 1/10th of a second to authenticate the first time you want to log in relative to everything else? It's like complaining you have to put the key into your car before starting a five hundred mile road trip. Yes, it takes a few seconds. But worth it? Most definitely.

codexon 16y ago
If you have 10 people logging in per second, you put a 1 second delay on future requests which is certainly noticeable. Maybe the correct thing to do is to make the key derivation executed on the client side, but then this would erode the experience of mobile phone users.
- tptacek 16y ago
  There is no way to securely do this clientside. It's hard to imagine a situation in which login overhead is painful where scaling in general isn't already a huge concern; presumably, anything you do after login is going to be more painful than bcrypt.
  - Xk 16y ago
    I would imagine some kind of zero-knowledge proof would work here, but that would require more server interaction than just doing the hashes in the first place.
  - deleted 16y ago
    [deleted]
- Xk 16y ago
  If you have ten people logging in per second, you've got to have more than one server. Distribute the login requests. And if it really kills you to make it take a full second, then make it take 1/10th of a second: there, now your hashing is faster than the time it takes to dynamically generate a page. People really need to learn that security doesn't come free, and some times you just need to bite down and say "You know what? I never plan on getting broken into, but just in case I do I'll take the tenth of a second extra computation in exchange for doing the right thing."

dguido 16y ago

Basic version: The salt prevents an attacker from being able to pre-compute a mapping from password <-> hash value. It's most effective when it changes per-password and it doesn't matter if it's public. http://en.wikipedia.org/wiki/Salt_(cryptography) http://en.wikipedia.org/wiki/Salt_(cryptography)

nitrogen 16y ago
To make it even more obvious, it's to prevent this (I haven't done SQL in a long while so this may be broken): SELECT username FROM users WHERE password=HASH('secret'); I've seen systems where that statement will give a list of all usernames with the password "secret".
- rmc 16y ago
  If you use a salt you could still do this 'attack. SELECT username FROM users WHERE password = HASH(salt||'secret'); This is academic because you already know the password ('secret'). Salts make rainbow tables (essentially precomputed hash values of (say) all english words) hard and infesiable.