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

The Correct Way to Validate Email Addresses

hackernoon.com

Post reply on HN
Print view View original

171–180 of 405 posts

Re: The Correct Way to Validate Email Addresses

#171

Post by toomanybeersies »

mschuster91 wrote: post #91
ryandrake wrote: post #35

Earlier quoted context omitted.

Even worse is rejecting my password because it has a + in it! Why do you as a business care what my random password generator spit out?? Scarier still is when it's a server-side response that rejects my password for its contents...

> Scarier still is when it's a server-side response that rejects my password for its contents... A friend's project decided to disallow umlauts, combined characters like ´e (can't type the correct e with accent mark), the pipe symbol and a couple more in new passwords. Not due to plaintext storage or so, but because of customer service issues - people were bugging support all the time because they were e.g. abroad an…

There's a pipe symbol on my keyboard.

By pipe, you mean "|", right?

Re: The Correct Way to Validate Email Addresses

#172

Post by [deleted] »

tempestn wrote: post #154
Benjamin_Dobell wrote: post #30

The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)

I recently registered [mylastname].email, thinking to switch over to firstname@lastname.email from my gmail address. Turns out a large percentage of forms don't accept new TLDs.

[deleted]

Re: The Correct Way to Validate Email Addresses

#173

Post by justinpombrio »

brianwawok wrote: post #166
pwg wrote: post #61

Earlier quoted context omitted.

Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text. Why: Because if they were (at least) hashing it the output from the hash would be a binary string in which case they would have to be 8-bit clean through to the DB column where the hash output resided, and then there wou…

> Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text. I don't think that is true at all. I may very well want to put a few simple rules I validate serverside, such as 1) No username in password 2) No email in password 3) No list of 100 most common passwords in password Al…

All of those checks can easily be done client-side, though. Of course this means you can't guarantee that none of these rules are violated, but I suspect that the users capable of bypassing this aren't the ones you're concerned about anyways.

Re: The Correct Way to Validate Email Addresses

#174

Post by LordKano »

vidarh wrote: post #170
LordKano wrote: post #160

Earlier quoted context omitted.

A former employer, that I will decline to mention by name, stored a hash of the password AND the plaintext in the database so it could be sent to people via email when they forgot it. I tried to explain to my boss why this was such a terrible idea and he was not hearing any of it.

If I ever use the "forgot my password" functionality at a site and they mail out something that is probably my original password, I make a point of cancelling my account and sending them an e-mail explaining why I don't trust them any more.

Yeah. As a former employee, I will not recommend them to anyone who is looking for services in that particular arena.

Re: The Correct Way to Validate Email Addresses

#175

Post by jcranmer »

developer2 wrote: post #161
kazinator wrote: post #95

Sorry, I disagree. There is absolutely is a correct way to lexically validate an e-mail address: namely, implement a parser for the syntax specified in whatever RFC is the up-to-date successor of RFC 822. There is such a thing as incorrect e-mail address syntax: namely, non-RFC-conforming syntax, whatever that is. You may reject that, and that's about it. Please don't reject RFC-conforming e-mail addresses.

I agree, with two specific exclusions: notations for IP addresses in square brackets, and comments. Just removing those two never-encountered-in-real-life syntaxes reduces the RFC regex down to nothing. Comments are not a real thing, RFC be damned. And square bracketed IP addresses are never encountered in the real world, especially with the requirements for PTR records to pass all the major providers' spam filters.…

Email addresses are defined and have an interpretation not according to RFC 5322 (which defines how you can write them in a message), but rather RFC 5321 (which defines how to route email addresses). Note that the RFC 5321 definition does not permit CFWS--its existence is merely an artifact in RFC 5322 of being able to insert whitespace (and later comments) anywhere in the grammar. Any tool which accepts CFWS in an email address that is not reading an addr-spec field of an RFC 822 mail message is incorrect.

Beyond the issue of comments, I'd advocate rejecting the use of IP address literals and quoted localparts. Additionally, despite the injunctions on interpreting local-parts, in practice, it is best to treat email addresses as case-preserving: you'd consider a@example.com and A@example.com to be the same email address, but if the user typed in the latter, don't normalize it to the former.

Re: The Correct Way to Validate Email Addresses

#176

Post by vidarh »

AgentME wrote: post #134
rickycook wrote: post #38

Earlier quoted context omitted.

scarier still is when they let you set it but fail to let you log in (generally happens more with length). i don't know what you're doing, but i know it's not right and it scares the hell out of me

I had that happen because of length at an online service we needed to use in high school. I believe my password had 9 characters. After requesting a password reset and experimenting I found that the registration form would allow you to enter a password of any length, but the login form would only accept up to 8 characters. What really shocked me was that I was the only one of my classmates that used a password longer…

Some places have been known to just truncate the password...

Re: The Correct Way to Validate Email Addresses

#177

Post by toomanybeersies »

tempestn wrote: post #154
Benjamin_Dobell wrote: post #30

The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)

I recently registered [mylastname].email, thinking to switch over to firstname@lastname.email from my gmail address. Turns out a large percentage of forms don't accept new TLDs.

It's because a lot of regex validations (including earlier versions of Angular) have a regex that ends in something like

\.[A-Za-z]{2,4}$ (this is the end of the regex in Angular 1.15, it also doesn't support brackets or quotes in the local part, poor showing from Google)

At the time when they were written, gTLDs didn't exist, so the longest a tld could be was 4 characters (.info, .mobi). It's pretty piss poor futureproofing to be honest.

Re: The Correct Way to Validate Email Addresses

#178

Post by ubernostrum »

wtbob wrote: post #37
tedmiston wrote: post #20

Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input. Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else. Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for examp…

> Sure, the complete regex is complex, but it is defined and is hardly unconquerable. If it is a regular expression, then it is not able to match all valid email addresses, because the grammar of email addresses is context-free, and regular expressions can only match regular grammars. It doesn't matter if it is defined or not: if it's a true regular expression, then it simply cannot validate email addresses. (it may,…

I wonder if the django validator will choke on perfectly valid email addresses such as (this)"()[]:,;@\\\"!#$%&'-/=?^_`{}| ~.a"(is)@(valid)example.org(honest)

If it doesn't, remind me to patch it to not accept that.

I have strong views on email validation, and they include telling people who use that kind of address to go register on someone else's site.

Re: The Correct Way to Validate Email Addresses

#179

Post by vidarh »

tempestn wrote: post #154
Benjamin_Dobell wrote: post #30

The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)

I recently registered [mylastname].email, thinking to switch over to firstname@lastname.email from my gmail address. Turns out a large percentage of forms don't accept new TLDs.

I co-founded the company that set up the ".name" TLD as part of the first batch of new TLDs back in 2001, and we had no ends of problems because of that.

A lot of people either had hardcoded lists, or they checked the length and refused TLDs longer than 3 characters. We kept e-mailing people about it, and kept getting messages back from people who had "fixed" it by adding just us (we'd generally have pointed people to articles listing other new TLDs too, to make it clear to them that this wasn't just one TLD), or increasing the limit to 4 characters... We quickly gave up on trying to get these people to stop having useless checks and settled for just getting them to accept ours.

It's quite shocking people still haven't learnt even after the number of expansions since.

Re: The Correct Way to Validate Email Addresses

#180

Post by vidarh »

toomanybeersies wrote: post #177
tempestn wrote: post #154

Earlier quoted context omitted.

I recently registered [mylastname].email, thinking to switch over to firstname@lastname.email from my gmail address. Turns out a large percentage of forms don't accept new TLDs.

It's because a lot of regex validations (including earlier versions of Angular) have a regex that ends in something like \.[A-Za-z]{2,4}$ (this is the end of the regex in Angular 1.15, it also doesn't support brackets or quotes in the local part, poor showing from Google) At the time when they were written, gTLDs didn't exist, so the longest a tld could be was 4 characters (.info, .mobi). It's pretty piss poor future…

Angular didn't even exist when the first expansion happened, so either they were flat out ignorant, or they copied an earlier regex without verifying it (.museum was part of the initial batch of new gTLDs in 2001)
Post reply on HN