The Correct Way to Validate Email Addresses

Post by pixl97 » Thu, Sep 08, 2016, 2:07 PM UTC

throwanem wrote: post #274

zAy0LfpBZLC8mAC wrote: post #272

Earlier quoted context omitted.

> 'Non-routable' as in a single label, or as in not resolvable. I don't think it is unreasonable to consider an address invalid when its domain part cannot be resolved. What exactly do you mean by "cannot be resolved"? > Checking for RFC1918 ranges means you don't try to send to another class of addresses that's never going to be received. But why check for it? Is that actually a common mistake people make? An attack…

"Cannot be resolved" means NXDOMAIN. Why assume email addresses only get checked in one place, and not all? Ten million a day was a milestone. I left that company over a year ago; it would astonish me to find that figure now exceeded by less than a factor of twenty. Granted these are mostly not signups. They are outgoing emails nonetheless, which makes the case germane despite that superficial distinction. Your propo…

Post by Bartweiss » Thu, Sep 08, 2016, 2:08 PM UTC

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

Post by NoGravitas » Thu, Sep 08, 2016, 2:08 PM UTC

kasparsklavins wrote: post #277

creshal wrote: post #229

Earlier quoted context omitted.

> At no time is the plain text password stored anywhere Hopefully. When I see rules limiting passwords to 16 characters and disallowing SQL special characters, I'm having doubts.

My bank limits passwords at 15 characters. The best thing? There is no verification, it just cuts off. Have fun figuring out why you can not login anymore.

Post by Bartweiss » Thu, Sep 08, 2016, 2:12 PM UTC

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…

Post by Bartweiss » Thu, Sep 08, 2016, 2:14 PM UTC

warfangle wrote: post #244

arielb1 wrote: post #237

Earlier quoted context omitted.

No it doesn't. You can perform the first pass of salted hashing on the client-side. This should not harm security, but it can improve it if someone on the datapath is logging requests but does not alter them.

Isn't that what SSL does? And if the SSL between you and the destination is compromised, you don't even know if the hashing algorithm you asked the client to use is actually the one they used.