4 ms·

Absolutely not. Like I said, the point of the salt is not to provide a "second password" that needs to be independently stolen. It's to make the results from

by tomku 13y ago

Absolutely not. Like I said, the point of the salt is not to provide a "second password" that needs to be independently stolen. It's to make the results from a cracking attempt on one account useless on the password of another. If you've read the article, you have a pretty good idea of how it works without salting. You have a list of N password hashes, and you come up with candidate passwords. You run each candidate password through the hash function, and compare the resulting hash to your list. If it matches any of them, you've got the plaintext for those user accounts. The key thing here is that you only have to hash each candidate password once, and you can compare that hash to as many accounts as you'd like. Now, let's add in a salt. It's stored next to the password, so after stealing the password db you've got a list of password hashes, each with its own salt. In order to check a candidate password against a particular user account, you have to append that user account's salt to the candidate, then hash it and compare against the stored hash. That part isn't any slower. The problem is when you try to take that hash and compare it to other accounts. Even if two users have the same plaintext password, their password hashes will be different because they have different salts. The end result is that you have to hash each candidate password fresh for every user.

chm 13y ago
That's what I understood from the article, and why I suggested the salts and hashes should be handled separately. If you give the attacker the salts, difficulty scales linearly. For two identical plaintexts, all that differs is the salt, but it is given to him. If you store the hashes and salts separately (the technical details of which I know nothing about), then you augment the keyspace exponentially. For N byte salts, using P characters, you augment it by N^P. Furthermore, who forces you to append a salt? You could prepend. Or n-pend. I'm just throwing ideas around.
- nknighthb 13y ago
  The server must have access to both the salt and the hash to verify a password. Therefore, upon compromise of the server, the attacker automatically has access to both the salt and the hash. There is no way around this problem that isn't simply obfuscation.
  - chongli 13y ago
    Not necessarily. With something like a smartcard or TPM chip, one could move the hashes and salts off the server. Both would still be stored together (on the device) but they'd be separate from the server! Edit: Or one could move just the salts into the device and store an index into them in the password file. Hashing would be carried out by the device but an attacker would only gain access to the indices. Without stealing the device itself it'd be impossible to properly salt the passwords for hashing.
    - A1kmm 13y ago
      If you have a dedicated cryptography module, you would be better off storing encrypted hashes, and asking the cryptography module to decrypt the hash and verify the password against it. Salting the hash (and using an expensive hash) would still provide a second layer of defence in case the module is compromised (and provide a physical rate limit to online attacks even if the server is compromised).
    - nknighthb 13y ago
      If the contents of the device can be dumped, the problem remains. If not, you have no copies of your database, so when (not if) the device or the server it's connected to fails, your site is down, and once you've brought it back up, all of your users must go through a password reset process. That one server/device is now a single point of failure and a bottleneck in processing logins. You're also still relying on the security of a computer, just a special-purpose one.
      - chongli 13y ago
        I didn't say anything about reliability or single points of failure. I merely pointed out that it was possible to separate the salt from the hashes and gain security that way. Whether this is practical or not depends on how important security is to you. And yes, it would not be possible to dump the contents of the devices.
        nknighthb 13y ago
- wnight 13y ago
  You can't make the difficulty scale more than linearly by number of passwords. If you could you'd drop back to tackling the problem in pieces and be back to linear scaling with the number of pieces. What's making it hard for you to analyze this is that you're using the wrong terms. The secret stuff is password - the non-secret stuff is salt. If you want two secret bits, you want two passwords, or to break the password into two pieces for separate storage. But after all that, you still want a salt, because you're not using it for secrecy but for ambiguation of identical plaintexts. But splitting the password hash is a bad, or at best neutral, idea because passwords are likely to be semi-human readable and thus a guessable password that matches hash1 is likely the actual password, and will match hash2. This wouldn't be true if we used random passwords, but we don't. So splitting the hash is mostly totally ineffectual, as is having two separate hashes of the same string - the attacker usually doesn't need to examine both.

by tomku 13y ago

chm 13y ago

That's what I understood from the article, and why I suggested the salts and hashes should be handled separately. If you give the attacker the salts, difficulty scales linearly. For two identical plaintexts, all that differs is the salt, but it is given to him. If you store the hashes and salts separately (the technical details of which I know nothing about), then you augment the keyspace exponentially. For N byte salts, using P characters, you augment it by N^P. Furthermore, who forces you to append a salt? You could prepend. Or n-pend. I'm just throwing ideas around.

nknighthb 13y ago
The server must have access to both the salt and the hash to verify a password. Therefore, upon compromise of the server, the attacker automatically has access to both the salt and the hash. There is no way around this problem that isn't simply obfuscation.
- chongli 13y ago
  Not necessarily. With something like a smartcard or TPM chip, one could move the hashes and salts off the server. Both would still be stored together (on the device) but they'd be separate from the server! Edit: Or one could move just the salts into the device and store an index into them in the password file. Hashing would be carried out by the device but an attacker would only gain access to the indices. Without stealing the device itself it'd be impossible to properly salt the passwords for hashing.
  - A1kmm 13y ago
    If you have a dedicated cryptography module, you would be better off storing encrypted hashes, and asking the cryptography module to decrypt the hash and verify the password against it. Salting the hash (and using an expensive hash) would still provide a second layer of defence in case the module is compromised (and provide a physical rate limit to online attacks even if the server is compromised).
  - nknighthb 13y ago
    If the contents of the device can be dumped, the problem remains. If not, you have no copies of your database, so when (not if) the device or the server it's connected to fails, your site is down, and once you've brought it back up, all of your users must go through a password reset process. That one server/device is now a single point of failure and a bottleneck in processing logins. You're also still relying on the security of a computer, just a special-purpose one.
    - chongli 13y ago
      I didn't say anything about reliability or single points of failure. I merely pointed out that it was possible to separate the salt from the hashes and gain security that way. Whether this is practical or not depends on how important security is to you. And yes, it would not be possible to dump the contents of the devices.
      - nknighthb 13y ago
wnight 13y ago
You can't make the difficulty scale more than linearly by number of passwords. If you could you'd drop back to tackling the problem in pieces and be back to linear scaling with the number of pieces. What's making it hard for you to analyze this is that you're using the wrong terms. The secret stuff is password - the non-secret stuff is salt. If you want two secret bits, you want two passwords, or to break the password into two pieces for separate storage. But after all that, you still want a salt, because you're not using it for secrecy but for ambiguation of identical plaintexts. But splitting the password hash is a bad, or at best neutral, idea because passwords are likely to be semi-human readable and thus a guessable password that matches hash1 is likely the actual password, and will match hash2. This wouldn't be true if we used random passwords, but we don't. So splitting the hash is mostly totally ineffectual, as is having two separate hashes of the same string - the attacker usually doesn't need to examine both.