The right answer isn't a blanket "sites should do this super-secret e-mail-only shuffle and not tell you anything".<p>First, you should define your threat model: which information is considered secret and which isn't, and treat any violations as security vulnerabilities.<p>If usernames are public by design, then don't hide them in one form, and expose in URLs elsewhere on the site.<p>If exposing who's registered on your site really is a threat, then by all means have a weird registration (and password reminder) that doesn't tell whether it worked or not. But if your site is for cookie receipies and you don't consider exposing who's a fan of cookies a privacy violation, then just use most helpful messages you can.
I have an argument for "username or password is incorrect" messages: it's possible that the password is correct, username exists but isn't the intended one. Then "password is incorrect" message would be lying, as the issue is actually with a username.
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.<p>So for login: always say "email or password is incorrect".<p>And for register: as he said, always say "we sent you an email to verify your email".
Not quite on topic, but it would be nice if more websites would offer the option of using client side TLS certificate "login" with or without an additional prompt for a username and password.<p>It would be next to impossible for an attacker to bypass that. For example, even if the attacker provided the correct credentials, they most likely would not have the associated client-side TLS certificate private key. Then the server could just reject the log on attempt outright (since the certificate wasn't provided or verified).
Even if this doesn’t increase security, you should still do it in the hope the user will check the username they’ve just typed as well as retyping the password.
The article explains how to do it properly at the end:<p>> To prevent attackers from knowing whether an account exists or not your signup must only take an email address and provide no feedback in the UI if the sign up succeeded or not. Instead the user would receive an email saying they’re signed up.<p>Is this not also part of the various 'best practices'? (I confess I don't read too many of them!)
The solution is relatively simple.<p>1. Email and password for login. Don't tell the attacker which is correct.<p>2. Email and password for registration. On registration send confirmation email. If user is already register attacker would need access to their email. Access to email is game over.<p>So now an attacker can't see which users are registered with your service and you've protected your customers privacy.<p>Extra points if your code is aware of timing attacks.
The title is "bullshit". The real problem is that they leak the information they try not to leak anyway, on a different form. This is a common, but not universal, problem.<p>It's not OK to leak information, even if that information is maybe leaked somewhere else already.
Ask HN: Why does Amazon allow multiple accounts with the same email address? (2014) | <a href="https://news.ycombinator.com/item?id=7075372" rel="nofollow">https://news.ycombinator.com/item?id=7075372</a>
Isn't the other reason so that adversaries can't tell if a particular username/email has signed up? This is not so useful for something like github, sure, but certainly is useful for the more embarrassing sites where users have an expectation the site won't leak their membership.<p>So in some ways I've always thought of this as a privacy concern rather than a security one?<p>Edit: I guess I'm thinking purely of emails where you don't get availability checkers during sign up.
If you're just trying to find a set of accounts with a weak password, isn't it much more viable to use the sign-in page that shows "invalid password" instead of "invalid username or password" rather than dealing with captchas on the signup page? Assuming you can't just find usernames as public profiles like on GitHub.
There's definitely a trend away from this to some degree lately, I feel. It's probably more influenced by Google not doing it with their accounts (enter username -> forwarded to password page with your avatar) more than anything else, mind.
I asked this same question[0] on StackExchange earlier this year. It has been asked many times and it really comes down to considering a username a secret or not.<p>In B2B applications where there is no registration form, then the username is probably a secret. In B2C applications where anyone can register, then the username likely isn't a secret. Many of those applications have the concept of "mentions" by username so clearly the username is not considered a secret in that case.<p>[0]: <a href="https://security.stackexchange.com/q/158075/11536" rel="nofollow">https://security.stackexchange.com/q/158075/11536</a>
Try searching for your username on <a href="https://namechk.com/" rel="nofollow">https://namechk.com/</a> <a href="https://www.namecheckr.com/" rel="nofollow">https://www.namecheckr.com/</a> <a href="http://checkusernames.com/" rel="nofollow">http://checkusernames.com/</a> or <a href="https://pipl.com" rel="nofollow">https://pipl.com</a>. I am sure these name checkers can't be built if they have to spam the sign up forms just to check availability (at least not for free if they have to pay for manual recaptchas).<p>The privacy is worth it.
This is actually a feature for users who have almost the same username and mistype this instead the password. E.g. this could probably happen through an unfamilar kayboard layout.<p>I understand that a lot of people think this is a security feature, but once upon a time it was the lazy programmers answer when "SELECT * FROM users WHERE username=? AND password=?" didn't return a result.<p>With proper salts for hashed passwords you now have to find the username, use the salt to hash the password and compare this. If your database allows to hash passwords with a dedicated function it's still the easiest to say username OR password must be wrong.
Stripe does it wrong, so it's wrong everywhere? Nah. <i>That's</i> bullshit.<p>For emails, you can very easily fake a second signup with the same email and ping out an enhanced verification email "Somebody just tried to register with this address but you already have an account".<p>Building the username into that flow is harder. That's why I preference not having separate usernames but some people would argue this is itself a bad thing (removing a factor or somesuch).<p>Either which way, <i>Stripe's approach is broken</i>. That doesn't make the whole idea nonsense.
Here is a super useful article about how you should build login <a href="https://blog.codinghorror.com/the-god-login/" rel="nofollow">https://blog.codinghorror.com/the-god-login/</a> (if you don't want to rely on professionals from Auth0 or Okta :-). In the article, there is a very good statement "being user friendly is way more important than being secure" and this is exactly this case also...
> Even if reCAPTCHA was perfect, a hacker could manually validate their usernames of interest by trying to sign up, then automate an attack on the sign in page.<p>Why is imperfect reCAPTCHA worthless? Do sign up pages even allow brute forcing of usernames (once validated)?<p>Is he suggesting to fix sign up pages, or to allow brute forcing usernames on login?<p>His writing style is dramatic, but the arguments are very weak.
My other favorite security theater advice is locking an account after x number of failures. How could this used for anything but DOS?<p>Depending on the service that's being protected, rate-limiting to 5 minutes between attempts, alerting the owner, and assigning them a temporary username seems more reasonable countermeasures to me.
After reading this I went straight to change the login system I'm currently working on ... And discover that I would need to add some extra code paths / conditionals ... So for me it's not "best practice", it's more todo with laziness and not wanting to add complexity to critical functions.
This is a pointless argument because I doubt Github or anyone who uses this message seriously considers it to be a security measure. Github's usernames are absolutely public. But they also have so many users that I suspect the wrong username is typed all the time. So yes, sometimes maybe the username is wrong.
What’s the point of having passwords at all? If there’s a password reset mechanism they provide no additional security. Just send a one time login token to the email.<p>Having a password just increases the odds of a hack by the user accidentally exposing it.
Also if you are doing the username/password is incorrect you should also add an artificial delay if it's the username is wrong. Because you can tell which one is wrong my seeing how long it takes the server to respond.
I suggest we just randomly say your username or password is incorrect.<p>"Your username is incorrect"
"Your password is incorrect"
"You hit the wammy. Try logging in again."<p>That way, you never know what's going on at all.
In the article:
"You gain no security, yet your customers lose clarity."<p>Oh boohoo. Like it's not on the customers side to know which email it is and which password.<p>And as many have said, one does gain privacy.