8

From my experience, 99%[citation needed] of the time, when you try to log on to a website, and you mistype your password, you get some indication that the login could not proceed due to incorrect information and the password field is cleared out. Usually the username field remains filled in, so you simply have to retype your password.

In a small fraction of instances, I've found that some websites do not clear out the password field after an incorrect login attempt. Is this a security issue? I can't think of how or why it may be, but I find it odd behavior since the overwhelming practice seems to be to clear the password field. Can this practice be exploited in some way by someone?

As an addendum, is there some sort of standard that says the password field should be cleared out after an unsuccessful login attempt or is this practice something that most websites have converged on without formalizing anywhere?

  • 1
    The Windows 10 login screen actually keeps it populated. It's annoying AF!! How does it help a user to populate a field with an incorrect value that is masked? There is no way to tell which character(s) are incorrect so you have to retype it anyway. To make matters worse, Windows 10 leaves the caret at the end, so you have to backspace over the whole thing or hit ctrl-A (select all) to clear it out. I don't think there is a security issue, but it is a usability issue for sure. – John Wu Jan 4 at 1:01
  • 4
    @JohnWu, Windows 10 has the ability to show the password when you click the eye-shaped icon that appears when there's something typed in. (It follows the specific NIST standard that I quote in my answer.) – Ghedipunk Jan 4 at 3:21
  • This is a UX issue, not a security issue. – caw Jan 4 at 20:39
  • @caw, usability and user-experience issues around security related features (such as a login screen) are security issues. Poor usability of a security feature makes people look for ways around that security. For example, not being able to paste passwords in (or otherwise use a password manager), not being able to verify a password before sending it, and being restricted in what types of characters are allowed in a password will cause people to pick easy-to-remember passwords, which greatly increases the chances that the password is one they've reused on other services. – Ghedipunk Jan 8 at 15:40
  • @Ghedipunk Sure, UX issues can have consequences for security, but here, the question was if this has direct implications for the security of the site, since the question was whether the behavior can “be exploited in some way by someone”. It cannot. The worst thing that can happen is that you must clear the field yourself before entering the password again – and that is only if there is no “Show password” button or icon. This is really not the same as preventing paste in password fields. – caw Jan 8 at 15:46
5

As a general rule, the server should not provide information about a submitted password, regardless of if that password was correct or not, back to the client.

After all, humans tend to reuse passwords, so even if the password isn't correct for that user on that site, it may be correct on a different site, such as their bank.

I'm not aware of any ways to intercept a password that applies only to receiving the password, that wouldn't apply to sending it as well. However, the fewer number of times a password crosses a network, the better1.

If the application submitting the password does a full page refresh, then the attempted password most definitely should not appear in the password field, because it requires the server to send that information back.

If, instead, the application submits the password through an AJAX request or some other means that does not update the page (or the login form), then it is safe for the password to remain in the field, as opposed to being re-filled in for you by any action from the server.

The only ways that I can think of that it might not be safe, is in cases where (potentially) malicious scripts are loaded after an authentication attempt. However, I consider such a vector to be unlikely and contrived, and the possibility indicates that the site itself is untrustworthy, regardless of when it loads the scripts. (Related tangent: Don't reuse passwords. Use a password manager and generate random passwords for every site; you never know when a site may be compromised (whether intentionally or not).)

The closest that the NIST standards on passwords come to making a judgement on this specific case, in section 5.1.1.2, says (emphasis mine):

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.

A strict reading of this could be interpreted as clearing the password field every time it is submitted, whether using a full page refresh or using an AJAX request. However, it is part of a "SHOULD" statement, rather than "SHALL" statement. Regardless of how strict one interprets this, the entire standard seems to assume that submitted passwords are never repeated by the server.


1Quick side note: I see a lot of people suggest to send a hash of the password, rather than the password itself, to prevent it from going across the network. This doesn't improve security because when doing that, the hash becomes the password.

|improve this answer|||||
0

I don't see severe risk with this, but as an attacker one can recover your previously typed password using developers tool (changing type=password to type=text) and can get idea about your password setting pattern.

|improve this answer|||||
  • 4
    That is not an attack vector that would be in the threat model of website developer – Vipul Nair Jan 3 at 18:57
  • Don't understand that comment. – uav Jan 3 at 21:07
  • 5
    @uav, what Vipul Nair means is, the web developer can't control whether or not a user (or scripts installed on the user's machine, such as browser plugins) can or will change the DOM on pages from their site. Thus, since it's completely outside of the developer's control, it's most definitely not the developer's responsibility. – Ghedipunk Jan 3 at 22:29
0

This usually isn't a way someone could get your password. The only way I could think of is that someone can copy and paste the password out of the field. But I think this is blocked by most systems by default.

|improve this answer|||||
  • It is blocked by default, but it is trivial bypass that as explained in Kailash's answer. – Fire Quacker Jan 3 at 22:24
  • 1
    If an attacker has access to the DOM, you have much more serious problems than the attacker being able to change a password field to a text field. – Jörg W Mittag Jan 4 at 9:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.