4

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.

  • 2
    Yikes. That's a great way to get passwords for other apps. When my login for paulddraper fails, try that password for paulddraper@gmail.com. – Paul Draper Oct 11 '15 at 2:42
  • 1
    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. – wchargin Oct 11 '15 at 5:41
  • 5
    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. – David Richerby Oct 11 '15 at 8:20
18

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

  • 2
    :/^To do this/s/should\(.*\).$/would have to\1 because it's a really really really bad idea./ – Wildcard Oct 11 '15 at 6:11
  • 3
    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). – David Richerby Oct 11 '15 at 8:22
4

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.

  • 1
    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.) – underscore_d Oct 11 '15 at 12:27
  • 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. – Dewi Morgan Dec 31 '15 at 14:09
  • Thanks for more interesting info! Realised I forgot to upvote this before, somehow, so there it is. – underscore_d Dec 31 '15 at 14:20
  • 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. – Dewi Morgan Dec 31 '15 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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