> 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.
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.