4 ms·

Out of interest, where where the per-user salts stored I wonder? Where would people normally store this if not next to the hashed password in the same table?

globaloptima 12y ago
I'll answer my own question, given the attacker wouldn't know how the salt was used unless they had access to the code, it doesn't matter.
mbrubeck 12y ago
Salts aren't meant to be secret; they are generally stored next to the hashes (and used in a known, standard way). The purpose of the salt is to raise the cost of brute-force attacks, by forcing attackers to brute-force each password separately. https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table
drinchev 12y ago
Yeah it's Usually the same table, but salt is used to prevent hackers using already generated hash map of popular passwords to diff with your password hash directly without computing.
- why-el 12y ago
  I am slightly confused. How can they have use their "hash map of popular passwords" to diff against your table if they do not have the "pepper" used originally for bcrypting the passwords?
  - swhipple 12y ago
    Pre-computed mappings of popular passwords (rainbow tables) aren't really used nowadays due to parallelization being more cost effective, but the idea in both cases is that you want collisions with known values: the popular password hashes in the case of the rainbow table, or the computed values in parallel enumeration. If the password hashes each have a stored unique salt (bcrypt will), you have to compute the hash per salt per password that you test. Instead of computing the hash for "password" (+ stored work factor for bcrypt) to be X, and checking all database entries for X, they instead have to calculate each hash per entry. For a table of 1000 users, it would take around 1000 times as much work to determine the users with "password" as their password. If you just wanted to target a single user though, the salt doesn't really matter for enumeration (though if you were using rainbow tables, you likely wouldn't have those specific hashes computed).

globaloptima 12y ago

I'll answer my own question, given the attacker wouldn't know how the salt was used unless they had access to the code, it doesn't matter.

mbrubeck 12y ago

Salts aren't meant to be secret; they are generally stored next to the hashes (and used in a known, standard way). The purpose of the salt is to raise the cost of brute-force attacks, by forcing attackers to brute-force each password separately. https://en.wikipedia.org/wiki/Rainbow_table https://en.wikipedia.org/wiki/Rainbow_table

drinchev 12y ago

Yeah it's Usually the same table, but salt is used to prevent hackers using already generated hash map of popular passwords to diff with your password hash directly without computing.

why-el 12y ago
I am slightly confused. How can they have use their "hash map of popular passwords" to diff against your table if they do not have the "pepper" used originally for bcrypting the passwords?
- swhipple 12y ago
  Pre-computed mappings of popular passwords (rainbow tables) aren't really used nowadays due to parallelization being more cost effective, but the idea in both cases is that you want collisions with known values: the popular password hashes in the case of the rainbow table, or the computed values in parallel enumeration. If the password hashes each have a stored unique salt (bcrypt will), you have to compute the hash per salt per password that you test. Instead of computing the hash for "password" (+ stored work factor for bcrypt) to be X, and checking all database entries for X, they instead have to calculate each hash per entry. For a table of 1000 users, it would take around 1000 times as much work to determine the users with "password" as their password. If you just wanted to target a single user though, the salt doesn't really matter for enumeration (though if you were using rainbow tables, you likely wouldn't have those specific hashes computed).