Earlier this year, when I went from having only Facebook-login on Wishy.gift to allow registrations with email address and password, one of my concerns was how to implement this is a way that protects the data and privacy of my users. I don’t have any ads or analytics on the site, the users can select whatever display name they want, and I never stored the email addresses I got from Facebook when a user registered or logged in - only a hashed[1] version of the ID. Email addresses and passwords, on the other hand, are a whole other beast, and the consequences of a database breach much worse.
Considering that the only kind of emails I ever need to send out are transactional - no newsletters or other kinds of notifications - the only thing I need to store them for are as identifiers, and can safely be hashed.
For every transactional email I need to send out - registration, account recovery, and email change verification - the user always initiates this by submitting their email address, and it will at that time be available to the backend to perform the needed action.
In conclusion, if you only use email addresses for transactional emails, you might be able to only store hashed versions of them. For Wishy.gift I use SHA512 with a fixed salt, and this has been working perfectly since implementation in June.
Thank you for reading this! I would love to hear your thoughts and ideas too. Join the discussion on Hacker News, or feel free to email me at <firstname>@klungo.no, or DM me on Twitter
I discovered that, even though the ID was unique to my FB-app, it was still possible to go to facebook.com/{id} and be redirected to the user’s FB-profile. ↩︎