42
It is common in many systems when entering the user and the incorrect password, the system informs us that one of them is wrong, but not exactly what (it happens also here in Stack Overflow).
Does this happen to protect data? Or could we say that it is because it is easier to do so?
Today in systems like Google and Microsoft is different from the past, now first ask the login and only if it is correct ask for the password.
27
I believe the answers are good, but @Stormwind’s response to "a generic error message" left me a little puzzled.
Today in systems like Google and Microsoft is different from the past, now first ask for the login and only if it is correct ask for the password.
I believe this is because the password is not so relevant. There is already authentication in two (or more) factors. In the past, only the knowledge of the password already gave access to the account. Nowadays this does not 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 it signs the "challenge".
Anyway, even if the attacker knows the e-mail and the password, he’ll still have a job. Therefore, I believe that it has become irrelevant the attacker know only the email and as has been said, have started to inform the user what is wrong, improving his experience.
Does this happen to protect data? Or could we say that it is because it is easier to do so?
Reporting two identical texts does not provide any security, you need to perform exactly the same thing. Otherwise, you can inform the attacker that the user exists or not, in other ways.
Consider this code, INSECURE:
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 above code will always enter "Password or incorrect user" if you miss one of the things. You can say that the above code meets what @Stormwind says:
If you use a generic error message, you are "increasing security" since the attacker will not know if you have taken valid and existing names on your system [...]
But.... No. That doesn’t add any security. An attacker can still get the original information, note that the processing time is different:
User "Domain name":
curl -d "username=QueNaoExiste&password=a" http://127.0.0.1:8888/login -w " "%{time_total}
Incorrect password or user 0,000
User "Queexiste":
curl -d "username=QueExiste&password=a" http://127.0.0.1:8888/login -w " "%{time_total}
Incorrect password or user 2,156
"Queexiste" user 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 do Bcrypt, so the result is faster than the one that does the comparison. The %{time_total} informs the total time spent until the request is completed. It is not enough that the messages are the same, you have to make it impossible to extract the true information in other ways. In this specific case you should protect yourself from timming-Attack.
This is just ONE of the thousands of methods that can be used, even where "the message is equal". In another real case, there is a website (I won’t mention the name here) that when logging in, the customer receives a id. But when you try to log in to a non-existent account, id is temporary. Just wait awhile and try a new login. If the new id is different from the old is because it does not exist, if it remains the same.... You hit the user.
An equal message, by me, does not guarantee any security. There are more things to be done than just "an equal message".
Usually more modern systems of user validation it is recommended to make a forced wait, precisely to avoid this type of Chanel Attack side
Good answer. That is, since giving a generic response does not necessarily protect, it is better to give an answer that really helps the legitimate user. :)
18
There are already some threads in the Information Security, site of Stack Exchange specific on information security, which deals, more or less, with the same subject. Actually there is a tag specific to this topic, user-enumeration.
In one of the questions asked there, is asked if there is any specific reason and if it is useful to show a generic error message like "Password or username are wrong". Speaking based on my research related to security, I would like in a synthesized way to share some points, I found about the use and operation of login system:
[...] It is beneficial to increase the difficulty for attackers to collect valid user names, but it is usually a cost to users. [...] You will have to determine if your security requirements will have priority over user experience.
Note that a generic error message does not help the user at all. Giving a generic response does not necessarily protect (see quotes and italics in "increasing security"), then it is better to give an answer that really helps the legitimate user.
The purpose of an error message is to help the user who encountered the error, to learn how to avoid the behavior that caused the problem. The program has found a situation that it cannot handle and needs to tell the user, so that the user (or someone else) understands and can avoid the situation that the program cannot handle. [...] The error message that says: "an unexpected error has occurred" is totally useless in this objective. Gives the user no hint as to what can be changed to avoid the problem, or even fix this issue.
In general, it is not always possible to determine who, what, where, how, when and why the error occurred. However, it should be taken into account that a good error message should contain a "species" minimum, complete and verifiable example:
In a synthesized way, explain the minimum to your user, but in a clear and understandable way, and if possible do something that allows the user to know that the problem is not being ignored. Let them take some action, how to send the logs or send an error report. Alternatively, let them know that the automatic action has already been taken and that your technical staff has been automatically notified that this error has occurred and is working on it.
See the image below. It is not specifically related to passwords, but it demonstrates well what I mean about generic messages and UX:
Who has never been p*** when you saw this screen of death and wanted to break your computer because Microsoft gave that damn blue generic error message? This is the feeling that users get when they see a message like this. Sure there are very few who can solve this problem, but see how bad it is by itself. Still as if it is not enough, they give some "Small letters in capitals", tell me to look on the internet for a solution to some ""Small letters in capitals"" I’ve forgotten which ones are and still turn off my computer.
An application must respond with a generic error message, regardless of whether the user ID or password is incorrect. You should also not indicate the status of an existing account.
However this is a consideration between security and usability. It’s still a good idea for most sites not to disclose if there is a username, but the risk needs to be weighed against the new user registration process.
A simple attack Brut-force in "next page" Wouldn’t it already damage your entire super secure login system? It lacked to balance the security with usability of the pages, therefore it was of no use to give a generic response to the user and you were still invaded. In the latter case discussed I recommend reading this question and even think of implementation of a captcha.
Finally, in all this reply again the word to be analyzed is usability. As well as everything related to UX, you will have to determine if your security requirements will take priority over the user experience.
[...] Unless you are ready to sacrifice a significant amount of usability [...]
13
Today very rarely will someone do something like this because it is easier to program. Of course, if the programmer is a layman, and many are, maybe he does it out of ignorance, but it’s never the case of a large site or app.
If you tell him which one is right, a portion of the authentication is solved for the attacker and he no longer needs to worry, decreases the combinatorial analysis he needs to do. Not knowing if one of them is right needs to keep trying other options in brute force.
Some people dispute this because with a strong password and limitations of attempts the chance greatly reduces to such an extent that this gain, which is not even small, becomes unnecessary. Thus it can give more useful information to the legitimate user than he has erred and needs to check. What is a gain in user experience but is small.
The system of login "modern" probably changed as experience improvement. As many people manage multiple accounts and passwords this can help. Probably they preferred to facilitate for the legitimate user even risking a little with the illegitimate because in practice the increased risk, although large, is statistical.
There is a chain that considers that less information helps the user to use the system, even if this adds steps. Having to choose where to type can confuse certain users. A guided system makes it easy. This is probably true, but it hurts more accustomed users who have a separate step to take. Nothing that changes that much, but in UX little things make a difference for good or bad.
But it’s possible that it’s also changed through security. Still would have to hit the user in brute force and then when hit would have to hit the password, can even become a new kind of barrier.
It is possible that they are using even other barriers. And a different authentication system that even brings some advantages against attack.
Nor did I mention that on very small screens increasingly common (watches, for example) where separation makes sense.
There are other reasons for this choice, but they are not usually relevant. Access to the database certainly does not weigh in the decision. This should be optimized. Even if it is not, it should not weigh more.
One important thing to analyze is the size of those who use the technique. Just as I usually say that many people go after the same technology of Google, Facebook, etc. when they do not have the same need, these suppliers can avail themselves of it, as the comment of Bacco in the question. For their volume makes no difference.
The fact that there is authentication in two factors does not mean anything because many people do not use it and still ask themselves separately for these users. Bacco’s hypothesis makes more sense.
Surely these companies have statistics that show that it is irrelevant to be this protection by obscurity.
For not having full knowledge of the subject I avoided drafting an answer. For example, I never measured the impact of first rescuing the user to then redeem the password vs simultaneous rescue of user and password; only knew that I had communication with the bank is that maybe latency could have some influence. Thank you for always giving those multifaceted answers
@Jeffersonquesado still need to improve some because these things you will remember new things, see what others have remembered and develop, so everyone learns together. But I couldn’t do it in the next few days. The question of the bank has ways of resolving not to be consulted every time, with some risk, but very small to create a racing condition, then it is a matter of seeing what pays off. Even if you don’t optimize anything, the cost is too small to avoid access by making the experience worse.
9
In relation to the best practices of UX, other answers already sufficiently address the subject.
In contrast to answers that claim segurança as a reason:
Not, this does not protect the data.
As mentioned by @Inkeliz, in the first instance the system should check the nature of the request.
The server must be prepared for this reading, otherwise, regardless of the implemented UX, the system will be vulnerable.
It must be taken into account that an attacker willing to hack into a system will not simply carry out a manual attack of attempts to log in, or attempt some brute force attack to discover 1 user and 1 password that are valid, simply because it can "create" your own user and from that "new user" explore "system failures".
If it does not give him to create a "new user", in case of closed systems, or he will use Engenharia Social, or it will attack the network to find the faults.
I speak superficially about this reasoning in this reply
When the crux of the matter is "security" UX is irrelevant (roughly speaking, there are factors in UX that can in one way or another collaborate to the lack of security). It is necessary to understand how attacks are made and for each group of systems there are N types of attacks.
Unlike closed systems, on the Web for example, expensive servers already leave a door open full time to receive requests, so there are "sniffers(sniffers)" who find these routes gathering information that will be relevant to taking a step forward to an attack. Many servers, are implemented with a minimum level of security and even without, by unprepared of those who implemented. Then the server responds to requests with dados that will be used to carry out an attack. The operating system, becomes the target (not the user "Crazy of the crooked legs" of the face).
There are groups that are heavily equipped with the most varied technologies to carry out attacks, and the well carried out attack is imperceptible, the administrator will not even know.
In summary the security architecture should take into account the nature of the system, users and possible attacks and use this in favor of the system.
Generally below the surface, UX is irrelevant to security, as quoted in the reply I put link.
3
Yes, this is to help protect the data (and the account).
Not because it is necessarily easier, but because it contributes a little more to safety. Not revealing which data is incorrect is a way to make it difficult to access a supposed attacker, and this way he doesn’t know what went wrong (user or password).
Currently, more secure systems still ask for the password when the user, even logged in, tries to do critical operations within the account, things that can affect the account itself and the security of the information, such as deleting or altering personal data, transactions involving values and, mainly, delete the account itself.
Browser other questions tagged security-guard ux
You are not signed in. Login or sign up in order to post.
Briefly speaking: this is to avoid giving hints to a possible attacker who hit the user; at length: not doing user verification and password separator implies a single access to the bank, which implies performance gain by not expecting communication latency. Not to mention that consulting only one or both has basically the same weight. Expecting someone to provide a more complete and reasoned answer of the subject
– Jefferson Quesado
Well, I can’t tell why Google changed the password validation design, but these were the reasons I knew
– Jefferson Quesado
This basically depends on the volume of users in the application. If you have a small system with a hundred users, the correct user information is precious. In the case of google and MS, the vast majority of the things you "kick" is a valid user, so it is irrelevant to protect this part of the credentials, which consequently allows you to rethink the mechanism. On the usability of the UI, they are equivalent solutions. The "effort" to switch fields on the same screen is equivalent to entering the username to jump to the next screen, so the choice of steps will be made by other criteria
– Bacco
Curiosity: as always, Google implodes things "more or less". I’ve noticed a lot of places where you have the time to hit the user, but the avatar doesn’t show up (which totally ruins the advantage of you evaluating whether it’s in the correct form, not a fake one). At first I thought it could really be a Mitm attack, but I confirmed in completely different places and equipment and with more than one account (from different people, including).
– Bacco