The Correct Way to Validate Email Addresses • Hacker News Board

Re: The Correct Way to Validate Email Addresses

#311

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

flurdy wrote: post #252

voidz wrote: post #97

Earlier quoted context omitted.

These days I do this differently; I created a subdomain that forwards all email to my main account. hackernews@foo.example.com would forward to main@example.com, and I can just filter the prefixes. That way I can use the subdomain for my own unique addresses, without interfering or using up addresses on the parent domain.

I do as well. Keeps a nice track of which have been leaked (or guessed) by spammers. And easy mail filtering to relevant labels on my side. But it does get awkward quite a few times when having to interact with a human (customer services, hotel bookings, etc) via email or phone when they get a bit confused why their company name is my email alias.... Spelling a long alias over the phone letter by letter is especially…

Same here, same (minor) problems. The human interaction part is pretty much covered when I used yourorg@mail.my-name.tld for registration, but the more provocative variation yourorg@spam.my-name.tld occasionally raises some eyebrows.

The nasty part is replying with the main address as the sender. I'd really love to have email clients with reasonable support for this usage pattern for the platforms I use, but maybe then the pattern might become popular enough to lose some of its advantages.

Re: The Correct Way to Validate Email Addresses

#312

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

pixl97 wrote: post #298

zAy0LfpBZLC8mAC wrote: post #266

Earlier quoted context omitted.

How about rejecting all email addresses that contain the character sequence "jex"? 99.9999% of email addresses with "jex" in it are invalid, so it makes sense to reject it, doesn't it?

If a few hundred people messed up and typed jex instead of sex a day, then yes it would make sense to reject it.

1. That wasn't the argument.

2. No, it still wouldn't make sense to reject existing email addresses if there is a method to figure out whether the email address you are being presented with actually exists instead of divining validity using some unreliable proxy. There is just absolutely no reason to ever reject an email address that you can successfully send emails to.

Re: The Correct Way to Validate Email Addresses

#313

Post by [deleted] » Thu, Sep 08, 2016, 2:31 PM UTC

pixl97 wrote: post #301

throwanem wrote: post #274

Earlier quoted context omitted.

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

NXDOMAIN can be a temporary error. The SMTP queuing protocol is designed to be resilient against DNS failures, internet outages, routing problems, and temporary mail delivery issues.

[deleted]

Re: The Correct Way to Validate Email Addresses

#314

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

kazinator wrote: post #95

Sorry, I disagree. There is absolutely is a correct way to lexically validate an e-mail address: namely, implement a parser for the syntax specified in whatever RFC is the up-to-date successor of RFC 822. There is such a thing as incorrect e-mail address syntax: namely, non-RFC-conforming syntax, whatever that is. You may reject that, and that's about it. Please don't reject RFC-conforming e-mail addresses.

Believe it or not, but MTAs often violate RFCs. Hands down, the best way to validate an email address is to attempt to send to it.

Re: The Correct Way to Validate Email Addresses

#315

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

oddlyaromatic wrote: post #89

mook wrote: post #67

Earlier quoted context omitted.

I've got an account where they just plain stripped the + character. Since I happen to have used only alphanumeric charters after, I am now registered with an email address I can't actually receive mail on - it goes to somebody else's inbox. Account synchronization was involved - IIRC the initial address confirmation message got thorough.

I thought that though the + is valid, nothing after the + is used to differentiate the email address? I use local+Organization when I sign up for an email list so that I can easily filter, plus I can see if that email address gets shared around. So on places that reject the + I just use everything before it as the local part. Maybe I'm missing something. Edit: I guess not all email providers do it this way but here's…

So this is true on the email provider side, sometimes. Gmail (and a lot of others) rout foo+bar@gmail to foo@gmail. It's not required, but it's common.

The problem here, though, is that the email sender just stripped the + and sent the content to foobar@gmail.com. That's just a totally different account, chosen without warning.

Re: The Correct Way to Validate Email Addresses

#316

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

Freak_NL wrote: post #271

mgkimsal wrote: post #260

Earlier quoted context omitted.

It's not always that. Let's use the "filtering chars from password" example above. You can't put some special chars in password field, and you want to change that so it's doing normal hashing where special chars don't matter. In a larger org, even changing a practice like that so that it "makes more sense" can have a big ripple effect. You have to * explain to someone else on the team who came up with the original pr…

At a small business convincing colleagues isn't that hard. At a larger corporation, getting the rest of the team on-board is the job of whoever is in charge of defining security policies and such. Not allowing characters present on all keyboards and input devices (!"@+'$) statistically increases the risk of people picking weaker passwords then possible, and he/she will guide that change through the proper processes,…

Take that one 'request' - possibly initiated by a jr-mid level developer - and stack it up against the 500 other todo items in the pipeline. You can make those arguments about "statistically increases the risk of people picking weaker passwords " - unless this increases a bottom line or comes out of someone else's budget, this sort of 'bug' is going to be really low down on the totem pole for all the reasons I mentioned, and a few others.

You can says "the process is broken" but it's also that same process that got people where they are, puts food on their table, pays for the lifestyle, and precious few people are willing to ever rock the boat at any company for anything.

Re: The Correct Way to Validate Email Addresses

#317

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

vacri wrote: post #216

gregmac wrote: post #80

Earlier quoted context omitted.

I agree, but in that case, you should be validating the e-mail address (which was my original point). Failure to do so means: - The user who actually owns that e-mail can't login - The user who signs up can potentially impersonate the real user (depending on what your app does) - The user who signs up can't reset their password - The user who actually owns the e-mail can take ownership of the account (by resetting pa…

Fair points. One argument against emails-as-names is that some people change email addresses frequently - unless you have some way of accounting for that (and you definitely wouldn't use the username as the contact field), the username will eventually go stale for some users.

You should allow changing the e-mail address. Of course, changing it requires the same validation, but I'm not really sure why there'd be an argument against it (though I do note many sites/applications don't have a mechanism for this).

At the same time, as a user, you need to consider your own e-mail setup. You should not use your ISP-provided e-mail address whatsoever, there is absolutely no reason to tie your contact to an account you may not keep.

Likewise, you should not be using your school or work-provided addresses for something that you expect to use beyond going to school or having that job.

If you're changing your e-mail address frequently for personal reasons (eg, someone harassing you?), then you should actually consider creating an account you use only for authentication, and a separate one that is your public-facing persona.

Having separate addresses for your contact and sign-ups is actually not a bad idea anyway. It actually makes it a bit harder for someone to break into your account somewhere (because they don't necessarily know what address you used), and you get the freedom to change/abandon your public e-mail address if necessary.

Re: The Correct Way to Validate Email Addresses

#318

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

zAy0LfpBZLC8mAC wrote: post #312

pixl97 wrote: post #298

Earlier quoted context omitted.

If a few hundred people messed up and typed jex instead of sex a day, then yes it would make sense to reject it.

1. That wasn't the argument. 2. No, it still wouldn't make sense to reject existing email addresses if there is a method to figure out whether the email address you are being presented with actually exists instead of divining validity using some unreliable proxy. There is just absolutely no reason to ever reject an email address that you can successfully send emails to.

I mean, in this case there are two reasons. They're both bad reasons, but still.

1. "Our email provider won't send to them". That excuses OP's part in the thing, although now we need to ask why the email provider is being stupid.

2. "We don't do validation links, they cause too many lost users". I have serious problems with this, but from a pure-business standpoint they decided that rejecting valid emails loses fewer users than using account confirmation.

Number two is vaguely horrifying to me, but in terms of "new users gained" it probably works out.

Re: The Correct Way to Validate Email Addresses

#319

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

arielb1 wrote: post #237

adrusi wrote: post #182

Earlier quoted context omitted.

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.

> You can perform the first pass of salted hashing on the client-side.

Not really. JavaScript crypto is fundamentally broken: an attacker, malicious server or disgruntled employee can replace server-side JavaScript and remove the client-side hashing at any time. This is, notably, why Firefox Accounts are completely and totally insecure (and hence why Sync is unsuitable for storing any private data at all).

Re: The Correct Way to Validate Email Addresses

#320

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

tempestn wrote: post #155

sbuttgereit wrote: post #96

Earlier quoted context omitted.

Ha! If only! Probably more than 50% of the sites I visit that have a maximum length that my password manager exceeds... give me an unrelated error message. Some times they tell me I haven't met the minimum length (100 chars, really?), sometimes they tell me that I've not met complexity requirements (I use upper/lower/numbers/special chars), etc. It's as though the developer only ever thought of how people wouldn't me…

You default to 100 character passwords? Doesn't that make it extremely inconvenient on the rare occasions when you need to type a password out? I figure 14 characters is going to be effectively unbreakable, but still possible to manually copy in under a minute.

It depends on your needs. Clearly in my case: nope, not a problem. Otherwise I would have changed. And I think your use of the word "default" is appropriate; what I do most of the time is not what I do 100% of the time... there are exceptions.

In those cases where I might need to manually enter a passphrase and I can't rely on the password manager functionality, I use a pass-sentence that is both long and includes some random characters thrown in. That can still get me to 100 characters pretty easily. But those cases a fairly rare for me. I'm also only very, very rarely using a device that I don't own (ok, I do access systems I don't own frequently, but using my device... ssh, etc).

Most of the time my 100 character default doesn't give me any greater security than your 14 characters (assuming they're well constructed or random passwords) and things like multi-factor auth are often times much more important anyway. There are some times it can be useful; sometimes I can remember a 14 character password just by looking at it, even if it's random and not mine. 100 characters I can't. Since password managers can rely on things like cut and paste, rarely, but occasionally, I might accidentally paste a password somewhere I don't mean to: at 14 characters I might not notice, but at 100 I more likely will (or overrun the field and lose a piece of it anyway). At the end of the day, I have a password manager and I'm going to turn it to 11 and let it run. My personal practices are not necessarily my recommendations in this area, but they suit my needs.

Either way, my point still stands: if you build software that takes passwords and you limit the length (or can't take longer passwords), provide meaningful feedback if your requirements are exceeded... makes me wonder what else I might be able to do if you didn't expect me to exceed your password length and respond properly.