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.
tldr; this is even worse than not hashing your passwords and storing them as plain text.
I agree with your lead dev’s concerns. In order to show past incorrect password attempts, you must store them in a reversible fashion, which means they cannot be hashed. If someone compromised the system, they would then have access to all the bad attempts, and likely could piece together what the true passwords are for some users. For example, if you can see some of my bad attempts were:
correct horrse battery staple correct horse batttery staple
It would be pretty easy to figure out my actual password.
I also agree with drewbenn’s answer: if I type in my username incorrectly but with my correct password, and the incorrect username happens to be someone else’s username, now that user can see my real password.
Once I tried to log into a system using my password but my coworker’s username.
Then there are all the times I used the wrong password when trying to log into a shared account.
And I know a lot of admins are granted access to their boss’ account so they can get things done. I’d be pretty shocked if their bosses had never entered the wrong password then gotten distracted by a visitor before logging in correctly to clear the mistake.
Plus all the typos when someone’s standing over my shoulder while I’m logging in.
And in all of those cases, sometimes I’ve entered my gmail or lastpass password into the password prompt at work, and vice versa.
And the time I googled my password because I wasn’t looking at the screen and just assumed it was locked. Not that that has anything to do with your proposal, but I like sharing that anecdote because it reminds people that everyone can make a mistakes and type in the wrong thing sometimes.
The only thing this hUnt3r2feature does is turn small mistakes (entering in the wrong password or mistyping it) into accidental exposures to a wider audience.