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

231–240 of 405 posts

Re: The Correct Way to Validate Email Addresses

#231

Post by Freak_NL »

creshal wrote: post #229
Freak_NL wrote: post #222

Earlier quoted context omitted.

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

And you should; you have no way of knowing if any service is practising proper security or not beyond what you can see (e.g., exclusive use of HTTPS with valid certificates), so assume the worst. It is best to see a password as a shared secret; something you share with a specific service. That means no reuse of passwords if you care about the consequences of that password getting out.

Re: The Correct Way to Validate Email Addresses

#232

Post by garaetjjte »

Freak_NL wrote: post #225
kiallmacinnes wrote: post #108

Earlier quoted context omitted.

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…

With banks there is other problem, because they often use partial passwords. They are password manager unfriendly and often limited to 16 characters.

Re: The Correct Way to Validate Email Addresses

#233

Post by nicolas_t »

Freak_NL wrote: post #228
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…

Our email provider flat out refuses to send to those domains actually so we actually reject the input for the domains that the email provider blocks.

> I would not rule out someone actually using ceo@cocacola at some point

Of course, this is subject to change if the practice changes. The aim is to make sure that we balance the percentage of emails that are correct versus the number of potential rejections. If 0.00001% of users use a top level domain and 99.9999% of emails without a tld are invalid, then it makes sense to reject it. We're not trying to find the most perfect solution just the most convenient solution for users.

Re: The Correct Way to Validate Email Addresses

#234

Post by nicolas_t »

gpvos wrote: post #205
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…

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.

Re: The Correct Way to Validate Email Addresses

#235

Post by zAy0LfpBZLC8mAC »

random_rr wrote: post #112
zAy0LfpBZLC8mAC wrote: post #73

Earlier quoted context omitted.

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

You haven't worked in email, I presume. Yes, it does cost money to send emails at a large scale.

I am not sure what you are trying to say. Yes, of course, it costs money. Just like serving websites costs money. And just as checking the syntax of an email address costs money (CPUs cost money and need power to run!). Now, how is that an argument for checking the syntax of an email address to avoid sending a single email and seeing whether it bounces?

Re: The Correct Way to Validate Email Addresses

#236

Post by chenster »

AgentME wrote: post #139
chenster wrote: post #87

Even from http://emailregex.com , a popular regular expression summary for email, states it can only catch 99.99% of validate emails. However, I still like to include some basic form of email validation both on the client and server side, plus the activation email.

>However, I still like to include some basic form of email validation both on the client and server side I worry you're more likely to permanently block a set of users with valid email addresses than prevent a user from making a typo.

The key here is "BASIC", something like [a-z]@[a-z] so at least they will have a at sign. Did you even read?

Re: The Correct Way to Validate Email Addresses

#237

Post by arielb1 »

adrusi wrote: post #182
justinpombrio wrote: post #173

Earlier quoted context omitted.

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.

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.

Re: The Correct Way to Validate Email Addresses

#238

Post by user5994461 »

robin_reala wrote: post #206
vidarh wrote: post #170

Earlier quoted context omitted.

If I ever use the "forgot my password" functionality at a site and they mail out something that is probably my original password, I make a point of cancelling my account and sending them an e-mail explaining why I don't trust them any more.

And submitting the site to http://plaintextoffenders.com

Omg. That sounds like a public list of "Top poorly secured business sites to breach. --Reward guaranteed"

Re: The Correct Way to Validate Email Addresses

#239

Post by zAy0LfpBZLC8mAC »

brightball wrote: post #124
zAy0LfpBZLC8mAC wrote: post #47

Earlier quoted context omitted.

That's just broken, the DNS lookups are wrong, the SMTP implementation is defective, I didn't look any further.

How so? If you could correct it how would you feel about the approach?

The approach of attempting to deliver a test email synchronously and seeing whether that fails? That's fine in principle. After all, it's in principle just what the MTA would do once you actually sent the email, and what would cause the MTA to generate a bounce message in the case of failure.

The practical problem is essentially the same as with all the syntax validation out there: It's extremely likely that you are getting it wrong, thus, once again, rejecting valid addresses because your implementation is buggy and behaves differently than an actual MTA.

As for the how so: Because somebody obviously, as is so often the case, just made shit up and implemented that instead of reading the relevant standards and implementing what they say. That's how most of the interoperability problems out there start: People have some passing familiarity with some protocol or data format, and then they implement code handling that protocol or format based on their idea of how things work, instead of what the standards actually say. That's just how we end up with people rejecting email addresses that contain "+" characters in the localpart. I mean, RFCs are public, what more do you need? If you want to implement an actual email address validator, you don't have to pay anything, you don't need to sign up anywhere, you just have to read it, and you can actually build a reliable email address validator, and there is nothing wrong with doing so. Yes, that is more work than just implementing your fantasy protocol. But if you can't be bothered with that, then just forget it and use an existing implementation by people who did care--namely, use an MTA to send a verification email.

Re: The Correct Way to Validate Email Addresses

#240

Post by erelde »

garaetjjte wrote: post #232
Freak_NL wrote: post #225

Earlier quoted context omitted.

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

With banks there is other problem, because they often use partial passwords. They are password manager unfriendly and often limited to 16 characters.

Société Générale uses the client ID and a 6 digit passnumber (sent via physical mail) with a digital numpad (you have to click) where each number is randomly placed.

So secure.

And they force a change every 3 months. As if a new 6 digit pass was more secure than the last 6 digit pass.

[https://en.wikipedia.org/wiki/Société_Générale]

Post reply on HN