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

221–230 of 405 posts

Re: The Correct Way to Validate Email Addresses

#221

Post by midgetjones »

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

If they refuse it, I think it's generally because they _know_ you're filtering them, and don't want you to sign up with a single-use address. In which case I don't bother signing up because I know they'll be spamming.

Also, there's always https://mailhero.io/

Re: The Correct Way to Validate Email Addresses

#222

Post by Freak_NL »

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

> Scarier still is when it's a server-side response that rejects my password for its contents...

Why? Assuming that you have established a secure connection with that server (i.e., HTTPS by means of TLS), then it is perfectly fine for the server to check, at the time you are setting the password, if your password confirms to the rules established. And when the password turns out to be suitable, it is okay for the password to be sent to the server as-is.

Now it goes without saying that as soon as you have picked a suitable new password, that the server will store only a (proper) hash — by using BCrypt for example. At no time is the plain text password stored anywhere, and any proper HTTP API will send the password via POST to prevent it from being logged in the server's access logs (which is where it could end up if sent as parameter via a GET request).

There are plenty of services that screw up and try to apply nonsensical rules (such as limiting the length of the password to anything less than, say, 256 characters), but in general this is done to prevent weak passwords. You can't exclusively do this client-side, because in security terms, the client cannot be trusted to actually apply the validation and to generate a proper hash; the client can be bypassed. Of course the client can and should validate any input before the server gets to it, so ideally the server need not even come into it during validation, but the server has the final word.

As user though, you have the responsibility of not reusing passwords anywhere (and you don't, because you sensibly use a password generator as you mention). Don't assume that any service handles security well.

Re: The Correct Way to Validate Email Addresses

#223

Post by Freak_NL »

Zancarius wrote: post #199
andreareina wrote: post #188

Earlier quoted context omitted.

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?

Because the other monkeys will chew you out if you start doing it differently all of a sudden. Nobody knows exactly why we're doing it the way we are doing it, but it is complex, and changing it might break something.

It's the five monkey experiment:

http://johnstepper.com/2013/10/26/the-five-monkeys-experimen...

Re: The Correct Way to Validate Email Addresses

#224

Post by Tomte »

mulmen wrote: post #210
Tomte wrote: post #196

Earlier quoted context omitted.

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"

Is a dash the same as a "+"? According to some quick googling it depends on your provider. If his provider relies on the "+" for sub-addressing what good will a dash do him? Why are you so firm on this position when it seems to be a legitimate problem for him?

Yes, it depends on the mail provider.

What is easier and better for your nerves? Moving to another mail provider or getting worked up for years?

Or if moving is not an option: how about stop wasting time and nerves on it? Just accept that your mail address doesn't work everywhere. There is no possible uture where you will force everyone on earth to stop mis-validating email addresses!

And I've never disputed that the problem is legitimate. I actually said in my comment!

Re: The Correct Way to Validate Email Addresses

#225

Post by Freak_NL »

kiallmacinnes wrote: post #108
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…

Or, they submit the password over HTTPS, validate server side, then hash and store in the DB? There is no reason to assume rejecting of a + means they don't hash, and browsers escape the password for you in POST/GET etc. The fact that + is used for space really isn't relevant. (That said, I think it's pretty stupid to "validate" passwords beyond checking for "12345", "password", a min length, and other public info. e…

> Anything any password generator spits out, so long as it meets the min length criteria, should be accepted

It annoys me to no end when I have to hand-craft a password to stay within the silly rules of some service.

Be vocal about this! Keep complaining to the services you use that don't accept such valid passwords. Banks for example are notorious in insisting on short passwords and arcane limits on which characters to use (ING in the Netherlands limits you to 20 characters, and nobody there seems to be able to explain why).

Re: The Correct Way to Validate Email Addresses

#226

Post by Arnt »

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 scrub ; from ALL arguments before considering what kind of argument it is instead of scrubbing only where that might be needed.

Re: The Correct Way to Validate Email Addresses

#227

Post by rikkus »

vidarh wrote: post #176
AgentME wrote: post #134

Earlier quoted context omitted.

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

I see this all the time. They accept it and then when you go to log in, it fails. I usually try chopping it down to 32, 30, 24, 20, ... until I hit a match.

Re: The Correct Way to Validate Email Addresses

#228

Post by Freak_NL »

nicolas_t wrote: post #198

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…

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

That can be helpful, but I assume you suggest the user that they may have made a typo and not flat out reject the input?

> […] having an email with a local domain name with no TLD is valid but it'll never be valid in the context […]

Well, depending on how the fairly recent brand generic top-level domains work out, I would not rule out someone actually using ceo@cocacola at some point (until the CEO of Coca-Cola realises that legacy email validation regexes mean a suspiciously quieter then usual inbox).

Re: The Correct Way to Validate Email Addresses

#229

Post by creshal »

Freak_NL wrote: post #222
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... Why? Assuming that you have established a secure connection with that server (i.e., HTTPS by means of TLS), then it is perfectly fine for the server to check, at the time you are setting the password , if your password confirms to the rules established. And when the password turns out to be suitable, it is okay for the pa…

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

Re: The Correct Way to Validate Email Addresses

#230

Post by zAy0LfpBZLC8mAC »

vacri wrote: post #212
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.

I mean unique as far as your end is concerned. Short of very invasive technology, there's no way to stop people from sharing a user token if they choose to do so.

Except, it's not a "user token", it's an address. It's as much a user token as a postal address or a telephone number is a "user token": not at all. It's a way to contact a person, not a way to identify a person. Just because you can enforce that only one person with a given postal address can create an account with your service, doesn't make it an inherent "user token".
Post reply on HN