Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need to store plaintext email addresses

blog.klungo.no

Post reply on HN
Print view View original

61–70 of 181 posts

Re: You might not need to store plaintext email addresses

#61

Post by Fumtumi »

danielskogly wrote: post #58
Fumtumi wrote: post #54

Sounds unnecessary complicated for no real benefit with issues along the road. And it does feel weird to use Facebook in this example. If you don't care for an email address, and you are using the login only for maintaining that list, use an permalink. Thats probably easier and better. One permalink for edit, one permalink for viewing.

Facebook is only mentioned in the context of how I did things previously, before I implemented the email/password registration.

What was your main motivation to put so much effort in making sure that you are not storing his/her email address?

Re: You might not need to store plaintext email addresses

#62

Post by raxxorrax »

markvdb wrote: post #49

> Earlier this year, when I went from having only Facebook-login [...] to allow registrations with email and password, one of my concerns was how to implement this is a way that protects the data and privacy of my users. Any privacy effort is laudable. Then again, if you're serious about protecting your users' data and privacy, Facebook login is the elephant in the room.

Fully agree and you can be certain that Facebook does save your E-Mail address.

I use authentication services like auth0 and AWS cognito. The first one I think is completely safe for privacy, the second one is used for convenience (I think the service is good for stuff you host on AWS anyway, although it is generic, so it isn't restricted to that).

But using an auth-service is mostly about deferring risk of breaches to people more proficient in security. That comes with the cost that said auth service can know which services registered users are using.

The author is correct though. While a user that employs such an auth service, it can be good practice to hash the mail-address or even other identifiers for you own DB (you still need that to associate state with a user).

Re: You might not need to store plaintext email addresses

#63

Post by llimos »

We did this slightly differently. For login we stored a hash of the normalized email address (all lowercase, and handling gmail's dots and plusses). For sending emails we had them encrypted in a separate database, which only the mail-sending servers had access to - not the web-facing servers. That way we didn't need to ask for the email address every time, and it was still fairly well protected.

Re: You might not need to store plaintext email addresses

#64

Post by franky47 »

ThePhysicist wrote: post #27

In most cases, encrypting sensitive information like e-mail addresses with a memory-resident key (e.g. injected using tools like Vault) in the application layer is a better strategy, at least if you need asynchronous access to that information (e.g. to send out weekly update e-mails). Most of the data leaks in the past were caused by compromised or misconfigured databases, not by compromised application server code.…

This kind of encryption-at-rest scheme becomes an absolute necessity when cryptographic secrets have to be stored, such as 2FA TOTP secret keys or recovery codes.

Encrypting the email addresses and any Personally Identifiable Information on your users may also be a good practice, to limit which eyes can actually see the plaintext data (database provider, former developers without rotated credentials, an old backup left over..).

One issue with this though could be the inability to use the encrypted field for queries (eg: select * from users where email = 'foo@bar.com'), but OP's solution of hashing can help here: store the email encrypted, its hash in clear text, and do a query on the hash.

Re: You might not need to store plaintext email addresses

#65

Post by notimetorelax »

inopinatus wrote: post #19
opk wrote: post #17

Earlier quoted context omitted.

No it doesn't, convert the case when generating the hash – think of it as part of the hash function. But leave the case unchanged from whatever the user entered for any steps that involve sending an e-mail to the address.

That is what produces the first failure mode described, viz. bouncing email, when delivering to a case-sensitive mailbox.

Do you know of any servers that are case sensitive?

Re: You might not need to store plaintext email addresses

#66

Post by ryanlol »

cm2187 wrote: post #5

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.

This is not a reasonable use case for rainbow tables.

Re: You might not need to store plaintext email addresses

#67

Post by scrollaway »

Piskvorrr wrote: post #43
gpvos wrote: post #24

Earlier quoted context omitted.

True. But since so many websites (e.g. all aviation companies I've encountered) case-smash the LHS of the email address and can get away with it since all other email software has had to adapt, this is a rather minor concern by now.

By that logic, \.[a-z]{2,4}$ is still the correct way to match the TLD of an e-mail: "meh, it's obviously wrong, but everyone has to adapt."

You're trying to sound clever but it's not working, I don't think you understand what the logic actually is, if you are comparing those two.

A lot of emails get casefolded no matter what. This is enough of an inconvenience that nobody in their right mind would operate a case sensitive mailbox you would be using for account signups.

Re: You might not need to store plaintext email addresses

#68

Post by trengorilla »

Hitton wrote: post #35
opk wrote: post #13

Earlier quoted context omitted.

People often forget usernames but not so often e-mails. The e-mail is usually the primary/only means of identifying users anyway so you're not going to provide it back on request anyway.

They won't forget the email, but they might easily forget with which email they registered (happened to me).

How many e-mails could you possibly have that makes trial and error not a good solution in this scenario?

Re: You might not need to store plaintext email addresses

#70

Post by whatatita »

loremipsumsum wrote: post #46
berdario wrote: post #44

Earlier quoted context omitted.

> No — many accounts aren’t created by the people that use them Can you elaborate on this? I can only think of 2 examples, but neither seem like good ones: 1- someone holds power of attorney over someone else, and register an account (email account?) in their name. But if there's PoA involved, the 2nd person isn't (probably ?) able to manage an email account on their own, so this doesn't seem a meaningful distinction…

3- Work e-mail is usually created by IT and users have no influence over it.

4 - school and academic emails are also often created the same for as work emails; following a Policy without any user involvement.
Post reply on HN