28

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.

AntiNoise
  • 361
  • 3
  • 5
  • I don't understand the situation. What do you mean by "attempted"? Did you enter anything? – schroeder Mar 02 '20 at 07: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 02 '20 at 08: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 02 '20 at 11:04
  • 1
    On a side note, you could use the [KeePassXC-Browser addon](https://github.com/keepassxreboot/keepassxc-browser) (for your browser) paired with either KeePassXC or with KeePass2 + [KeePassNatMsg](https://github.com/smorks/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 02 '20 at 15:17
  • 1
    https://www.businessinsider.com/henry-blodget-okay-but-youve-got-to-admit-the-way-mark-zuckerberg-hacked-into-those-email-accounts-was-pretty-darn-cool-2010-3?utm_source=reddit.com&r=US&IR=T is this what you mean? – Clumsy cat Mar 02 '20 at 15:42
  • When you say recording logons, do you mean the username/password combination or a log that someone tried to login to x username at y time from z ip address? – Kyle Wardle Mar 02 '20 at 15:49
  • Password managers that make it easy to use username/password for the wrong website should be banned... That's just voiding one of the key benefits of password managers... – stefan Mar 02 '20 at 16:19
  • if you intend to address a specific commenter, prefix their handle with an "@" - they will then be notified of your reply. – GalacticCowboy Mar 02 '20 at 16:41
  • I have seen low cost sites developed by low grade devs do things like log passwords in plaintext. You would be surprised how widespread this kind of failure is. – Frank Mar 02 '20 at 22:31
  • I know that Active Directory does. Meaning a website that authenticates against one will log your password! – Anemoia Mar 03 '20 at 01:03
  • @Luc this should be an answer, because it's the best advice – George M Reinstate Monica Mar 03 '20 at 02:31

7 Answers7

52

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
jdow
  • 1,321
  • 2
  • 7
  • 6
  • 13
    GDPR, as far as I know, forbids it. Then again, not everyone is subject to GDPR (or abides by it). –  Mar 02 '20 at 06: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 02 '20 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 02 '20 at 17:08
  • 2
    @MechMK1, what section of GDPR would forbid this? – Tangurena Mar 02 '20 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" –  Mar 03 '20 at 07:54
29

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 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 02 '20 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 02 '20 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 02 '20 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 02 '20 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 02 '20 at 20:14
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/105132/discussion-between-harper-reinstate-monica-and-kevin). – Harper - Reinstate Monica Mar 03 '20 at 16:29
6

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.
fraxinus
  • 3,425
  • 5
  • 20
1

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.

JakeInTheMiddle
  • 11
  • 3
  • 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 02 '20 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 02 '20 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 02 '20 at 21:46
  • @Chenmunka As ikkachu and Iron gremlin have stated, this is a Bad Idea™ – Kevin Mar 02 '20 at 22:11
0

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.

Hand-E-Food
  • 109
  • 1
0

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.

Criggie
  • 508
  • 3
  • 12
0

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?

KuttKatrea
  • 9
  • 1