I agree. I must have wasted weeks of my life trying to get access to systems that just would not tell me what went wrong.
Often just returning a 400 error code.
Or given the "username or password incorrect" message even it not true.
It is even worse when you are developing the client or trying to access a new server.
It could be a wrong user name.
Or I should have used my email instead of the user name or the other way around.
or the password
or it could be that the account is expired
or an expired certificate
or maybe some negotiation of encryption codecs failed
or an URL is wrong.
or maybe the server-side DB was down.
once it turned out to be a REST API that stopped accepting single-quoted strings generated by a client.
Then you click the "I forgot my password button" and nothing happens.
You do not know if an email was sent. Or if an email was sent, to which email address is was sent. Or if it was stopped by a spam filter.
I think there is a fundamental error in this post.
If there were targeted attack against a person sure, but IMHO this protects against simple brute force attack on the login page where the script just cycles through logins, finds a valid login, and then cycles through common passwords.
If the argument is that the attack scripts can also run against the registration page to correlate login, sure, but you've just made the life harder for the attacker.
Good point. I think this is a case of cargo cult programming--it makes good sense in situations where you can't just sign up but as he shows it's meaningless in situations where you can. The standard was laid down before the world became full of sites where you can simply create an account for free.
There’s a pretty trivial way to fix this, if you’re willing to block post-signup access until the email is verified:
1. Make the signup look like it was successful.
2. Tell the user to check their email.
3. If the account already exists, send an optional password reset email to the account owner (tailored to explain what happened if you prefer, throttled to prevent spam/abuse as you see fit).
4. If you want to go the extra mile, check for password reuse and make the password reset mandatory, or at least strongly encourage it in the email.
The vulnerability lies in the registration page disclosing that information. To show absolutely no signs, you would accept the registration with a message: "An email has been sent to the provided address."
Obviously this is less convenient and arguably not a critical vulnerability for GitHub. The good news is, the registration page doesn't disclose which account an email address is associated with.
While usernames are easy to figure out, I think email divulgation should be taken more seriously.
Even a registration form should not inform you that the email is already used. This information could be given ... by sending a mail.
While disclosure of the existence of an account with your email have minimal impact on Stripe or GitHub, what about a dating site ? What about a politic website ? How about some sensible professional tool ?
Not all security threats possible are from mr. robot episodes and involve sophisticated hackers. There are also a lot of straight up dumb people out there with malicious intentions. This method is more like a speed bump.
[+] [-] nelgaard|5 years ago|reply
It is even worse when you are developing the client or trying to access a new server.
It could be a wrong user name. Or I should have used my email instead of the user name or the other way around. or the password or it could be that the account is expired or an expired certificate or maybe some negotiation of encryption codecs failed or an URL is wrong. or maybe the server-side DB was down. once it turned out to be a REST API that stopped accepting single-quoted strings generated by a client.
Then you click the "I forgot my password button" and nothing happens. You do not know if an email was sent. Or if an email was sent, to which email address is was sent. Or if it was stopped by a spam filter.
[+] [-] yumraj|5 years ago|reply
If there were targeted attack against a person sure, but IMHO this protects against simple brute force attack on the login page where the script just cycles through logins, finds a valid login, and then cycles through common passwords.
If the argument is that the attack scripts can also run against the registration page to correlate login, sure, but you've just made the life harder for the attacker.
[+] [-] LorenPechtel|5 years ago|reply
[+] [-] eyelidlessness|5 years ago|reply
1. Make the signup look like it was successful.
2. Tell the user to check their email.
3. If the account already exists, send an optional password reset email to the account owner (tailored to explain what happened if you prefer, throttled to prevent spam/abuse as you see fit).
4. If you want to go the extra mile, check for password reuse and make the password reset mandatory, or at least strongly encourage it in the email.
[+] [-] miccah|5 years ago|reply
Obviously this is less convenient and arguably not a critical vulnerability for GitHub. The good news is, the registration page doesn't disclose which account an email address is associated with.
[+] [-] callesgg|5 years ago|reply
Well I guess they can figure that one out by signing up with my email. Cause when you do that websites tend to complain(I think).
But given my previous statement I guess I think that would be the flaw if anything should be seen as a flaw.
[+] [-] pjerem|5 years ago|reply
Even a registration form should not inform you that the email is already used. This information could be given ... by sending a mail.
While disclosure of the existence of an account with your email have minimal impact on Stripe or GitHub, what about a dating site ? What about a politic website ? How about some sensible professional tool ?
[+] [-] yongjik|5 years ago|reply
What if the user typed a wrong username that matches another existing user?
[+] [-] watermelon0|5 years ago|reply
What you suggest shouldn't be possible because:
- multiple users can have the same password
- properly hashed passwords rely on per-user/per-hash random seed, which can be only determined after user is found in the database
[+] [-] scyzoryk_xyz|5 years ago|reply
[+] [-] tardyp|5 years ago|reply
[+] [-] Tepix|5 years ago|reply
[+] [-] high_byte|5 years ago|reply
just tell me which one is wrong dammit!!