Hacker News new | past | comments | ask | show | jobs | submit login

Good points. Though given how many emails have been leaked already, not sure sha256 with fixed salt achieves much. One can build a rainbow table with that salt fairly quickly. You might as well use bcrypt, scrypt and co.



Using something like bcrypt would definitively be better, but considering that the email is the identifier, I would have no way of retrieving the correct hash to check it against, so the salt must be fixed to allow for lookups.

I'm currently using SHA512 with a fixed salt. If someone gains access to only the database and not the salt, the emails are well protected. If someone gains access to both, then it's true that they could build a rainbow table to check if a given email exists in the database. What they _can't_ do is easily use all the emails in the database for spam/phishing/etc.

Either way, I'd argue it's better than nothing :)


Sorry, I missed the point about it being the identifier.

Though technically you can still use the bcrypt hash as your identifier, unless it has to be correlated to an external source of emails.


You cant, really... bcrypt hashes are not consistent... you run bcrypt on the same email, you are going to get two different hashes. You can't search your DB for the matching hash, you would have to iterate through every entry to compare.


Use the password as the salt.

Still need a fixed salt but that should help.


Doesn't that break account recovery requests?


This is not a reasonable use case for rainbow tables.


Why? You can churn sha256 hashes pretty quickly. There are probably less email addresses out there than there are passwords.


Why would you build a rainbow table you’re only going to use once? You’d just use hashcat for this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: