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

181–190 of 405 posts

Re: The Correct Way to Validate Email Addresses

#181

Post by toomanybeersies »

GirlsCanCode wrote: post #84
Ameo wrote: post #40

I have a .link domain for my personal email and a lot of sites refuse to let me register because they don't recognize it as a valid TLD. Then there's the textbook company that lets me register but refuses to let me reset my password claiming that I'm trying to enter an "invalid email address."

I had a .to domain for a while, and I had an email address "firstname@firstname.to" where firstname is my first name. I wanted to use it when I needed to give out emails causally, like if someone from Church or some other group wanted my email. I gave up on it, not because of computer validation but because of stupid people! Nobody would "get" the .to domain and they'd always think there should be a .com or .gmail.co…

I'm discovering the same problem with my *.xyz domain name.

Re: The Correct Way to Validate Email Addresses

#182

Post by adrusi »

justinpombrio wrote: post #173
brianwawok wrote: post #166

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

The server does have to have access to the plain text password in memory, you know. I don't see why you think it's worth sacrificing guarantees of password strength to uphold some kind of taboo.

Re: The Correct Way to Validate Email Addresses

#183

Post by mabcat »

niij wrote: post #164
zAy0LfpBZLC8mAC wrote: post #75

Earlier quoted context omitted.

> email addresses for usernames have the advantage of already being unique Not true. There are people who share an email address.

Care to expand? As in having a first.last@example versus firstlast@example

As in bloggsfamily@localisp.net.au that both parents and all the younger sprogs share. Still common as anything.

Re: The Correct Way to Validate Email Addresses

#184

Post by pcl »

niij wrote: post #164
zAy0LfpBZLC8mAC wrote: post #75

Earlier quoted context omitted.

> email addresses for usernames have the advantage of already being unique Not true. There are people who share an email address.

Care to expand? As in having a first.last@example versus firstlast@example

Probably the most common example these days is spouses who don't email regularly.

Once upon a time, you only got one or two email addresses from your email provider (I'm looking at you, CompuServe and AOL), so at that time it was common for everyone in a family to have a single address. Eventually they added explicit multi-user features -- IIRC, AOL went as high as 5 emails per account before my family moved on.

Re: The Correct Way to Validate Email Addresses

#185

Post by roywiggins »

zAy0LfpBZLC8mAC wrote: post #75
vacri wrote: post #74

Earlier quoted context omitted.

email addresses for usernames have the advantage of already being unique. None of this "gregmac already taken, try gregmac23, gregmc_595, or verbingnounXX instead?" nonsense

> email addresses for usernames have the advantage of already being unique Not true. There are people who share an email address.

I have family who share one email between two spouses. They might maintain separate personal email addresses; probably not, though.

Re: The Correct Way to Validate Email Addresses

#186

Post by deathanatos »

wtbob wrote: post #114
deathanatos wrote: post #68

Earlier quoted context omitted.

> the grammar of email addresses is context-free I don't think you're really correct about "email addresses" being context-free, or at least, citation, please? When I look at a generic "email address" entry field on a random form on the Internet, say on the sign-up page for some hot new startup's service, I expect it to take what RFC 5322 §3.4.1[1] calls an `addr-spec`; specifically, I don't ever expect such fields t…

> I don't think you're really correct about "email addresses" being context-free, or at least, citation, please? > When I look at a generic "email address" entry field on a random form on the Internet, say on the sign-up page for some hot new startup's service, I expect it to take what RFC 5322 §3.4.1[1] calls an `addr-spec`; specifically, I don't ever expect such fields to take the grammar of what that RFC calls an…

Oh, shoot, I missed that. I saw "FWS" (meaning "folding white space"), and assumed that didn't include comments since they have nothing to do with folding whitespace.

Well done.

Re: The Correct Way to Validate Email Addresses

#187

Post by Zancarius »

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…

> 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 implications) or b) you really truly are storing passwords as plain text.

Re: The Correct Way to Validate Email Addresses

#188

Post by andreareina »

Zancarius wrote: post #187
brianwawok wrote: post #166

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

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

Re: The Correct Way to Validate Email Addresses

#189

Post by seanp2k2 »

pwg wrote: post #61
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...

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?!

Re: The Correct Way to Validate Email Addresses

#190

Post by buro9 »

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 canonical version when signing-in/identifying and the raw version originally supplied to send email.

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

The canonical email is always lowercase, no dots, no + part, no prefix or suffix columns, known domain aliases are normalised to the most common alias (googlemail.com > gmail.com).

I wrote a SQL canonical email func recently (in preparation for Persona shut-down) if anyone is interested: https://github.com/microcosm-cc/microcosm/blob/master/db/mig...

Post reply on HN