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

161–170 of 181 posts

Re: You might not need to store plaintext email addresses

#161

Post by [deleted] »

strogonoff wrote: post #147
scoot wrote: post #146

Earlier quoted context omitted.

> “email” is interchangeably used to mean either the protocol, an address or a message "email" isn't a protocol. SMTP is though, and referring to RFC 5321 ("a specification of the basic protocol for Internet electronic mail transport"), section 2.3.11 [1], we see that: " As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail wil…

I stand corrected on the former, should’ve written “system” instead of “protocol”. As a frequent reader of technical blogs and reference documentation, I stand by my point that “email” alone is used to mean email address quite frequently.

[deleted]

Re: You might not need to store plaintext email addresses

#162

Post by jeromenerf »

Semaphor wrote: post #31
jeromenerf wrote: post #14

Storing email feels like a no-brainer for a system that needs to send messages to its customers. Some prefer phone numbers, which maybe provide stronger guarantees while being maybe not as long lasting. As an individual, the issue is that "anon" or "throw-away" emails are not that commoditized. I heard that "login with Apple" meant to provide an email proxy, hiding your real email, but I have not seen it deployed, ex…

how are wildcards not low maintenance?

Lack for a better word I guess. This is what I do for myself and my So, but this isn’t a commodity accessible to anyone directly by their email provider.

Re: You might not need to store plaintext email addresses

#163

Post by nicbou »

This is the sort of content I come on HN for. It introduced me to a possibility I haven't considered, and it's followed by an interesting debate in the comments. Thank you for sharing.

The most important caveat I can think of is the ability to inform irregular users about something important, either for legal or ethical reasons. For example, my note taking app is shutting down, and users might have important things stored there. I could also message them about a deprecated feature, a change to the ToS, or ironically a data breach.

Nonetheless, it's still a good idea and I'll keep it in mind.

Re: You might not need to store plaintext email addresses

#164

Post by moortaube »

diggan wrote: post #74
Kwpolska wrote: post #34

That might be in breach of the GDPR. In the event of a personal data breach, you need to tell the data subjects about the breach [0]. You can’t just put a notice on your page, since someone might not be using your service any more, but you still have their data. And GDPR aside, it is very short-sighted to assume you will never ever need to e-mail users on your own. [0]: https://gdpr-info.eu/art-34-gdpr/

You comment was dead, I vouched for it as it's a valid assumption that you have to notice users on breach. But in this case, it seems like the following applies (34.3.A from your link): > The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met: > the controller has implemented appropriate technical and organisational protection measures, and th…

I would totally agree with you, diggan. I understand it the same way.

Re: You might not need to store plaintext email addresses

#165

Post by GoblinSlayer »

renewiltord wrote: post #106
gfauchart wrote: post #81

Earlier quoted context omitted.

you need to reach your users in case of data breach, but what if you have zero “Personal Data” ? you could still hash the email I imagine

Well the hashed email is Personal Data. https://www.google.com/url?sa=t&source=web&rct=j&url=https:/... Sorry for the Google link, I can't figure out how to copy the direct link on Android Chrome.

Click the link, then copy the address from address bar, if it still exists.

Re: You might not need to store plaintext email addresses

#166

Post by Dagger2 »

inopinatus wrote: post #156
harg wrote: post #84

Earlier quoted context omitted.

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…

You could manage that with hashed emails by separately storing the case of letters in the user part, without storing which letters it's referring to. You could then apply that case to the user-provided email during checkout.

(You could probably actually do a pretty good job in most cases just by bruteforcing the possible combinations and seeing which one matches the hash, but the worse-case CPU cost would be bad for long emails.)

Re: You might not need to store plaintext email addresses

#167

Post by hinkley »

simonw wrote: post #160
hinkley wrote: post #149

Earlier quoted context omitted.

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.

Right? And especially in these event stream architectures we like to use now. We still use outbound mail queues don't we, if for no other reason than to control the blast radius of any bugs in the system.

I don't need to send you a mail, I need to tell the system that handles mail to send you a mail. As long as I spend a small amount of care on avoiding the Confused Deputy scenario (eg, open relay), that would work better and contain much of the PII to a low-traffic (network and, as you say, code delta) system.

Re: You might not need to store plaintext email addresses

#168

Post by GoblinSlayer »

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.

It can be a fairly thin encryption service that encrypts provided data but doesn't decrypt. Then you decrypt in rare cases when it's needed.

Re: You might not need to store plaintext email addresses

#169

Post by GoblinSlayer »

inopinatus wrote: post #156
harg wrote: post #84

Earlier quoted context omitted.

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…

If you have a method to validate email by bouncing, you just use it every time.

Re: You might not need to store plaintext email addresses

#170

Post by GoblinSlayer »

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…

If the email provider says that email addresses are case sensitive, then that's the truth you live with, it's not your system, not your design and you can't dictate other systems how they should work.
Post reply on HN