Live data from Hacker News

In A Perfect World, This Is How Web Sites Would Handle Login Forms

woutersmet.com

11–17 of 17 posts

Re: In A Perfect World, This Is How Web Sites Would Handle Login Forms

#11
post #6

Whatever you do, DON'T follow this advice. It's utterly wrong. Here's the professional way to do this: "An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account." https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Bare in mind that particular advice is from a group expressly interested in security. The article is talking about usability. There is often a balance to be struck.

There is a balance, and it swings heavily in the direction of never ever ever compromising security.

Re: In A Perfect World, This Is How Web Sites Would Handle Login Forms

#12
post #11
post #6

Earlier quoted context omitted.

Bare in mind that particular advice is from a group expressly interested in security. The article is talking about usability. There is often a balance to be struck.

There is a balance, and it swings heavily in the direction of never ever ever compromising security.

Your reply made me smile. You're quite right, but only up to a point. An emphasis on security that compromises usability can backfire and start to make things less secure.

For example, enforcing a 32 character passphrase with at least 1 non-alphanumeric character would be incredibly secure, but users will start writing down their password on post-its near their terminals, and suddenly all that 'security' evaporates because you've introduced an artificial weak link.

In a small way better usability enhances security by making the user less likely to get things wrong.

Re: In A Perfect World, This Is How Web Sites Would Handle Login Forms

#14
There's a key question whether or not to do this that I haven't seen discussed: is the fact that a given login has an account private information? Sometimes it is, sometimes it isn't.

For example, on HN, it's trivial to find out whether a given username has an account -- just visit https://news.ycombinator.com/user?id=zck , and you'll see whether zck is a registered account.

On services like that, I don't see the harm in distinguishing "password incorrect" errors from "no user" errors, since that doesn't give you private information.

But on private sites, or if you're logging in via email? That's a different story.

Re: In A Perfect World, This Is How Web Sites Would Handle Login Forms

#15
post #12
post #11

Earlier quoted context omitted.

There is a balance, and it swings heavily in the direction of never ever ever compromising security.

Your reply made me smile. You're quite right, but only up to a point. An emphasis on security that compromises usability can backfire and start to make things less secure. For example, enforcing a 32 character passphrase with at least 1 non-alphanumeric character would be incredibly secure, but users will start writing down their password on post-its near their terminals, and suddenly all that 'security' evaporates b…

Compromising the lock is different than choosing the type of lock.

Re: In A Perfect World, This Is How Web Sites Would Handle Login Forms

#16
This is, as everybody noticed - HORRIBLE advice. Imagine this: You mind your own business on - let's say a man-to-man datings site. You don't appear to have a problem with homosexuality, but MAYBE your wife or your employer does. Like this, when they put in your private, personal email address and the website basically tells them: "Yep, you got it, that guy has an accout here". This "meta data" is quite sensitive information, if you ask me, not only from a security point of view, but from a privacy one. Holy moly, don't follow this advice.

Re: In A Perfect World, This Is How Web Sites Would Handle Login Forms

#17
Everyone's already covered how this is absolutely wrong, but I wanted to add that a second query is not appropriate, either.

You'd want your query to be something like

SELECT password_hash = {password_hash} AS authenticated FROM accounts WHERE email = {email}

That way you'd be able to tell based on your result set whether the user exists, and if so if their password is valid. All with one query.

But, again, you shouldn't do this.

Post reply on HN