3 ms·

Signup and login should behave the same, and provide no information wether the email is registered or not. And username should be treated as public. So for log

Signup and login should behave the same, and provide no information wether the email is registered or not. And username should be treated as public. So for login: always say "email or password is incorrect". And for register: as he said, always say "we sent you an email to verify your email".

wyuenho 9y ago
Except that when you are signing up, unless the service is using some draconian password formatting rules, any "email or password is incorrect" error can be inferred as the email is incorrect, and if the email format is correct, it's must likely because the email was taken. "email or password is incorrect" is bullshit is right.
- ChrisMorrisOrg 9y ago
  Can you please give an example? I don't think I understand what you're saying.
- croon 9y ago
  Either you or I misunderstood GP. I understood it as if (as long as any email format validation allows the address) the service only outputs "sent you an email for confirmation", even if the email is registered. The attacker wouldn't know if it was the first time or the 50th time that message had been shown, as it's always the same.
  - travisjeffery 9y ago
    Correct. The UI message would always be the same, some variant of "email sent." Even if the account already existed and it wasn't actually a successful sign up of a new account.
  - wyuenho 9y ago
    I understand him perfectly, what I'm saying is what he's proposing is useless, because you can mold your email and password into anything that you know for certain it will pass validation, that's your oracle right there. During sign up, if you know both the formatting rules of what you typed as the email and the password cannot have caused an error, then it follows any error message (500 errors notwithstanding) must be a duplicate email. Because that's typically the only constraint difference exists between an email and a password. Given that, who cares what error message you display, as an attacker I only need to be able to find out weather a system has an email or not, and the sign up screen is a perfect oracle.
ChrisMorrisOrg 9y ago
Precisely this. The title of this article should probably be renamed because it's looking at specific examples where the whole process (ie login + registration flows) hasn't been implemented properly.
croon 9y ago
Edge case: For services which uses an additional account name/alias (separate from email), where you can login with either account name or email; An attacker could find a target account name through signup, using an email the attacker owns.
- cdancette 9y ago
  True. For this I would recommend adding the mention "your username will be publicly visible" during the registration process.
bo1024 9y ago
Why? I don't see why it's important to hide existence of a user unless you're allowing people to try multiple logins per second on your site. (I'm not an expert so I am sincerely asking to help me understand.)
- cdancette 9y ago
  If your users want to disclose that information, provide them a way to make a public profile if they want to, and if it makes sense. Don't assume their intentions. They might have good reasons you didn't think of.
- avian 9y ago
  For some websites, people might not want others to be able to find out whether they have registered if they only know their email address (e.g. same kind of websites for which the incognito/private mode exists in browsers).
- rimliu 9y ago
  You are leaking the information. Maybe you want to check if your buddy is a registered on some controversial site, or maybe you want to target someone for hacking…
- Terr_ 9y ago
  We're used to assuming that the attacker knows a login and is guessing at a password, however the opposite scenario is is increasingly common. Suppose another website has a security breach, revealing many names and passwords. User John Doe used a password of "foo", so an attacker starts trying combinations like jdoe/foo or johnd/foo or john_doe/foo, looking for the same person reusing a password on your site. By denying them information about which login names exist, it's harder for the attacker to either zero-in on the correct username (and try alternate password variations) or to be certain that they've got nothing and that it's time to move on.
- TranceMan 9y ago
  I could find user 'bo1024' has an account on pornhub - not necessarily you and you might not care but certain situations it may be a problem. You could argue it's security through obscurity - I'd say preventing leaking data.
ryanbrunner 9y ago
If you have a user name, why do you care about e-mail? Let people enter an arbitrary user name, and log in with that. Username enumeration doesn't carry privacy concerns since users can ensure their usernames don't reveal personal information. For duplicate e-mails on signup, who cares? Since you're not using them as an identifier, let multiple users have the same e-mail address. Making your validation errors cross mediums and a wait for an e-mail to delivered is an unnecessarily hostile user experience.
- pdkp 9y ago
  I think you have a good point in that if you are going to use usernames as an identifier, there is an argument that having an email also be an identifier is sort of redundant. One problem with that is that when users are given the option of an arbitrary username, they tend to be much more likely to forget that username than they are the email address they use daily. So, you need some way of resetting their password and letting the user recover their username. In some cases, you could pair that with other identifiers, like their name, phone, social security number, etc. However, then you are just trading the email as an identifier for something else, which you would also need to check during registration. For this reason, I've found that moving away from a username and just relying on an email for a login makes managing multi-user sites a great deal easier from an admin side.
  - ryanbrunner 9y ago
    That's fine though, sending a forgot username / password e-mail is much simpler to do without exposing the fact that you know their e-mail (just send a "sorry, we don't have that e-mail on file" to the e-mail address if there's no match) I agree that e-mail makes for a better login experience, but if exposing who uses your site is too much of a privacy concern, I'd rather move to usernames than have to implement awkward user experiences to never reveal whether someone is a user or not.
    - pdkp 9y ago
      I think a lot of sites already do that, although they may not send an email saying 'sorry, we don't have that e-mail on file,' it is pretty common to get a 'if that email exists, we have sent a reset e-mail to it' message when you do a password reset that doesn't expose if the email exists in the system. Although to the point of this article, they will then happily tell you you can't use an email during signup, so it is a mixed-bag. I suppose if you allowed multiple usernames per email, you could just email them all the usernames that they have on that email address when they forgot their username, but that seems like a clunky setup. It probably depends a lot on the service though, as someone posted a link to a discussion from 2014 about Amazon's reasoning for allowing multiple emails elsewhere in this thread, which makes a bit of sense for their use-case.

wyuenho 9y ago

Except that when you are signing up, unless the service is using some draconian password formatting rules, any "email or password is incorrect" error can be inferred as the email is incorrect, and if the email format is correct, it's must likely because the email was taken. "email or password is incorrect" is bullshit is right.

ChrisMorrisOrg 9y ago
Can you please give an example? I don't think I understand what you're saying.
croon 9y ago
Either you or I misunderstood GP. I understood it as if (as long as any email format validation allows the address) the service only outputs "sent you an email for confirmation", even if the email is registered. The attacker wouldn't know if it was the first time or the 50th time that message had been shown, as it's always the same.
- travisjeffery 9y ago
  Correct. The UI message would always be the same, some variant of "email sent." Even if the account already existed and it wasn't actually a successful sign up of a new account.
- wyuenho 9y ago
  I understand him perfectly, what I'm saying is what he's proposing is useless, because you can mold your email and password into anything that you know for certain it will pass validation, that's your oracle right there. During sign up, if you know both the formatting rules of what you typed as the email and the password cannot have caused an error, then it follows any error message (500 errors notwithstanding) must be a duplicate email. Because that's typically the only constraint difference exists between an email and a password. Given that, who cares what error message you display, as an attacker I only need to be able to find out weather a system has an email or not, and the sign up screen is a perfect oracle.

ChrisMorrisOrg 9y ago

Precisely this. The title of this article should probably be renamed because it's looking at specific examples where the whole process (ie login + registration flows) hasn't been implemented properly.

croon 9y ago

Edge case: For services which uses an additional account name/alias (separate from email), where you can login with either account name or email; An attacker could find a target account name through signup, using an email the attacker owns.

cdancette 9y ago
True. For this I would recommend adding the mention "your username will be publicly visible" during the registration process.

bo1024 9y ago

Why? I don't see why it's important to hide existence of a user unless you're allowing people to try multiple logins per second on your site. (I'm not an expert so I am sincerely asking to help me understand.)

cdancette 9y ago
If your users want to disclose that information, provide them a way to make a public profile if they want to, and if it makes sense. Don't assume their intentions. They might have good reasons you didn't think of.
avian 9y ago
For some websites, people might not want others to be able to find out whether they have registered if they only know their email address (e.g. same kind of websites for which the incognito/private mode exists in browsers).
rimliu 9y ago
You are leaking the information. Maybe you want to check if your buddy is a registered on some controversial site, or maybe you want to target someone for hacking…
Terr_ 9y ago
We're used to assuming that the attacker knows a login and is guessing at a password, however the opposite scenario is is increasingly common. Suppose another website has a security breach, revealing many names and passwords. User John Doe used a password of "foo", so an attacker starts trying combinations like jdoe/foo or johnd/foo or john_doe/foo, looking for the same person reusing a password on your site. By denying them information about which login names exist, it's harder for the attacker to either zero-in on the correct username (and try alternate password variations) or to be certain that they've got nothing and that it's time to move on.
TranceMan 9y ago
I could find user 'bo1024' has an account on pornhub - not necessarily you and you might not care but certain situations it may be a problem. You could argue it's security through obscurity - I'd say preventing leaking data.

ryanbrunner 9y ago

If you have a user name, why do you care about e-mail? Let people enter an arbitrary user name, and log in with that. Username enumeration doesn't carry privacy concerns since users can ensure their usernames don't reveal personal information. For duplicate e-mails on signup, who cares? Since you're not using them as an identifier, let multiple users have the same e-mail address. Making your validation errors cross mediums and a wait for an e-mail to delivered is an unnecessarily hostile user experience.

pdkp 9y ago
I think you have a good point in that if you are going to use usernames as an identifier, there is an argument that having an email also be an identifier is sort of redundant. One problem with that is that when users are given the option of an arbitrary username, they tend to be much more likely to forget that username than they are the email address they use daily. So, you need some way of resetting their password and letting the user recover their username. In some cases, you could pair that with other identifiers, like their name, phone, social security number, etc. However, then you are just trading the email as an identifier for something else, which you would also need to check during registration. For this reason, I've found that moving away from a username and just relying on an email for a login makes managing multi-user sites a great deal easier from an admin side.
- ryanbrunner 9y ago
  That's fine though, sending a forgot username / password e-mail is much simpler to do without exposing the fact that you know their e-mail (just send a "sorry, we don't have that e-mail on file" to the e-mail address if there's no match) I agree that e-mail makes for a better login experience, but if exposing who uses your site is too much of a privacy concern, I'd rather move to usernames than have to implement awkward user experiences to never reveal whether someone is a user or not.
  - pdkp 9y ago
    I think a lot of sites already do that, although they may not send an email saying 'sorry, we don't have that e-mail on file,' it is pretty common to get a 'if that email exists, we have sent a reset e-mail to it' message when you do a password reset that doesn't expose if the email exists in the system. Although to the point of this article, they will then happily tell you you can't use an email during signup, so it is a mixed-bag. I suppose if you allowed multiple usernames per email, you could just email them all the usernames that they have on that email address when they forgot their username, but that seems like a clunky setup. It probably depends a lot on the service though, as someone posted a link to a discussion from 2014 about Amazon's reasoning for allowing multiple emails elsewhere in this thread, which makes a bit of sense for their use-case.