1. 41
  1.  

  2. 17

    Easy fix: Don’t complain about existing emails, simply convert the signup into a password reset email and if usernames aren’t public don’t complain or even ask for one until a confirmation mail has been received.

    Username or Email disclosure can be very bad for privacy.

    1. 1

      This just delays disclosure. Eventually, the sign up is gonna fail because the username/email exists. Even if you push it later after an email.

      1. 8

        Not necessarily. The signup could only continue with access to the targets email service. The attacker doesn’t know if the attack succeeded or not unless they have access to the email address. If that is the case, the entire point is moot anyway since you can click “reset password”.

        1. 2

          Let’s say I’m an attacker. I sign up on lobste.rs at hacker@gmail.com, sign up works and I get a confirmation email. I then sign up on lobste.rs with the email tscs37@gmail.com. Because your account exists already, I don’t get an email. The difference, even if it’s something not happening, tells me what I wanted to know.

          1. 12

            Yeah but you don’t know if you get an email for tscs37@gmail.com since you don’t have access to that account.

            You wouldn’t get an email if the account existed or not.

            1. 0

              I do know though. I know I didn’t get an email for tscs37@gmail.com. That tells me just as much about the account’s existence if I had got the email.

              1. 14

                If you get that mail that implies you have control over tscs37@gmail.com, in which case the entire method doesn’t do anything. But it’s also not valid to say the entire method is therefore flawed.

                You just gained access to my mail account, you can click “reset password”. Or signup for real. Or just check the emails in the archive folder.

                If you do not have access to tscs37@gmail then you cannot tell if the email had signed up because you don’t get the email

                1. 2

                  Ah I see what you’re saying now. Yeah that might work, it wouldn’t work for sites that have usernames, users could only be identified/login with email addresses.

                  1. 2

                    It can work with sites that have usernames, but only for display purposes.

                    So you can still be shown as “travisjeffery” or “ilikedeepthreads” or whatever rather than showing your email all over the place, but thats all it is - display text.

                  2. 1

                    This also takes the step of validating that an email address is active during signup, instead of after signup, which is a huge win, in and of itself.

                  3. 1

                    It tells you that somebody already registered that email address. It does not tell you if that somebody also has a lobsters account.

                2. 2

                  You didn’t get any email because you don’t control the email account to be able to check it.

                  1. 1

                    Lobsters isn’t a good example for average case because it has a list of usernames. So, you can tell if the name is there. You might not know if it’s the target individual, though. Then, clicking on the profile may or may not tell you more about the individual. You can also social engineer users to find out identity information you might not get from a commercial service without more work and risk.

                    I do agree with you that it’s pointless to hide the username on a site where (a) you can see if it’s take and critically (b) username has something like email that uniquely identifies an individual. Other examples might be their Facebook or Twitter accounts. I’d still default on hiding it in the likely-reusable implementation of login since I can’t know ahead of time whether or not they’ll leak information like that. Secure by default.

                    1. 1

                      If email address was used for login (and usernames only for display) there’d be minimal attack surface there.

              2. 1

                This is definitely a good way to prevent those issues. For several times I thought about using this method on some projects.

              3. 7

                Ha, me on this issue three years ago: https://kev.inburke.com/kevin/invalid-username-or-password-useless/ Different sites, same idea!

                1. 5

                  “Only the dumbest, laziest hacker is stopped by the “username or password is incorrect” sign in.” I understand that this takes care of most of them, previously known as script kiddies.

                  1. 7

                    Theoretical example: login as TravisJeffery on YouPorn. Only “password is incorrect” shows up. What can you deduce?

                    1. 3

                      The rules are different when the existence of a customer account should be a secret. But porn sites tend to be poorly written and/or covered in ads which will track you across the web anyway. Use a throwaway.

                    2. 4

                      On services with large number of users typo in username can lead to account that also exists. In this case showing user if account with this username exists or not is meaningless.

                      1. 2

                        I agree. The error message is actually correct as written. The user entered their username incorrectly or their password incorrectly, or both. The application doesn’t know which and shouldn’t guess!

                      2. 3

                        There’s a usability reason to say this: the user may have mistyped their username rather than mistyping their password, so it’s worth telling them to check both fields.

                        1. 3

                          Alternate and more amusing solution, simply always say “Password is incorrect” even if no such user exists.

                          1. 1

                            As someone else below said, you can just always return “password is incorrect” regardless of whether the user exists. The key is not to vary the message based on whether the user ID entered exists or not.

                            The “ways to deduce a username” are also quite specific and only work because logins are username based not email based AND because GitHub profiles are public.

                            But hey, I guess “suggested method X doesn’t work quite as expected in situations Y and Z” isn’t as catchy as “X is bullshit” now is it?

                            1. 1

                              Have you read the article? “password is incorrect” doesn’t change anything. You could remove the error message and it wouldn’t change anything. The point to the article is that whatever you try to do, you can simply go to the sign up page and check if you can create an account under a given username or email and check the result. It is not specific to wether you use email, username or github profiles.

                              1. 3

                                Login page and signup page are two separate things where we have the same goal: don’t leak existence of user accounts.

                                On the login screen, returing the same error message all the time achieves this.

                                On the signup screen, the solution is simple: make usernames display only (ie not used for login) and dont show “already registered” errors for email.