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

191–200 of 405 posts

Re: The Correct Way to Validate Email Addresses

#191

Post by alcari »

seanp2k2 wrote: post #189
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…

For more fun, try putting a "--" (two consecutive hyphens) in many fields in the AWS console. Not allowed, I guess because they're passing it to shell commands somewhere along the line?!

Not likely. That's the comment start marker in many dialects of SQL.

For commands, shell metacharacters like `, |, &, and $() are much more important.

Re: The Correct Way to Validate Email Addresses

#192

Post by Roedou »

parennoob wrote: post #64
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 ;)

Can you name some popular websites that do this? Speaking as someone who uses + addresses to filter stuff from mostly well-known websites, I have never seen this. I have seen this a few times on old, crusty, finance websites etc. but I hardly ever need to use a + address with them anyway. (It does make me wonder about how good their internal security is, though.)

IIRC, Chipotle's Chiptopia promotion this summer allows users to sign up with a + in their email address, but not log in or do a password reset.

Re: The Correct Way to Validate Email Addresses

#193

Post by Hydraulix989 »

ryandrake wrote: post #35
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 ;)

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

Even Linux tools like GNOME Archive Manager in Linux Mint 18 rejected my RAR password containing a $ as the incorrect password, even though it was the correct password for the RAR file I was trying to extract. I then used the command-line unrar utility with the exact same password, and it extracted successfully.

Now, why would you preemptively (and explicitly) throw out a candidate password string based on its characters?

At least make the validation consistent.

I also had trouble with connecting to a wifi network with a WPA password containing an ampersand in Arch Linux using the Arch Wiki's recommended command line network manager utility (netctl, if my memory serves me correctly), and I tried all sorts of ways of escaping it and quoting it in the configuration file.

The Arch devs on IRC just told me to change my AP settings so that the wifi network doesn't use a password containing an ampersand character. Well, that would have been a good idea, but it wasn't my network, so I didn't have the ability to change its WPA password.

Re: The Correct Way to Validate Email Addresses

#194

Post by cimnine »

buro9 wrote: post #190

The best way to validate an email address: Send an email that they need to click on (or an email with a code they need to enter), OR ask the OAuth provider with authority for it to validate it (i.e. Google Oauth for Google addresses, Windows Live for Microsoft Accounts, etc). The best way to identify someone with an email address: Store a canonical version of their email address alongside the users email. Use the can…

Just make sure the (canonical) email address is not the primary identifier for the user, as email addresses may change over time.

Re: The Correct Way to Validate Email Addresses

#195

Post by justinlardinois »

buro9 wrote: post #190

The best way to validate an email address: Send an email that they need to click on (or an email with a code they need to enter), OR ask the OAuth provider with authority for it to validate it (i.e. Google Oauth for Google addresses, Windows Live for Microsoft Accounts, etc). The best way to identify someone with an email address: Store a canonical version of their email address alongside the users email. Use the can…

> This is the only way to not have duplicate accounts for firstlast@googlemail.com vs first.last@googlemail.com vs first.last@gmail.com .

Periods being optional in usernames is something that Gmail started, not a universal rule or part of the specification. Are you going to build into your system all the possible variations for every email provider?

Re: The Correct Way to Validate Email Addresses

#196

Post by Tomte »

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 agree that it's annoying.

But I have an acquaintance who is constantly bickering and venting about this issue. If he strongly suspects that a signup form will reject his plus address, he will enter it even more fervently to prove they are idiots.

I'm firmly on the side of "Too bad. Maybe you could simply move on with your life? Just use a dash if you need sub-mailboxes"

Re: The Correct Way to Validate Email Addresses

#197

Post by nomel »

jwecker wrote: post #72
lstamour wrote: post #70

Earlier quoted context omitted.

Then reject email addressed to localhost. It shouldn't matter how the email got there. I'd suggest that especially given DNS trickery involving setting up a low TTL then redirecting to 127.0.0.1, you're probably not preventing this from happening or you'd have to invalidate any unrecognised domain. Better to solve that problem at a different layer -- validate the email by sending a validation link if you must...

True, but that's my point- it's a backend issue, not a front-end "help the user" issue.

And their point is, it's a backend issue, the backend being the mail client/server that already completely handling the sending/receiving of emails. Either the activation link gets clicked or it doesn't. The click is the only correct validation, and yes, the whole process happens on the "backend".

Re: The Correct Way to Validate Email Addresses

#198

Post by nicolas_t »

The one thing I systematically do in term of email validation is catch the common typos of the main providers. So things like gmail.con, hotmai.com, gmall.com and so on.

In 99% of those cases, it prevents someone from entering a wrong email.

We do not do email activation by forcing people to click a link in their email to validate that they received it since that causes a drop in the funnel and reduces the amount of revenues (non technical users tend to not come back when you ask them to go to their emails to verify it). So, in this case, correcting the typical typoes is very important. In our case though the information is not extremely private so it's less of a problem to do this.

Having people type the email twice doesn't really prevent typoes, people copy and paste. And if you disable paste, then it becomes annoying to users and you don't want to annoy users during the signup process (plus I hate websites that mess up with paste so I won't be hypocritical and do it).

Lastly, I know that having an email with a local domain name with no TLD is valid but it'll never be valid in the context we are sending so supporting them just doesn't make sense.

Re: The Correct Way to Validate Email Addresses

#199

Post by Zancarius »

andreareina wrote: post #188
Zancarius wrote: post #187

Earlier quoted context omitted.

> I don't think that is true at all. I've run into a couple of sites that reject passwords containing ', %, and other special characters that suggest there may be some truth to it. If you're scrubbing input as if it's about to be insert into a database via SQL, then there's really only two possibilities. Either a) you're running legacy code that still does the check and does blind escaping (which has its own set of i…

Or they're cargo-culting on decades of experience where special characters are verboten.

Hah, good point. Although I do have to wonder: When does it turn into filtering by force of habit? After all the legacy cruft has long been forgotten and is no longer maintained?

Re: The Correct Way to Validate Email Addresses

#200

Post by buro9 »

justinlardinois wrote: post #195
buro9 wrote: post #190

The best way to validate an email address: Send an email that they need to click on (or an email with a code they need to enter), OR ask the OAuth provider with authority for it to validate it (i.e. Google Oauth for Google addresses, Windows Live for Microsoft Accounts, etc). The best way to identify someone with an email address: Store a canonical version of their email address alongside the users email. Use the can…

> This is the only way to not have duplicate accounts for firstlast@googlemail.com vs first.last@googlemail.com vs first.last@gmail.com . Periods being optional in usernames is something that Gmail started, not a universal rule or part of the specification. Are you going to build into your system all the possible variations for every email provider?

> Are you going to build into your system all the possible variations for every email provider?

I've analysed my user database and am only doing the large providers for which I have high confidence.

Post reply on HN