5 ms·

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

7 points by wauter 13y ago

1p1e1 13y ago
It's a good UI, however if not done right it can be potentially dangerous. As you mention in the PS, people can abuse it in various different ways. Spam bots can go around websites that use this practice and check email validity, for example.
facorreia 13y ago
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 https://www.owasp.org/index.php/Authentication_Cheat_Sheet
- onion2k 13y ago
  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.
  - leigh_t 13y ago
    There is a balance, and it swings heavily in the direction of never ever ever compromising security.
    - onion2k 13y ago
      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.
      - firephreek 13y ago
        Compromising the lock is different than choosing the type of lock.
- VeejayRampay 13y ago
  I second that. It's preferable to not give any indication about which emails are or are not stored in your database.
vxxzy 13y ago
This is a terrible idea. At this rate, you're just handing out your data! It is a matter of practicality and security. When someone enters a username and password, you do not know who may be on the other end. Telling them that the username is correct but the password is wrong puts an attacker one step closer to gaining access.
- azurelogic 13y ago
  Came to the comments to say this. Glad to see I'm not the only one thinking it.
onion2k 13y ago
In my perfect world signing up to a service would only need my email address. I'd enter it and the service would email me a link. Clicking that link would log me in. No password necessary. My log in credentials would be available everywhere my email is available (which is everywhere), and if I accidentally delete the email then just filling in the "sign up" box with the same email address would email me a new one. The downside is that if my email account is compromised then my account with the service is also compromised, but if that's the case then most 'forgotten password' systems would be equally broken.
camelNotation 13y ago
No, in a perfect world, THIS is how web sites would handle login forms: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
aboodman 13y ago
In a perfect world, you don't login at all because your device knows your identity and there are standardized identity federation protocols that applications and devices can participate in. (Android already has this. Android developers: Please use AccountManager. I am highly unlikely to create an account with you.) I can't count the number of times I've just "oh well, nevermind" when I couldn't remember the stupid credentials I used with some application, or couldn't be bothered to create new ones. Not to mention the well-documented security problems with asking users to manage passwords. Blech I say. Blech. I'm sad that it's 2014 and this is still unsolved.
madaxe_again 13y ago
In a perfect world, username enumeration is everywhere?
zck 13y ago
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 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.
cessor 13y ago
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.
slinkyavenger 13y ago
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.

7 points by wauter 13y ago

1p1e1 13y ago

It's a good UI, however if not done right it can be potentially dangerous. As you mention in the PS, people can abuse it in various different ways. Spam bots can go around websites that use this practice and check email validity, for example.

facorreia 13y ago

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 https://www.owasp.org/index.php/Authentication_Cheat_Sheet

onion2k 13y ago
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.
- leigh_t 13y ago
  There is a balance, and it swings heavily in the direction of never ever ever compromising security.
  - onion2k 13y ago
    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.
    - firephreek 13y ago
      Compromising the lock is different than choosing the type of lock.
VeejayRampay 13y ago
I second that. It's preferable to not give any indication about which emails are or are not stored in your database.

vxxzy 13y ago

This is a terrible idea. At this rate, you're just handing out your data! It is a matter of practicality and security. When someone enters a username and password, you do not know who may be on the other end. Telling them that the username is correct but the password is wrong puts an attacker one step closer to gaining access.

azurelogic 13y ago
Came to the comments to say this. Glad to see I'm not the only one thinking it.

onion2k 13y ago

In my perfect world signing up to a service would only need my email address. I'd enter it and the service would email me a link. Clicking that link would log me in. No password necessary. My log in credentials would be available everywhere my email is available (which is everywhere), and if I accidentally delete the email then just filling in the "sign up" box with the same email address would email me a new one. The downside is that if my email account is compromised then my account with the service is also compromised, but if that's the case then most 'forgotten password' systems would be equally broken.

camelNotation 13y ago

No, in a perfect world, THIS is how web sites would handle login forms: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm

aboodman 13y ago

In a perfect world, you don't login at all because your device knows your identity and there are standardized identity federation protocols that applications and devices can participate in. (Android already has this. Android developers: Please use AccountManager. I am highly unlikely to create an account with you.) I can't count the number of times I've just "oh well, nevermind" when I couldn't remember the stupid credentials I used with some application, or couldn't be bothered to create new ones. Not to mention the well-documented security problems with asking users to manage passwords. Blech I say. Blech. I'm sad that it's 2014 and this is still unsolved.

madaxe_again 13y ago

In a perfect world, username enumeration is everywhere?

zck 13y ago

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

cessor 13y ago

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.

slinkyavenger 13y ago

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.