3

I am testing web application where in case of incorrect login attempt response contains sent earlier login and password (incorrect one). This values are in value attribute, like in this example:

<input class="form-control" data-val="true" data-val-required="Password required." id="Password" name="Password" type="password" value="qwerty" />

Is this a correct behavior, are there any recommendation concerning this issue?

Improve this question
3
  • 2
    keep in mind to sanitize every user input before you republish it
    – user169088
    Commented Jun 3, 2018 at 12:50
  • 1
    Are you saying that only the wrong value is echoed back?
    – jrtapsell
    Commented Jun 3, 2018 at 13:08
  • related in context of brute-force attack: ux.stackexchange.com/a/28013/115328
    – user169088
    Commented Jun 5, 2018 at 10:22

1 Answer 1

Reset to default
2

Incorrect passwords are almost as sensitive as correct ones - just think of all the times you failed to login because caps lock was on... Or all the times you have entered a password you use for another site by mistake.

But is this really a dangerous way to handle passwords, incorrect or not?

Let's concider security in transit first. Here you already send the passwords in one direction. Sending them back as well will not make things worse. So either you use good TLS and everything is fine, or you don't and then this doesn't make things any worse than they already are.

The next issue is security at the client. What I would be concerned about here are two things:

  • The user might not expect the password to remain accesible after clicking login. It would be easy to leave the password in an open tab. (The fact that it's a password input makes no difference here.)
  • If the page is cached the users password would end up in the browser cache. That's not so good. But responses to POST requests aren't cached, and hopefully they don't use GET requests for logins anyway. (If they do, there are bigger problems associated with that.)

Finally, on the server side a larger part of the application needs to handle the password because of this. That doesn't have to be a problem, but in general, the more you use passwords the easier it is to accidentally leak them to log files or something like that.

So in conclusion, I would say that this is not good practice. It fulfills not legitimate need. But the effects are not catastrophic either, so I wouldn't be to concerned with it. This is a case of small cost, no benefit.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .