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

241–250 of 405 posts

Re: The Correct Way to Validate Email Addresses

#241

Post by robin_reala »

user5994461 wrote: post #238
robin_reala wrote: post #206

Earlier quoted context omitted.

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"

They have two classes of site that they don’t distinguish to be fair. One is the awful “You’ve forgotten your password. It’s: xxxx” where they’re just storing the password in plaintext in the database.

The other is still not great but it’s less bad: “Thankyou for registering. Your registered password is: xxxx”. In this case they’ve just passed the user details to an emailer before (potentially) encrypting and storing them.

Neither is good, but the first is awful.

Re: The Correct Way to Validate Email Addresses

#242

Post by throwanem »

zAy0LfpBZLC8mAC wrote: post #230
vacri wrote: post #212

Earlier quoted context omitted.

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

Yep.

I designed a system once around the assumption of a 1:1 mapping between people and email addresses. I will never design another system that way.

Re: The Correct Way to Validate Email Addresses

#244

Post by warfangle »

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.

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.

Re: The Correct Way to Validate Email Addresses

#245

Post by throwanem »

zAy0LfpBZLC8mAC wrote: post #71
jwecker wrote: post #59

Earlier quoted context omitted.

An email address isn't a document though, it's a routing command. I don't mean sanitization in the sense of inserting backslashes. I mean sanitization in the sense of "we don't allow people to set their email address to a mailbox on localhost at our mail server."

1. Sanitization generally means changing information. As in, "removing bad characters", that kind of stuff. That's different from validation, which should result in rejection of bad input, and which can be perfectly fine. However, more often than not, validation is implemented badly and rejects perfectly fine input, which is why validation shouldn't be employed more than necessary either. 2. Rejecting @localhost addr…

> There is nothing particularly dangerous about receiving unsolicited signup emails or about sending emails to yourself.

Depends on what you do with them, in the latter case. There could be an amplification attack there.

Validating domain parts to a certain extent isn't a bad idea, at least as far as non-routable domain names and RFC1918 ranges go. I've seen this done (actually implemented some of it, in fact) at a past employer, who were basically looking to cover the 90% case in terms of not getting hosed by a trivial attack. It doesn't take much effort and it makes 4chan's life harder. What's not to like?

Re: The Correct Way to Validate Email Addresses

#246

Post by [deleted] »

nomel wrote: post #197
jwecker wrote: post #72

Earlier quoted context omitted.

True, but that's my point- it's a backend issue, not a front-end "help the user" issue.

And their point is, it's a backend issue, the backend being the mail client/server that already completely handling the sending/receiving of emails. Either the activation link gets clicked or it doesn't. The click is the only correct validation, and yes, the whole process happens on the "backend".

[deleted]

Re: The Correct Way to Validate Email Addresses

#247

Post by zAy0LfpBZLC8mAC »

flukus wrote: post #211
Hydraulix989 wrote: post #193

Earlier quoted context omitted.

Even Linux tools like GNOME Archive Manager in Linux Mint 18 rejected my RAR password containing a $ as the incorrect password, even though it was the correct password for the RAR file I was trying to extract. I then used the command-line unrar utility with the exact same password, and it extracted successfully. Now, why would you preemptively (and explicitly) throw out a candidate password string based on its charac…

I'm guessing both are because the are calling command line tools. One of my pet peeves with linux is that many of these tools are only callable via text and don't expose an API for other programs.

"callable via text"? What does that even mean? The command line is an API, isn't it? If people don't manage to pass an ampersand to another program via the command line, that's really no different than people failing to pass an ampersand as a URI parameter to an HTTP resource: Failure to encode properly. There is absolutely nothing that prevents you from passing an ampersand (or any other characters) to a program via its command line.

Re: The Correct Way to Validate Email Addresses

#248

Post by Xylakant »

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.

so you just replaced the password with another secret, the hashed password. An attacker would now not need to gain access to the original password, but needs the hashed password - which will be logged just like the PW.

The only security benefit is that it offers a bit of support for those that are reusing passwords since it doesn't expose the plain text.

Re: The Correct Way to Validate Email Addresses

#250

Post by zAy0LfpBZLC8mAC »

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.

Depends on where you have to type it, but usually, if people have long "passwords", it's because they use passphrases, which tend to actually be easier to type on real keyboards, but which are long because of the low entropy per character.
Post reply on HN