Linux - Log What Username and Password Was Tried

Question

I am using Ubuntu Server and I am curious if there is anyway to log what username and password a potential attacker has tried.

I can grep /var/log/auth.log and see all the failed attempts but I would like to see what username and passwords they are trying.

Solution 1

You can visualise the failed user names after you turn up the verbosity of the log in sshd_config¹, but there is no way to see the failed passwords as this could be a potential security issue and would violates the privacy of users (for example you could mistype your password and it would be leaked into some log file).

All the passwords are handled as extremely sensitive data and only stored in memory and never written to a log so they will not be able to leak out of their security context.

To do this, you should use some specially crafted honey-pot custom-made for this use case, not standard production security products.

¹ See man sshd_config for more information

Solution 2

The reason this is NOT done is easily revealed by looking at what can happen on a site where it IS done.

I was once required to improve the password hash strength of a site which logged bad passwords (for what possible reason they did this, I cannot imagine). To minimize user inconvenience, I first had it auto-convert users as they logged in, but since those who hadn't logged in for some time also needed the improved protection, I tried cracking them, converting all guessed passwords to the higher hashing standard.

After a week of trying everything I knew, known-password lists from large leaks like facebook and so dictionaries of many languages, permutations and so forth, I was left with about 4,000 passwords of people who had not logged in, and which I could not crack.

I took the bad password log for the past several years, used those passwords against the uncrackable passwords, and cracked a quarter of the remainder. That is, it guessed quarter of the really hard passwords in the system, including multiple admin accounts, and meaning that I only needed to reset the passwords of 3,000 users, rather than 4,000.

So I think that the value of such a log, to a malicious attacker, cannot be overstated.

There is simply no good, valid reason to log failed passwords, and every reason to avoid doing so - if that data leaks, you have revealed login info for a large swathe of your users. Those "bad passwords" will be passwords they have changed back to, or which they user on other accounts on your system, or which they use on some other system (their bank, their email...)

By keeping such a log, you are endangering your users for no real advantage in security.

Comments

[Paul Draper]

Yikes. That's a great way to get passwords for other apps. When my login for paulddraper fails, try that password for [email protected].

[wchargin]

This is probably a really bad idea. If I try correct horse batetry staple, what do you think the password is? What if I get it wrong twice in a row—first I write ,Y{56wK!bv and then I write Y,{56wK!vb before getting the correct password? In this case, you can easily see that the correct password is highly likely to be one of two possibilities.

[David Richerby]

This is a really, really, really bad idea. Even logging the username is a bad idea, since it's quite common for people to accidentally enter the password in the username box, either because they didn't expect to have to enter their username or their fingers got out of synch with their brains.

[Wildcard]

:/^To do this/s/should\(.*\).$/would have to\1 because it's a really really really bad idea./

[David Richerby]

Even logging the usernames is a bad idea. People often accidentally type their password in the username field (e.g., because they got their password wrong and were expecting to just have to enter the password again but the user interface blanked the username, too).

[underscore_d]

Paragraph 4 is a very interesting statistic! Agree with the emphasis on not logging failed passwords because (A) it's basic security/privacy and (B) you could be compromising users' security on other accounts they use (and ideally coders aren't so selfish that they don't care about that.)

[Dewi Morgan]

The 1/4 stat is likely VERY lowballing: usernames and passwords were provided to the system by software from data stored during registration, so entire classes of password failure were impossible. No accidental typing the password in the username field, no caps lock held down, no accidental typos, etc. Really the only way you could log in incorrectly is if you had two computers, updated one, then logged in from the other with an outdated config file. It was a "should never happen from one install" scenario, which I guess is why they thought it OK to log.

[underscore_d]

Thanks for more interesting info! Realised I forgot to upvote this before, somehow, so there it is.

[Dewi Morgan]

Just thought about it more, and those numbers made no sense. Quarter of the people with the best passwords logged in with an old config file sometime and then changed back to that password? Nah. Then I remembered a setting to not store passwords locally, and instead prompt every time you logged in. I thought nobody used it, but makes sense that the hardest passwords would belong to those who cared enough to check that box. Hence the high number of admin accounts, etc. I could also see this techie elite having multiple accounts, and trying all their passwords when they forget one.