6 ms·

"It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested,

"It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database." Why are you storing the whole salt in your database? Isn't it much more common to keep half of it in a configuration file? I know Django has a SECRET_KEY parameter for this sort of thing, and hopefully other frameworks do also. For that matter, why is authentication being handled by the web server? If you've got data worth stealing (billing, emails, medical), you can afford to spring the extra few hundred for a proper authentication server. Gawker's password handling (7-bit salt, in the database, digested with crypt) seems like the worst possible implementation of secure password storage.

beej71 16y ago
If you want to crack passwords ultrafast, you make a look-up table of the hashes of all probable passwords. Without a salt, this is rather a smaller table. A 7-bit salt makes the table larger, but not hugely larger, and not troublesomely larger. The 128-bit salt used by bcrypt makes the table intractably hugely large. You cannot precompute it. Of course, you know the salt (because it's stored right there in /etc/shadow), so you can still run through dictionary words and try them all. But bcrypt is designed to take arbitrarily long amounts of real time to do this. So in the case of bcrypt, it's not really an issue that the salt is stored right there alongside the hashes password.
- tptacek 16y ago
  Those password crackers that are belting through billions and billions of passwords an hour with just a couple of video cards aren't using rainbow tables, are they? You could have zero bit salt: you're still boned. Bcrypt is not better because it has a better salt. It's better because one iteration of bcrypt takes a long time, and millions of iterations take an intractably long time.
  - beej71 16y ago
    Bcrypt is better for BOTH those reasons working together; removing either the salt or the variable-cost key scheduler would be Bad. Obviously, the variable-cost key scheduler is the central notion to the thing, but not having a large salt completely nerfs it. bcrypt uses a 128-bit salt, and it uses it for good reason. See the paper, sections 6.2.1 and 6.2.2.
    - tptacek 16y ago
      You're not wrong. But a 128 bit salt on SHA1 would do zilch to slow down an attacker. You see my point. I see yours.
      - beej71 16y ago
        Yes... the point I see you making is something like this: Putting the 128-bit salt on there prevents a precomputed dictionary attack, a constant time operation. But SHA1 itself is a constant time operation, so having a salt only slows down an attacker in a wall time sense, but not the more important time-complexity sense. We all agree the salt is not particularly important for the constant time hash. (It's only practically important when the hash takes a lot of wall time relative to the wall time of a precomputed dictionary lookup, and constant time hashes gradually lose this edge due to Moore's Law.) The point you see me making is that bcrypt is not a constant time operation (due to the variable-cost key schedule--2^cost, actually), and allowing people to use a constant time precomputed dictionary lookup by not having a large salt would make it as bad as no-salt SHA1. So we all agree that the large salt is vitally important for the non-constant time bcrypt. Not that either of these points are relevant to my initial assertion that giving the salt to an attacker is not something people worry about. The salt is there to prevent a precomputed dictionary attack, and a large salt does this no matter how well-known it is.
izak30 16y ago
I may be mistaken, as I was only browsing. I was looking at Django's auth system last night (as all of this had me curious about the backend). I don't think that SECRET_KEY is used for part of the salt at all, I think it's primarily used for validation of site-generated data, signing requests, and cookie encoding/decoding.
- deleted 16y ago
  [deleted]
- jmillikin 16y ago
  You're probably correct; when I used Django I had to reimplement the auth, since their built-in doesn't support roles, and I didn't look too closely at their implementation.
- StavrosK 16y ago
  You are correct, Django's hashes are stored as salt$digest, or maybe salt$function$digest nowadays. It wouldn't be very good if all your password hashes became invalid because you changed the secret key.
tptacek 16y ago
That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt. Every time this topic comes up, 15 people chime in with various schemes in which some of the "salt" is derived from the hostname and some of it is stored in an encrypted vault and some of it is inferred from the color of the user's eyes. This is why Coda is making fun of "Himalayan pink salt". To understand how irrelevant these details are, consider AES encryption. In addition to hiding an AES key, you can also hide portions of the AES CBC IV (a public value). You could use a random number of rounds. You could mix in tweaks with the round key. All of these things are possible, but (a) nobody analyzes AES based on those random hacks, because they don't fundamentally alter the properties of AES, and (b) nobody does those things, because they are silly. Gawker could use the best conceivable practices in cryptography to obscure passwords; they could be using Colin Percival's scrypt function (which nobody uses yet) to be (in some way) provably resilient to hardware-assisted cracking. You could still level this criticism at them, for "not doing something to further obscure the encryption they used". This is not a new argument; what I am re-explaining here is Kerckhoffs' principle.
- jmillikin 16y ago
  > 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.
whakojacko 16y ago
Why are you storing the whole salt in your database? Isn't it much more common to keep half of it in a configuration file? I know Django has a SECRET_KEY parameter for this sort of thing, and hopefully other frameworks do also. How is that really any better? You should assume that if an attack can get to your database, they can get to your web servers and take all of that as well. Such a scheme certainly wouldn't have saved Gawker.
- jhchen 16y ago
  In Gawker's case this is exactly right. The database AND the source code was accessed so the config file defense would not have worked.
- jmillikin 16y ago
  Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc). There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems.
  - tptacek 16y ago
    If you lose code execution on your server to an attacker, you're done. 100% fucked. Everything in your environment needs to get stripped down and rebuilt from trusted sources. Do not be one of those people who rationalizes "oh, I just lost uid=4294967294". Gawker lost root. So will you.
    - JonnieCache 16y ago
      And if you lose root, the disk must be reimaged. Rootkits are too advanced these days to ever make the assumption that you have removed them.
      - bigiain 16y ago

beej71 16y ago

If you want to crack passwords ultrafast, you make a look-up table of the hashes of all probable passwords. Without a salt, this is rather a smaller table. A 7-bit salt makes the table larger, but not hugely larger, and not troublesomely larger. The 128-bit salt used by bcrypt makes the table intractably hugely large. You cannot precompute it. Of course, you know the salt (because it's stored right there in /etc/shadow), so you can still run through dictionary words and try them all. But bcrypt is designed to take arbitrarily long amounts of real time to do this. So in the case of bcrypt, it's not really an issue that the salt is stored right there alongside the hashes password.

tptacek 16y ago
Those password crackers that are belting through billions and billions of passwords an hour with just a couple of video cards aren't using rainbow tables, are they? You could have zero bit salt: you're still boned. Bcrypt is not better because it has a better salt. It's better because one iteration of bcrypt takes a long time, and millions of iterations take an intractably long time.
- beej71 16y ago
  Bcrypt is better for BOTH those reasons working together; removing either the salt or the variable-cost key scheduler would be Bad. Obviously, the variable-cost key scheduler is the central notion to the thing, but not having a large salt completely nerfs it. bcrypt uses a 128-bit salt, and it uses it for good reason. See the paper, sections 6.2.1 and 6.2.2.
  - tptacek 16y ago
    You're not wrong. But a 128 bit salt on SHA1 would do zilch to slow down an attacker. You see my point. I see yours.
    - beej71 16y ago
      Yes... the point I see you making is something like this: Putting the 128-bit salt on there prevents a precomputed dictionary attack, a constant time operation. But SHA1 itself is a constant time operation, so having a salt only slows down an attacker in a wall time sense, but not the more important time-complexity sense. We all agree the salt is not particularly important for the constant time hash. (It's only practically important when the hash takes a lot of wall time relative to the wall time of a precomputed dictionary lookup, and constant time hashes gradually lose this edge due to Moore's Law.) The point you see me making is that bcrypt is not a constant time operation (due to the variable-cost key schedule--2^cost, actually), and allowing people to use a constant time precomputed dictionary lookup by not having a large salt would make it as bad as no-salt SHA1. So we all agree that the large salt is vitally important for the non-constant time bcrypt. Not that either of these points are relevant to my initial assertion that giving the salt to an attacker is not something people worry about. The salt is there to prevent a precomputed dictionary attack, and a large salt does this no matter how well-known it is.

izak30 16y ago

I may be mistaken, as I was only browsing. I was looking at Django's auth system last night (as all of this had me curious about the backend). I don't think that SECRET_KEY is used for part of the salt at all, I think it's primarily used for validation of site-generated data, signing requests, and cookie encoding/decoding.

deleted 16y ago
[deleted]
jmillikin 16y ago
You're probably correct; when I used Django I had to reimplement the auth, since their built-in doesn't support roles, and I didn't look too closely at their implementation.
StavrosK 16y ago
You are correct, Django's hashes are stored as salt$digest, or maybe salt$function$digest nowadays. It wouldn't be very good if all your password hashes became invalid because you changed the secret key.

tptacek 16y ago

That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt. Every time this topic comes up, 15 people chime in with various schemes in which some of the "salt" is derived from the hostname and some of it is stored in an encrypted vault and some of it is inferred from the color of the user's eyes. This is why Coda is making fun of "Himalayan pink salt". To understand how irrelevant these details are, consider AES encryption. In addition to hiding an AES key, you can also hide portions of the AES CBC IV (a public value). You could use a random number of rounds. You could mix in tweaks with the round key. All of these things are possible, but (a) nobody analyzes AES based on those random hacks, because they don't fundamentally alter the properties of AES, and (b) nobody does those things, because they are silly. Gawker could use the best conceivable practices in cryptography to obscure passwords; they could be using Colin Percival's scrypt function (which nobody uses yet) to be (in some way) provably resilient to hardware-assisted cracking. You could still level this criticism at them, for "not doing something to further obscure the encryption they used". This is not a new argument; what I am re-explaining here is Kerckhoffs' principle.

jmillikin 16y ago
> 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.

whakojacko 16y ago

Why are you storing the whole salt in your database? Isn't it much more common to keep half of it in a configuration file? I know Django has a SECRET_KEY parameter for this sort of thing, and hopefully other frameworks do also. How is that really any better? You should assume that if an attack can get to your database, they can get to your web servers and take all of that as well. Such a scheme certainly wouldn't have saved Gawker.

jhchen 16y ago
In Gawker's case this is exactly right. The database AND the source code was accessed so the config file defense would not have worked.
jmillikin 16y ago
Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc). There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems.
- tptacek 16y ago
  If you lose code execution on your server to an attacker, you're done. 100% fucked. Everything in your environment needs to get stripped down and rebuilt from trusted sources. Do not be one of those people who rationalizes "oh, I just lost uid=4294967294". Gawker lost root. So will you.
  - JonnieCache 16y ago
    And if you lose root, the disk must be reimaged. Rootkits are too advanced these days to ever make the assumption that you have removed them.
    - bigiain 16y ago