Live data from Hacker News

The Correct Way to Validate Email Addresses

hackernoon.com

321–330 of 405 posts

Re: The Correct Way to Validate Email Addresses

#321
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…

As much as I agree that most artificial limits on the passwords are silly, there's a reason for at least limiting to latin1 charset - or maybe even a bit stricter. How sure are you that strings are always unified the same way between the browser and hashing? Have you tested that you can login from a browser which prefers CJK encodings and each of the UTFs? From all browsers? Maybe it works, maybe your framework deals…

We reject Unicode control characters, surrogates, private use code points etc. Passwords are sent in a UTF-8 encoded JSON over TLS. They are normalized using NFC.

Re: The Correct Way to Validate Email Addresses

#322

Earlier quoted context omitted.

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

There is a key on my keyboard that produces a vertical bar (|) but the glyph on the key is a broken bar(¦). I think every keyboard I own is like that.

That could be confusing to someone who doesn't know better.

Re: The Correct Way to Validate Email Addresses

#323

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

As of a year or two ago, Garmin wouldn't accept email addresses with "+" signs in them when registering for some (but not all) of their services. I think they would let you register for the main Garmin Connect service, but not for their support forum or something. Leading to a nice situation where you couldn't get technical support via the forum for the same account you had created on Connect.

Interestingly, though, the support email address they had hanging around at the bottom of the login page actually routed to an engineer (somewhere), which was nice, although they did claim repeatedly that the "+" character wasn't valid in an email address, which is of course not true. I was floored just to get a response from my complaint, though, even though it didn't seem likely to lead to them fixing the problem.

Re: The Correct Way to Validate Email Addresses

#324
post #7
post #4

Earlier quoted context omitted.

Also relevant was, "If you have a well laid-out form with a label that says “email”, and the user enters an ‘@’ symbol somewhere, then it’s safe to say they understood that they were supposed to be entering an email address." In other words, it does make sense to check that they entered an '@' symbol somewhere, since it shows that they understood it was an email field. Any 'validation' beyond that is useless.

How about more than one @ sign? Does the email address spec exclude the possibility of more than one @ symbols?

The local-part may contain a quoted @: "@"@example.invalid is a valid email address.

@ signs are also permitted in comments: (ted@home)ted@example.invalid is also a valid email address.

Re: The Correct Way to Validate Email Addresses

#325
post #205

Earlier quoted context omitted.

I like activation emails, because it shows the website cares about being able to email me. Then again, I'm a technical user.

Oh, we do send a welcome email and actually include a link in the email to subscribe to the newsletter but we don't make it necessary to use the website.

In that case, I'd rather not have the site gather my email address at all. Just create an account with an arbitrary name (or no account at all) and let the user use the web site. As soon as an email address is connected to the account (or the user name itself is an email address), I'd rather have it verified.

But I can see how there may be other concerns (commercial or not) that interfere with this.

Re: The Correct Way to Validate Email Addresses

#326

Earlier quoted context omitted.

Definitely, I think email validation links are important too. However, it's pretty senseless to let an obviously invalid email address pass all the way through to that layer (and potentially get billed for sending messages to invalid email addresses).

1. There are no "obviously invalid email address[es]". 2. Getting billed for sending emails? WTF?

> There are no "obviously invalid email address[es]".

An email address which doesn't validate against the applicable RFC is ipso facto obviously invalid.

Validating against the RFC is somewhat complex though.

Re: The Correct Way to Validate Email Addresses

#327

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

Meet Time Warner Cable. Time Warner, which has an obscenity filter on their passwords. Enforced server-side! Bets on how long before those folks make the news for losing a hundred million unhashed passwords?

That is ridiculous. Why would you even filter passwords? It's not like it is public, unless you are planning on making it so.

Re: The Correct Way to Validate Email Addresses

#328
post #120

At this point, our email validity criteria: .+@.+\..{2,} That is, at least one character for the inbox, at least one character for the domain, at least two for the TLD (we assume that TLD-less domains are undeliverable by us). This ensures we don't allow 'a@a' or 'a@a.a', but do allow 'a@a.io'.

That wouldn't allow ceo@cocacola, which is a valid email address (I don't know if mail will be delivered to it, but cocacola is an actual TLD).

Re: The Correct Way to Validate Email Addresses

#329
post #212

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.

Sure, but what if two humans share an email address, but both of them want to sign up for your game/service/whatever independently? This is a fairly common situation if you are (say) designing a game that might appeal to kids. Or old people.

If you block that, you're going to lose users. Either because they just can't sign up at all, or because there's too much unnecessary friction in requiring someone to go out and sign up for an email address just to register for your service.

Re: The Correct Way to Validate Email Addresses

#330

Earlier quoted context omitted.

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.

My bank limits passwords to ten chars. Ten! Have you ever heard any reasoning behind why they do this? The "best" excuse I've heard is so that customers don't forget. As if they don't have a "Forgot password?" link right there .

Because somewhere they have a decades old legacy system that can't handle more than 10 characters.
Post reply on HN