5 ms·

How so? Seems to me like it could mean any number of things, all of which succeed in securely hashing+salting a password.

by rheide 15y ago

daeken 15y ago
They could be using 3 different salts, each of which is statically stored on the server. They could be using 3 per-password salts, and applying each of them once. They could be.... At the end of the day, salts are there for one thing alone: eliminating the possibility of rainbow tables. But whether you use 1 salt of decent size (64-bit minimum for that) or 1000, you've got the exact same protection there. There's a good reason it's recommended that you use PBKDF2 or bcrypt.
- eric-hu 15y ago
  Doesn't a salt just make a rainbow table attack more expensive, in direct relation to the length of the salt?
  - yaakov34 15y ago
    No, it doesn't. Once the salt is large enough that you don't have several passwords hashed with the same salt value, there is absolutely no further advantage. Frankly, 64 bits of salt seems like enough for anything. Triple-salting sounds like a technique made up by an amateur who doesn't understand what salting is supposed to do.
    - by 15y ago
      "The length of the randomly generated salt shall be at least 128 bits." nist-sp800-132.pdf http://csrc.nist.gov/publications/PubsSPs.html http://csrc.nist.gov/publications/PubsSPs.html Not quite the same application, but it would seem best to take a conservative approach and make your salts 128 bits because the storage required is so small - you are only storing one per username.
      - yaakov34 15y ago
        Right, but this doesn't make the search space 2^64 times larger, or anything of the sort. Once you've assigned a unique salt to every password, you're not getting any further benefits from salting. This is what the Mt. Gox owner doesn't seem to get, with his "triple-salting". The NIST application involves generating keys from passwords, which you might do a gigantic number of times for every password to get unique sessions and so on. They're not talking about password storage. And even then, 128 bits seems like a huge overkill, which was included just because it's cheap, so why not. I don't mind 128-bit salts, but let's not promote that as some "ultra-secure" feature, which it isn't.
deleted 15y ago
[deleted]
tzs 15y ago
Security is hard, and we KNOW they are not experts in this area. The ONLY way they can do a secure system is to use someone else's design. Thus, the fact that they are describing it in terms that none of us have heard of is a troubling sign.

How so? Seems to me like it could mean any number of things, all of which succeed in securely hashing+salting a password.

by rheide 15y ago

How so? Seems to me like it could mean any number of things, all of which succeed in securely hashing+salting a password.

daeken 15y ago

They could be using 3 different salts, each of which is statically stored on the server. They could be using 3 per-password salts, and applying each of them once. They could be.... At the end of the day, salts are there for one thing alone: eliminating the possibility of rainbow tables. But whether you use 1 salt of decent size (64-bit minimum for that) or 1000, you've got the exact same protection there. There's a good reason it's recommended that you use PBKDF2 or bcrypt.

eric-hu 15y ago
Doesn't a salt just make a rainbow table attack more expensive, in direct relation to the length of the salt?
- yaakov34 15y ago
  No, it doesn't. Once the salt is large enough that you don't have several passwords hashed with the same salt value, there is absolutely no further advantage. Frankly, 64 bits of salt seems like enough for anything. Triple-salting sounds like a technique made up by an amateur who doesn't understand what salting is supposed to do.
  - by 15y ago
    "The length of the randomly generated salt shall be at least 128 bits." nist-sp800-132.pdf http://csrc.nist.gov/publications/PubsSPs.html http://csrc.nist.gov/publications/PubsSPs.html Not quite the same application, but it would seem best to take a conservative approach and make your salts 128 bits because the storage required is so small - you are only storing one per username.
    - yaakov34 15y ago
      Right, but this doesn't make the search space 2^64 times larger, or anything of the sort. Once you've assigned a unique salt to every password, you're not getting any further benefits from salting. This is what the Mt. Gox owner doesn't seem to get, with his "triple-salting". The NIST application involves generating keys from passwords, which you might do a gigantic number of times for every password to get unique sessions and so on. They're not talking about password storage. And even then, 128 bits seems like a huge overkill, which was included just because it's cheap, so why not. I don't mind 128-bit salts, but let's not promote that as some "ultra-secure" feature, which it isn't.

deleted 15y ago

[deleted]

tzs 15y ago

Security is hard, and we KNOW they are not experts in this area. The ONLY way they can do a secure system is to use someone else's design. Thus, the fact that they are describing it in terms that none of us have heard of is a troubling sign.