I use KeePass with auto-type, and once in awhile (when tired, etc.) I'll accidentally launch a similarly-named entry's URL and try to logon with the wrong U/P. This question is unrelated to KeePass per se.

I'm just wondering if attempted logons are recorded and logged by the "wrong" site, allowing site admins to see an unrelated logon which they might abuse.

  • I don't understand the situation. What do you mean by "attempted"? Did you enter anything? – schroeder Mar 2 at 7:34
  • 20
    Just to add some practical advice to the existing answers: it would be best if you change the password after putting it into the wrong website or had the password be put in the username field, but unless it was a phishing/typosquatting site, the risk is relatively low. Definitely recommended for more important accounts (e.g. PayPal, or your company's credentials), though, also for liability reasons. – Luc Mar 2 at 8:36
  • For schroeder: Yes, KeePass auto-type (Google its functionality) entered the U/P but of course it didn't work because it was the wrong site. – AntiNoise Mar 2 at 11:04
  • 1
    On a side note, you could use the KeePassXC-Browser addon (for your browser) paired with either KeePassXC or with KeePass2 + KeePassNatMsg plugin. That will add browser autofill for all sites that match the url listed in your password entries. It works really well as anti-phishing as well, since the autofill won't happen on sites that have similar but distinct domains. – Stephen Schrauger Mar 2 at 15:17
  • 1
    businessinsider.com/… is this what you mean? – Clumsy cat Mar 2 at 15:42

They could be, phishing sites are set up to do exactly this.

On non-malicious sites, this would be generally be considered poor practice, but there is no reason why they couldn't, beyond user privacy regulations.

| improve this answer | |
  • 13
    GDPR, as far as I know, forbids it. Then again, not everyone is subject to GDPR (or abides by it). – MechMK1 Mar 2 at 6:54
  • To be clear, this was in no way a phishing site, it just has a KeePass entry that appears similar to the site I intended to launch. Both are related to rent and utility payments but one is for viewing only (the site I mistakenly launched, then ran the actual payment site logon in its fields). I'm renaming one of the entries to reduce the chance of this happening again. – AntiNoise Mar 2 at 11:12
  • 3
    @AntiNoise This is an inherent danger if you have to manually select the password to paste, rather than the browser doing it automatically. – Barmar Mar 2 at 17:08
  • 2
    @MechMK1, what section of GDPR would forbid this? – Tangurena Mar 2 at 21:24
  • @Tangurena Username and password could be considered Personal information, and it'd be difficult to argue you're storing people's passwords in plaintext for legitimate reasons. However, I'm not a lawyer, so I don't know for sure. Hence why I said "as far as I know" – MechMK1 Mar 3 at 7:54

I think the general answer here is that passwords are not normally logged by any legitimate service. Usernames certainly are.

To record passwords is a problem, even for the "correct" site. Services should not know what your passwords are, which is why there are some complicated processes used to store passwords. I have seen some very poorly designed systems where passwords are recorded, but this is an error/incompetence in design.

Malicious websites, on the other hand, do record your username and passwords, because they want to know them and abuse them.

| improve this answer | |
  • 3
    To be noted that if you incorrectly enter the password in the username field, then that will be logged. So I'd say "contents of password fields" instead of "passwords", since the application cannot know that xunh'%3nbs is your password instead of your username. – Giacomo Alzetta Mar 2 at 12:16
  • You need to store passwords in the clear so you can send them to dumb users who forget them. While that's bad for some sites, I won't armwave that it's bad for all sites. Not every site needs Fort Knox security. Security at the expense of usability comes at the expense of security. – Harper - Reinstate Monica Mar 2 at 18:34
  • 1
    @Harper-ReinstateMonica and you're saying that the safer options for password management when users forget their password are not as usable? – schroeder Mar 2 at 20:11
  • @schroeder depending on the site and its demographic, sometimes, it's right. Mind you I didn't say safer. – Harper - Reinstate Monica Mar 2 at 20:13
  • 1
    @Harper-ReinstateMonica taking on that liability is not "arm-wavy". I think there is a compromise that will not cause problems for all parties involved – schroeder Mar 2 at 20:14

A legitimate website will rather not do that.

Then again, there are possibilities:

  1. The site being compromised
  2. The site being run by incompetent people (never underestimate...), collecting the data and get compromised in some future point.
  3. The site collecting some data of failed logins in order to analyse and prevent brute-force or similar attacks. "Some data" probably includes login names and may or may not include passwords, parts of the passwords or hashes of the passwords and the hash may or may not be strong.
| improve this answer | |

This would likely be recorded as an error on the website as it would return permission denied. Many websites go through some kind of firewall or protection which might pick up failed attempted to try and block brute force log-in attempts or similar.

I would be pretty shocked to find that a (none compromised) website is storing passwords of failed log-in attempts, or any un-hashed/plaintext passwords at all.

| improve this answer | |
  • 1
    On the contrary, I would be shocked if a sited did not store the passwords of failed logins. If only for a few days for statistical purposes. – Chenmunka Mar 2 at 18:29
  • @Chenmunka, those logs would be filled with otherwise valid passwords with one character mistyped. That's a huge leak risk. – ilkkachu Mar 2 at 20:09
  • @ilkkachu And/or filled with valid passwords for that same user, but for a different site. This would absolutely be a horrible risk for both the site in question and all of it's users individually. I cannot imagine a usecase for that log data that would come anywhere close to balancing that risk. – Iron Gremlin Mar 2 at 21:46
  • @Chenmunka As ikkachu and Iron gremlin have stated, this is a Bad Idea™ – Kevin Mar 2 at 22:11

Ignoring deliberately malicious websites, it can happen by accident or neglect. I refer you to Twitter: https://www.theverge.com/2018/5/3/17316684/twitter-password-bug-security-flaw-exposed-change-now

May 3, 2018

According to Twitter, the bug occurred due to an issue in the hashing process that masks passwords by replacing them with a random string of characters that get stored on Twitter’s system. But due to an error with the system, apparently passwords were being saved in plain text to an internal log, instead of masking them with the hashing process. Twitter claims to have found the bug on its own and removed the passwords. It’s working to make sure that similar issues don’t come up again.

| improve this answer | |

In a previous job we logged failed credentials to a radius server used to authenticate internet connections. This was handy, we could reset customer's password to whatever their router was sending, or could see if the creds were from another ISP by the username.

My point is, there are times when logging failures is useful ("grandma you got caps-lock on again") However this was a decade ago, rules and regulations have moved on.

You are using a different password per service anyway right? So go to that one site, and change that one password that you think might have leaked. If its your default password for everything, then you have a lot more work to do.

| improve this answer | |

They should not, but good security practice would be to consider the password used as compromised and change it.

After all, if you lose a set of keys for your home, wouldn't make you less worried to replace the locks?

| improve this answer | |

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