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

131–140 of 181 posts

Re: You might not need to store plaintext email addresses

#131

Post by laszlokorte »

inopinatus wrote: post #29
laszlokorte wrote: post #25

Earlier quoted context omitted.

But wouldnt the user face this issue all the time if they have a case sensitive mailbox but type their own address in the wrong case? So the assumption may be that a user with a case sensitive mail box is used to typing in the correct address?

No — many accounts aren’t created by the people that use them, and in any case we shouldn’t be relying on correct repeated string input and then blaming the user for a fulfilment process failure due to a typo from hours ago that we silently accepted at the time, and (worse) we can’t even distinguish between a capitalisation error and a discontinued recipient, even if it was previously verified. As designers/developer…

Okay... so how is this issue currently handled? Say I create a new email account: lAsZlO@inopinatus.com and the mailbox is case sensitive.

Next I create a youtube account but as E-Mail address I enter laszlo@inopinatus.com and I am told to click the link in the confirmation E-Mail... that I never receive. Well I do not like youtube anyway so I head over to hackernews and create an account to write this comment. Oh no I can not because I typed my E-Mail address in lowercase again. So now I am wondering if there is some error so I open your homepage, search for the support page and file a bug report, typing my E-Mail address in lowercase into the E-Mail field. I never receive your response telling me to write my E-Mail address in the correct casing. I come to the conclusion that my E-Mail account just does not work and create another one at a provider that is case insensitive. OR I figure out/am told that the case is important and will never forget it again.

So where exactly are services like youtube or hn that ask me for my E-Mail responsible for handling upper/lower case correctly? The solution could still be: store both the hash for the canonicalized address and the hash of the exact address of which you know that it worked at some point in time. If the user enters the address later the matches the one but not the other issue a warning that should they not receive the E-Mail to double check their spelling.

Re: You might not need to store plaintext email addresses

#132

Post by pkulak »

toyg wrote: post #124
gregoriol wrote: post #104

This would not work for any serious/useful service: e-mails are not only for marketing, there are many good reasons to send one like (user requested) notifications, invoicing, ... and also screw-ups! If your service had a problem (security, broken data, invoicing again, long downtime, ...), you better contact your users before they find out on hackernews.

Even just a very thin encryption layer would probably do a decent job. Attackers are typically going at it from an infrastructure perspective: they make a hole, poke around for basic configuration info, locate the database, and siphon it out. They may or may not have enough time and knowledge to reverse-engineer a basic column-specific symmetric scheme. The only drawback is that such scheme must then be made availabl…

Not any system that consumes the database, just any system that needs to send email. Unless you are using the encryption for other fields as well, I suppose.

Re: You might not need to store plaintext email addresses

#133

Post by voiper1 »

ajanuary wrote: post #52
mantap wrote: post #50

Earlier quoted context omitted.

Says who? Email addresses are case insensitive. If email software treats emails as case sensitive then it is broken. People have to write email addresses on paper forms, in all caps.

Says RFC 5321 [1]: "The local-part of a mailbox MUST BE treated as case sensitive." It _does_ recommend receivers treat it as case insensitive for maximum interoperability, so it is de facto insensitive, but something implementing it as case sensitive isn't broken. [1] https://tools.ietf.org/html/rfc5321

huh, TIL email addresses can be case sensitive.

Re: You might not need to store plaintext email addresses

#134

Post by edoceo »

notimetorelax wrote: post #65
inopinatus wrote: post #19

Earlier quoted context omitted.

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?

Postfix. In the local user case. Alias and Virtual are not but local accounts are (because username is case sensitive)

https://serverfault.com/questions/969671/postfixdovecot-case...

Re: You might not need to store plaintext email addresses

#135

Post by PostThisTooFast »

gregoriol wrote: post #104

This would not work for any serious/useful service: e-mails are not only for marketing, there are many good reasons to send one like (user requested) notifications, invoicing, ... and also screw-ups! If your service had a problem (security, broken data, invoicing again, long downtime, ...), you better contact your users before they find out on hackernews.

But nobody should be forcing people to use E-mail addresses AS USER IDs!

So dumb.

Re: You might not need to store plaintext email addresses

#136

Post by edoceo »

jmnicolas wrote: post #94
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.

Why would you go to the trouble of not enabling Facebook login (as long as you provide other logins methods of course)? If someone is using Facebook & Facebook login they clearly don't mind being tracked by Facebook. I don't have a FB account fwiw.

If you enabled FB in your app, then publish to Apple/iOS they then say you must support Apple based SSO. But email only avoid this Apple heavy-hand

Re: You might not need to store plaintext email addresses

#137

Post by nulbyte »

cblconfederate wrote: post #99
mischanix wrote: post #71

The more important takeaway from this article for me is that sites should be hashing the Facebook user ID, since it's often far more personally-identifiable information than an email address.

Id is already hashed per-app from facebook's side

The article points out that this doesn't maintain privacy:

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

Re: You might not need to store plaintext email addresses

#138

Post by gpvos »

adrianmonk wrote: post #100
inopinatus wrote: post #12

This scheme struggles in the face of email address case folding. At the protocol level, email addresses are case-folded on the RHS but case-sensitive on the LHS. So it’s crucial that LHS case is preserved by delivery systems. Unfortunately most users then treat them as folded on both. So you can successfully verify one variant, store the downcased hash, and it’ll subsequently match but delivery bounces. Or, hash the…

I thought email addresses were case folded on the right hand side and site dependent on the left hand side. The right hand side is more or less forced by the rules of DNS. As for the left hand side, if I run the email for a site, can't I decide whether to deliver ABC@ and abc@ both to the same mailbox or to different mailboxes? And can't someone else make a different decision for their site? If a site administrator d…

Of course, but when processing an arbitrary email address, which will almost always be not on your site, you MUST treat the left hand side as case-sensitive (unless you have knowledge about that email domain).

Re: You might not need to store plaintext email addresses

#139

Post by gpvos »

mantap wrote: post #50
inopinatus wrote: post #12

This scheme struggles in the face of email address case folding. At the protocol level, email addresses are case-folded on the RHS but case-sensitive on the LHS. So it’s crucial that LHS case is preserved by delivery systems. Unfortunately most users then treat them as folded on both. So you can successfully verify one variant, store the downcased hash, and it’ll subsequently match but delivery bounces. Or, hash the…

Says who? Email addresses are case insensitive. If email software treats emails as case sensitive then it is broken. People have to write email addresses on paper forms, in all caps.

You, and the paper forms, are incorrect. In fact, on such forms, you should use the proper case for your email address, otherwise you are entering an incorrect address, which may be fraud.

Re: You might not need to store plaintext email addresses

#140

Post by nwsm »

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

This sounds like terrible UX, not to mention email use cases not initiated by the user. I really think you'd be shooting yourself in the foot by setting up a small site with this philosophy because you don't need emails right now

Post reply on HN