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

291–300 of 405 posts

Re: The Correct Way to Validate Email Addresses

#291

Post by lostboys67 »

vidarh wrote: post #179
tempestn wrote: post #154

Earlier quoted context omitted.

I recently registered [mylastname].email, thinking to switch over to firstname@lastname.email from my gmail address. Turns out a large percentage of forms don't accept new TLDs.

I co-founded the company that set up the ".name" TLD as part of the first batch of new TLDs back in 2001, and we had no ends of problems because of that. A lot of people either had hardcoded lists, or they checked the length and refused TLDs longer than 3 characters. We kept e-mailing people about it, and kept getting messages back from people who had "fixed" it by adding just us (we'd generally have pointed people t…

I recall doing something similar for .coop

Re: The Correct Way to Validate Email Addresses

#292

Post by wtbob »

thedufer wrote: post #156
wtbob wrote: post #37

Earlier quoted context omitted.

> Sure, the complete regex is complex, but it is defined and is hardly unconquerable. If it is a regular expression, then it is not able to match all valid email addresses, because the grammar of email addresses is context-free, and regular expressions can only match regular grammars. It doesn't matter if it is defined or not: if it's a true regular expression, then it simply cannot validate email addresses. (it may,…

It is true that regular expressions in the CS sense can't parse context-free grammars. However, PCRE, which is what most programmers are talking about when they say "regex", can do so. So you're both kinda right, I guess. But you're being a bit pedantic.

> But you're being a bit pedantic.

Technically-correct is the best kind of correct:-)

But I do think it's important to note, since there really are differences between regular and 'regular' expressions.

Re: The Correct Way to Validate Email Addresses

#294

Post by tssva »

kasparsklavins wrote: post #277
creshal wrote: post #229

Earlier quoted context omitted.

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

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.

Here is a fun one. My credit union limits passwords to 32 characters and since I use lastpass for my passwords I had it generate a 32 character password when registering at the website.

Next day I get around to downloading and setting up their mobile app. Login and get a prompt that since it is my first time using the mobile app. They have sent me an email with a 4 digit code I need to enter before proceeding in the app. The email with the code arrives quickly and I enter the code. Proceed to get an error message "Error 400: This service is not available at this time." Ok, they must be down I'll try again later. The code is good for 24 hours. Next morning find time to try again and get the same error message except this time it also informs me that my account has been locked. Call up customer service and with scarily little information get them to unlock my account. Explain what is happening with the app and the CS rep puts me on hold. Comes back and tells me the IT folks thought it must be a problem because of my email address. "Do you have a normal email address like from Gmail, Yahoo or hotmail?" I release a great sigh and give in to the stupidity I'm about to have to navigate. I provide a gmail address. They change the email associated with my account on their end and tell me I should try again in 24 hours. I do with the same results. Call back again and the CS person puts me on hold again while she reaches out to IT. This time whoever she talks to knows the issue right away.

Turns out that when you login to the mobile app for the first time and submit the code it is actually appended to the end of your password and submits it as your password. Which if you have a password with more than 28 characters means you are exceeding the 32 character password max which causes them to return the informative, "Error 400: This service it not available at this time.", message.

Re: The Correct Way to Validate Email Addresses

#295

Post by pixl97 »

nucleardog wrote: post #165
tempestn wrote: post #155

Earlier quoted context omitted.

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.

Yeah, basically this. In theory every time I need a password I can copy and paste. In reality, sometimes I'm on someone else's computer or something else comes up that I need to open my database up on my phone and type it in by hand. For instance, I can't imagine trying to enter a 100 character password with a PS3 controller to log myself back into Netflix... If I'm already at "it's going to take 100 quintillion year…

It would take less time than you think with MD5 because of hash collisions. A 100 char pass is longer than the hash it outputs and is truncated.

Re: The Correct Way to Validate Email Addresses

#296

Post by BuildTheRobots »

Benjamin_Dobell wrote: post #110
parennoob wrote: post #64

Earlier quoted context omitted.

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

You probably hang around tech sites that mostly have it together. I find common culprits are service companies; gas, electricity, real estate websites, insurance companies etc. EDIT: Oh, and warranties! Man warranty websites tend to suck. Samsung for instance won't let you register your product to an email with a +.

when registering my S3 years ago I realised that samsung wouldn't let you have the word "samsung" or "s3" as part of your email address.

Re: The Correct Way to Validate Email Addresses

#297

Post by Filligree »

Xylakant wrote: post #248
arielb1 wrote: post #237

Earlier quoted context omitted.

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.

Most people reuse passwords, so that isn't a trivial benefit.

Re: The Correct Way to Validate Email Addresses

#298

Post by pixl97 »

zAy0LfpBZLC8mAC wrote: post #266
nicolas_t wrote: post #233

Earlier quoted context omitted.

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…

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.

Re: The Correct Way to Validate Email Addresses

#299

Post by sethammons »

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.

Another argument against: some couples share email accounts but may want separate accounts on your service. Yes, this happens.

Re: The Correct Way to Validate Email Addresses

#300

Post by Filligree »

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.

Word-splitting, escape character interpretation and so forth is done by the shell. The shell is only invoked if you use the system() call to run said tool.

Which you shouldn't. execve (and friends) will let you pass an explicit array of flags, and you should always use one of those functions if you're calling another program. No interpretation.

Post reply on HN