Is there any reason to not show users incorrectly entered passwords after a successful login?

  • Our client has come up with the requirement that in case the username in question has had multiple failed login attempts, the incorrectly entered password(s) must be shown once a successful login is performed. Correctly entered information, including previous passwords, will not be shown in any case.

    Our lead dev has told us it is technically possible by not hashing incorrect entries, but she is extremely uncomfortable with the feature and thus it has been put on hold while we brainstorm it out.

    The website in question is a broad mapping/GIS application that does not feature any monetary transactions whatsoever. Other login/authentication options include Google/LinkedIn/Twitter/facebook, so obviously no passwords to be stored there and handling that is primarily a UX issue.

    What security vulnerabilities come with implementing such a feature? Our client is not entirely without technical knowledge so a general explanation is enough.

    My apologies if the question is too broad or the answer very obvious.

    Ask the client why. Then ask why about whatever they say. They may have an idea, but surely they don't want to do this.

    enormous legal liability - do not implement unless you have the client remove all legal obligations on your company's part

    What @timpone says. Because, as anyone in infosec perfectly well knows, humans often have 100 accounts (I have 154) and no human can remember all that, reuse happens. Even if your site has little to lose, and even if the user shares its password with other sites with little to lose (eg FooFlix, what's he gonna do, steream some movies?) imagine his surprise when a hacker *finds a way* (e.g. buying thousands of dollars of gift memberships).

    (Convince your client and) just go with the standard screensaver info: *"The had been X unsuccessful login attempts"*.

    Show them an SSH log from a public server, show how it's continuously logging failed logins from around the world. The most likely content of that log will be 100Mb of attempts of "password", "1234", etc - not useful for someone to see *every login*. If you do clear the log after a successful login then someone will never know if someone else logged in as them after password guessing a few times. If you don't, then you forever see previous typos that you know about and don't care about. And if you DO see two failed logins, what use is that anyway? Who benefits in any way from this "feature"?

    Tricky... I for one have a (large) set of passwords I use on various sites, so while a password may be incorrect on one site, it would still be correct on several other sites. Subsequently, I'd prefer that a site didn't seem to store my "incorrect" passwords, nor send them back to me **in the clear** for anybody to read!

    Instead, provide a button a user can click to mask/unmask the password field. Passwords shouldn't be shown unless the user expects it.

    Secure storage of the incorrect passwords is possible. But the answers provided so far already give you sufficient reasons why you shouldn't do it. So I am not going to give you the algorithm. Instead I am going to tell you that the passwords belong to the users. The passwords do not belong to your client. What your client is asking you to do is abuse of those passwords. You have got to ask yourself if you really want to help your client abusing their users. What you really need is the best possible argument to convince your client to go with a proper solution instead.

    Maybe your client meant to show the number of incorrectly entered password instead of the actually incorrect passwords. The first is what SAP does too. The latter is unheard of.

    This is a terrible idea. The hashing issue and the crossed account username/password exposure issue should rule this idea out. I always look around for answers to problems like this and think if this was a good pattern places like google etc.. would use it. Point this out to your client along with all the already mentioned points. Always remind clients that the wheel seldom needs reinventing.

    **Bad bad bad:** `hunter3`, `junter2`, `hunrer2` and now you know my password.

    I know of a website that does this (or at least, used to). And I took advantage of this "feature" to bypass this website's ToS about not sharing contact info with other users.

    High five to the lead dev who expressed discomfort and provoked this issue!

    If you could measure how different it was from the original password you could show typos, but then you would have to store your passwords unhashed.

    just adding ingredients to the already great answers above use this site to see

    In general if I found an Open Source project doing this I would probably assign a CVE identifier to it as this would generally be considered a security vulnerability.

    as a sysadmin, It's useful to characterize failed attempts in some way, to distinguish between a user trying to remember and type his own password, and some sort of attack. If the former, offer the user help. If the latter, start defensive measures.

    your lead dev is smart, don't let her go

    Two word: transposition errors.

    If I encountered a system that presented me with my plaintext, mistyped passwords, I would close my account and stop using that system and recommend to friends and family that they avoid that service. It's virtually guaranteed that if I typed my password wrong, it's either off by one character, or I typed one of my passwords from a different account. Either way, it is negligent for any company to be keeping a list of my mistyped passwords. This is just an abysmally bad idea.

  • PwdRsch

    PwdRsch Correct answer

    5 years ago

    The primary issue is that incorrect passwords have to be stored in a way that allows them to be later displayed to users. Which, as your dev pointed out, means they can't be cryptographically hashed first. The result is that you store them either as plaintext (bad) or encrypted (better but not normally recommended).

    The biggest risk is if this database of invalid passwords becomes accessible to attackers. Either they compromise the server, perform SQL injection, or retrieve it in some other way. Rather than cracking the primary passwords, which hopefully are strongly hashed and therefore tougher targets, they could decide to compromise accounts using the information in the invalid password history. Either they access the plaintext passwords easily, or they attempt to find the encryption key that allows them to decrypt back to plaintext passwords.

    A common source of login failures is minor typos during the password entry process. So my password is Muffins16 but I type in mUFFINS16 because my caps lock is on. Or Muffins166 because I hit the same key twice. Or Muffina16 because my finger hit the wrong key. As you can see these variations are close enough to the original that attackers can probably determine the valid password from invalid passwords by trying a few minor alterations or comparing wrong passwords to likely dictionary words or names.

    This problem is exacerbated because most people use password choices similar to these formats and not random strings. It is harder for an attacker to identify the typo if your invalid password is V8Az$p4/fA, although still much easier to try variations of that then guessing it without any info.

    Another risk is that users may not remember which of their passwords they used on this site so they try their common ones. Now this site is suddently a bigger target because an attacker might be able to not only compromise a user's account there but also on other sites with the handy list of 'invalid' passwords.

    You can mitigate some of these risks by wiping storage of invalid passwords immediately after display following a valid login. That should limit the window of opportunity for an attacker to access and benefit from the data.

    The question you should probably ask your client is how they predict users will benefit from seeing their invalid passwords. Is it so users can identify how they mistyped their password? Typos aren't intentional so it's not likely that showing them their mistake will improve future login attempts. So users can identify an attacker trying to guess their passwords? Similar feedback can be provided by listing date, time, IP/geolocation or other info for invalid attempts without the attempted password. So users know that they screwed up during password entry and don't blame the site's login system? This seems like the only one with merit and I'm not sure it provides enough value to justify the risk.

    My guess is that once you better understand what they're trying to accomplish with this feature you can probably suggest more secure alternatives.

    What's your email so I can try the password Muffins16 on it? I mean, discuss this important topic with you further?

    Obviously that's a trick, the real password *is* mUFFINS16.

    Cracking the database would be *extremely* easy—just try 1000 incorrect password attempts on several dozen accounts before stealing the encrypted database. Voila, you now have several thousand "known plaintext" wrong passwords in the database from which you can work out the encryption key.

    @Wildcard um, what? Why would known plaintext help crack the key of a modern crypto algorithm?

    At least one system's root password was compromised from the incorrect passwords list.

    @Ben I think his point is about cracking the wrong passwords that are stored in the database. Assuming those are stored encrypted. If an attacker has, or will have access to,data from the DB, then having a very big range of known input will aid in reversing the output, hence revealing the encryption used which means that you will then have easy access to any wrong password stored in the database.

    An upvote wasn't enough for this amazing answer. Really appreciate your contribution..

    @vlaz the point is that modern crypto is not vulnerable to a known-plaintext attack so having any number of known plaintexts will not help you crack the encrypted passwords.

    Another pretty big issue is shoulder surfing. I don't need to crack your server if simply looking at someone's screen achieves the same. And, of course, if the CEO skimped on an SSL cert, you have much bigger problems than that, so you might as well not exacerbate them even further.

    Aside from the fact that the general idea isn't all that great; could the primary risk identified here be mitigated by accumulating incorrect password attempts in a cookie rather than persistently storing them server side, or even just doing it entirely client side with local storage? You'd lose the ability to see failed logins from other machines... but it's not really clear that that's a requirement from the OP's description.

    If the intention is to show how users are mistyping their passwords, the most secure option would be to provide a button to show their password as they type. And it'd be best to not submit the visible value; that is, the `

    @JasonC: unfortunately storing passwords in cookies poses the same risk as they can be used to guess your password from your failed attempts. Even if cookies are encrypted, the key has to be stored somewhere. If that key gets compromised, its game over (accessing the cookies its very easy if you have physical access to the device, and relatively easy if you can inject some code into the system).

    @lepe You don't need a cookie for this. When the server responds with a failed login attempt, couldn't the client store these values locally, in memory? Then, once the server finally responds with a Login OK, the client can show any passwords it has in memory. None of this requires storing unhashed passwords on the server side or in a cookie, and doing so does not introduce anymore risk than is involved in gathering and submitting the login credentials in the first place.

    Another issue would be people forgetting which password they used for your login. I imagine there are a substantial number of users that use a handful of passwords across all accounts. If one doesn't work, they just loop through their list until one works. Saving their failed attempts means saving actual passwords on other sites.

    @Andonaeus: yes that is a possibility. It's still unclear to me what is their intention behind that request. If they want to show any login attempt (which I feel it might be the case), then what we are discussing here is a totally different animal.

    No matter what you do, the incorrect password is going to be stored somewhere in memory temporarily. Normally to keep this longer you'd just store the password in a session, which is temporary and normally only in memory, and not in persistent storage. Frankly, what's the real added risk here that the bad passwords are stored for a longer (minutes?) period of time while the user logs in? To even perform the hash, you obviously have to have the password in memory, so you'll never get perfection anyway.

    @corsiKa My kids tell me that if the password is Muffins16, then the email address must be [email protected]

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM