Question:
It is common in many systems when entering the wrong username and password, the system informs us that one of them is wrong, but not exactly which one (this also happens here on Stack Overflow).
Does this happen to protect data? Or could we say it's because it's easier to do it that way?
Today in systems like Google and Microsoft it is different from the past, now they ask for the login first and only if it is correct they ask for the password.
Answer:
I believe the answers are good, but @Stormwind's answer about "a generic error message" got me a little puzzled.
Today in systems like Google and Microsoft it is different from the past, now they ask for the login first and only if it is correct they ask for the password.
I believe this is because the password is not that relevant. Two (or more) factor authentication already exists. In the past, just knowing the password already gave access to the account. Nowadays that doesn't apply, now you need more than just the password.
Specifically, Google even allows the use of FIDO U2F, which requires a physical key, USB, which contains an ECDSA key, in which the "challenge" is signed.
Anyway, even if the attacker knows the email and password, he still has a job. Therefore, I believe that it has become irrelevant for the attacker to know only the e-mail and as has been said, they started to inform the user what is wrong, improving his experience.
Does this happen to protect data? Or could we say it's because it's easier to do it that way?
Entering two strings of the same doesn't provide any security, you need to do the exact same thing. Otherwise, you can inform the attacker that the user exists or not, in other ways.
Consider this code, UNSAFE:
func login(w http.ResponseWriter, r *http.Request) {
var hashedPassword string
var username = r.PostFormValue("username")
var password = r.PostFormValue("password")
if username == "" || password == "" {
fmt.Fprint(w, "Você precisa enviar os dados")
return
}
err := db.QueryRow("SELECT `senha` FROM login WHERE usuario = ? LIMIT 1", username).Scan(&hashedPassword)
if err != nil {
fmt.Fprint(w, "Senha ou usuário incorreto")
return
}
if err := bcrypt.CompareHashAndPassword([]byte(hashedPassword), []byte(password)); err != nil {
fmt.Fprint(w, "Senha ou usuário incorreto")
return
}
fmt.Fprint(w, "Conectado com sucesso")
}
The code above will always say "Incorrect username or password" if you get one of the things wrong. You can say that the code above fulfills what @Stormwind says:
If you use a generic error message, you are "increasing security", as the attacker won't know if he got valid and existing names on your system […]
But… No. This doesn't add any security. An attacker can still get the original information, note that the processing time is different:
User "ThatDoes Not Exist":
curl -d "username=QueNaoExiste&password=a" http://127.0.0.1:8888/login -w " "%{time_total}
Incorrect password or username 0.000
User "QueExists":
curl -d "username=QueExiste&password=a" http://127.0.0.1:8888/login -w " "%{time_total}
Incorrect password or username 2,156
User "QueExiste" and with the right password:
curl -d "username=QueExiste&password=umasenhamuitolouca" http://127.0.0.1:8888/login -w " "%{time_total}
Successfully connected 2,157
A non-existent user does not BCrypt, so the result is faster than the one doing the comparison. The %{time_total} informs the total time spent until the request is completed. It's not enough just for the messages to be the same, you have to make it impossible to extract the true information by other means. In this specific case you should protect yourself from timing-attack .
This is just ONE of the thousands of methods that can be used, even where "the message is the same". In another real case, there is a website (I won't mention the name here) that when logging in, the client receives an id . But when trying to login from a non-existent account the id is temporary. Just wait some time and try to login again. If the new id is different from the old one, it's because it doesn't exist, if it stays the same…. You got the user right.
An equal message, for me, does not guarantee any security. There is more to it than just "one message the same".