4 ms·

> You could simply have people use their email address (or name) as a salt. Not great, but it would help significantly. This wouldn't work, as the attacker sho

by jhasse 9y ago

> You could simply have people use their email address (or name) as a salt. Not great, but it would help significantly. This wouldn't work, as the attacker should know both from the database. Anyway: If the user really wants, he can already add his email or name to one of the input fields. A salt is just another input to the hash function so this would be the same. > Eight character random mixed alphanumeric password, hashed with say, sha256: crackable in hours with a GPU cracking rig. Let's say by "several" you mean two. Then if 62^8 = 2 hours that means that: 62^12 = ~3374 years Meaning that a 12 character random mixed alphanumeric password would already take longer than the scrypt approach thanks to the way the exponential function works :) And to do it the other way around (let's say that "years or decades" is 20 years): 62^8 = 20 years 62^5 = ~44 minutes That's why I don't like to advertise with an "uncrackable hash function". In the end this might lead users to choose a shorter password, which is way worse! > scrypt using aggressive settings Keep in mind that if a breach happens, the database is also hashed. And salted! So the attacker would need to crack that first anyway.

ryan-c 9y ago
> This wouldn't work, as the attacker should know both from the database. You mentioned pregenerated lookup tables in a previous comment. Using email address as salt prevents that attack. Salts come with the database too. > Anyway: If the user really wants, he can already add his email or name to one of the input fields. A salt is just another input to the hash function so this would be the same. The proportion of people who would supply it as a salt is much greater than those who would otherwise prepend/append that data to the password. > Meaning that a 12 character random mixed alphanumeric password would already take longer than the scrypt approach thanks to the way the exponential function works :) Yes, but then the user has a more difficult password to memorize, so that argument is irrelevant. You should be thing about what actual humans actually do, rather than assume your users are technically sophisticated and willing to put in the effort to do the right thing. > That's why I don't like to advertise with an "uncrackable hash function". In the end this might lead users to choose a shorter password, which is way worse! Don't advertise it as such, but do it anyway, and explain the details in an FAQ. > Keep in mind that if a breach happens, the database is also hashed. And salted! So the attacker would need to crack that first anyway. It is entirely unreasonable to expect anything better than MD5.
- jhasse 9y ago
  > You mentioned pregenerated lookup tables in a previous comment. Using email address as salt prevents that attack. Salts come with the database too. Ah right, didn't think of that! I will think of adding a preference where one can add a salt value :) > Yes, but then the user has a more difficult password to memorize, so that argument is irrelevant. But while the password-remembering difficulty scales linearly, the difficulty to crack it scales exponentially ;)

by jhasse 9y ago

ryan-c 9y ago

> This wouldn't work, as the attacker should know both from the database. You mentioned pregenerated lookup tables in a previous comment. Using email address as salt prevents that attack. Salts come with the database too. > Anyway: If the user really wants, he can already add his email or name to one of the input fields. A salt is just another input to the hash function so this would be the same. The proportion of people who would supply it as a salt is much greater than those who would otherwise prepend/append that data to the password. > Meaning that a 12 character random mixed alphanumeric password would already take longer than the scrypt approach thanks to the way the exponential function works :) Yes, but then the user has a more difficult password to memorize, so that argument is irrelevant. You should be thing about what actual humans actually do, rather than assume your users are technically sophisticated and willing to put in the effort to do the right thing. > That's why I don't like to advertise with an "uncrackable hash function". In the end this might lead users to choose a shorter password, which is way worse! Don't advertise it as such, but do it anyway, and explain the details in an FAQ. > Keep in mind that if a breach happens, the database is also hashed. And salted! So the attacker would need to crack that first anyway. It is entirely unreasonable to expect anything better than MD5.

jhasse 9y ago
> You mentioned pregenerated lookup tables in a previous comment. Using email address as salt prevents that attack. Salts come with the database too. Ah right, didn't think of that! I will think of adding a preference where one can add a salt value :) > Yes, but then the user has a more difficult password to memorize, so that argument is irrelevant. But while the password-remembering difficulty scales linearly, the difficulty to crack it scales exponentially ;)