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

151–160 of 181 posts

Re: You might not need to store plaintext email addresses

#151

Post by [deleted] »

pc86 wrote: post #128
crazygringo wrote: post #123

Sidenote, but I find this post maddening to understand, because the author seems to be using the word "e-mail" to mean both "e-mail address" and "e-mail message", and then uses ambiguous pronouns to boot: > In conclusion, if you only use emails for transactional emails, you might be able to only store hashed versions of them. HUH? The most obvious way to interpret this sentence is as storing hashed versions of transa…

"Most obvious" only if you make the conscious decision to ignore the context of the entire article, maybe. The author isn't a native English speaker.

[deleted]

Re: You might not need to store plaintext email addresses

#152

Post by Mandatum »

Yeah with data breaches becoming more and more common, I really think it's irresponsible to not have a way of contacting your users. Sure, you could throw a banner up on your website - but the comms should be immediate.

This might be reasonable for a service that doesn't sell anything, or there's absolutely nothing owed to users and users have no reasonable expectation of privacy. But any commercial or professional organisation that doesn't have a method for contacting end-users is either A. Shady as fuck (numbered accounts, darknet-hosted, ignorance by design), or B. irresponsible.

This is a website who's pure purpose is to extract PPC/ad and referral revenue from its users. There's no personal information requested from users, other than "Display Name". This is actually one of few exceptions I think the owner of the website is being more responsible with their user's data by not keeping anything.

However, if they are breached and are serving malware to customers for a week before realising, they will have no way to tell their users they may have been affected. Or what if someone decides to install a backdoor and log the user's email and password when logging in? This is nitpicking and honestly probably 1% of websites hacked in this way actually notify their customers, but it's nevertheless still a hole in the design.

They're also likely capping their earning potential if they do plan to sell the website, as they don't have any delicious user data to sell to marketers.. For which I commend Daniel and Bjorn! Well done.

I don't know, I'm thinking this is great, but also pretty bad. Maybe adding an opt-in for breach notifications would be useful, or having a third-party service to subscribe to breach notifications for the website would be the best of both worlds.

Re: You might not need to store plaintext email addresses

#153

Post by inopinatus »

feoren wrote: post #98
inopinatus wrote: post #29

Earlier quoted context omitted.

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…

Wait a second. Back up. Let's be clear here: the case you are talking about is the user entering their own email address incorrectly, and you're saying we as designers/developers should make a system that knows this and sends it to the correct email? What? Huh? If Person@place.com and person@place.com are two different recipients, how the hell is my application supposed to know which one you actually mean!?

The same way we deal with all email validation. Verify it once at application signup, then rely on the precise verified form.

It is unrealistic to expect end users to get the capitalisation of their email address consistently right. It is realistic to expect it to be done right at signup, since in the best practice case this’ll include a verification loop.

Re: You might not need to store plaintext email addresses

#154

Post by inopinatus »

whatatita wrote: post #70
loremipsumsum wrote: post #46

Earlier quoted context omitted.

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.

5- parental/grandparental accounts. What’s more, speaking from our own support mailbox, these are the folks most likely to miscapitalize their email address.

Re: You might not need to store plaintext email addresses

#155

Post by inopinatus »

ilammy wrote: post #33
inopinatus wrote: post #22

Earlier quoted context omitted.

It’s a neat idea but unfortunately RFC 6531 opened up the local part to most of UTF-8, so internationalised capitalisation is in the mix now. Ultimately I’ll never advise delivering to email addresses other than the precise octets of the one already verified, and this means the gold standard is always folding for match and uniqueness, but delivery precisely as verified. How about this: store the verified email addres…

> For extra jollies, only decrypt it on the client. Uh... How does that work if you need email address to send email to the user? If only the client is able to decrypt the addess, you will basically have to wait until the user connects and gives you the email (which your presumably never store long-term, handling it like you'd handle credit card numbers). That severely limits what you can do with an address. If you'r…

> That severely limits what you can do with an address.

Assuming we’re talking in the scope of the original article, that is exactly one of the intended constraints.

Re: You might not need to store plaintext email addresses

#156

Post by inopinatus »

harg wrote: post #84
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.

Isn't this problem orthoganal to storing hashed email addresses? You'll always have access to the email address the user typed in when you want to send a transactional email so you can perform whatever sanitization needs to be done at that point. How does storing the email in plaintext get around issues involving sending emails to case-sensitive mailboxes?

> How does storing the email in plaintext get around issues involving sending emails to case-sensitive mailboxes?

By the validation one performs at initial sign-up.

I’m implicitly saying it’s okay to require that an email address was entered with perfectly matched case at signup, which is validated by a code or link etc, and then be more forgiving about what you receive in all subsequent uses because it’s supportive of ordinary humans trying to use your product.

Re: You might not need to store plaintext email addresses

#157

Post by inopinatus »

mantap wrote: post #72
ajanuary wrote: post #52

Earlier quoted context omitted.

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

It does make it broken. Broken means not working. If your software refuses an email because it's in the wrong case then that software is broken. And quoting out of an RFC is not going to make users stop complaining. Email addresses are written i a variety of situations where preserving case is not possible. For instance on forms, or over the phone. If the IETF wants to ignore that then that's the IETF's problem, don'…

On the flipside, you’re trying to tell me I should be willing to accept a lower standard than I wish to, or that I’m used to, or that has been established for decades, because of some anachronistic bureaucrat, and my response to that is a short expletive.

Re: You might not need to store plaintext email addresses

#158

Post by icedchai »

edoceo wrote: post #134
notimetorelax wrote: post #65

Earlier quoted context omitted.

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

It depends on configuration. I doubt very many SMTP servers are case sensitive in this day and age. This is not the case on my Postfix servers. Sendmail was also case insensitive in its default configuration (though it has been many years.)

Re: You might not need to store plaintext email addresses

#159

Post by icedchai »

laszlokorte wrote: post #131
inopinatus wrote: post #29

Earlier quoted context omitted.

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 suspect you'll have difficulty creating a case sensitive email address on any public email service.

Re: You might not need to store plaintext email addresses

#160

Post by simonw »

hinkley wrote: post #149
simonw wrote: post #145

Some things that become difficult if you don't have a verified email address for your users: - Most common: a user has a support request because they can't get into their account (e.g. you have sign-in-with-Facebook and they lost their account there, or got banned). - Your authentication partner (again e.g. Facebook) disables your integration for some reason - someone reports your account as abusive (maybe maliciousl…

Between 'yes' and 'no' we could still have airgapped or at least segregated systems, where an email address is known, but only to the part of the system responsible for communication.

In larger systems that could be a reasonable way to build things.

Keeping email addresses in the "auth" microservice which has tighter security - blocking security team code reviews, a smaller team who are allowed to modify it for example.

Post reply on HN