You should log all successful user authentication

August 27, 2012

Here's something that I've recently had my nose smacked with:

Every place where users can authenticate over the network to your systems should log successful authentications, including the source IP address.

Every place. No exceptions. And all of the pieces (minimally user name, remote IP, and time) should be logged explicitly in one place; you should not have to piece together this information by inference from a collection of different logs, because sooner or later you will go mad from having to do this. You should do this logging even in systems that do not directly authenticate the user but delegate it to another system and then just use the authentication result.

(For example, suppose that you have a webmail system that is actually a frontend on your IMAP server and so relies on the IMAP server for authentication and mail access. The webmail system should still log all successful authentications, partly because your IMAP server logs are likely to report the source of all of the connections as being from the webmail system instead of the user's actual remote IP address.)

It's hopefully obvious why you need this everywhere, on every service (no matter how insignificant). Partly this is because if you ever have an attacker exploiting a compromised account, you'll want to know everything the attacker did. Partly this is because you can never entirely predict what service an attacker is going to find interesting and then (ab)use. Partly this is because it's easier to make sure that something important doesn't slip through the cracks if you have a policy with no exceptions; otherwise, it's all too easy to deploy something without this logging on the grounds that you need the service now and you'll put the logging in later. (Remember, later never comes.)

Logging failed authentications for existing users is optional (my personal feelings on this are heretical, so I will skip them for now). For hopefully obvious reasons, you should omit the login name if you log failed authentications for nonexistent users.

(This is likely something that experienced large-scale sysadmins know automatically and is part of best practices and so on. Sometimes I'm slow, and it's always tempting to say 'ehh, we're too small and it doesn't really matter for this service because ...' or, for that matter, just not think about the issue when you're deploying a service. Security compromises are low-probability events for most places and most services, and security in general is an overhead.)

Comments on this page:

From at 2012-08-27 19:27:19:

I would gratefully welcome an entry that expands on all the obviousness in this one. (I am merely a developer; sysadmin thinking does not come naturally.)

Aristotle Pagaltzis

By cks at 2012-08-27 23:20:42:

I was all set to write an entry about this but then it turned out that I already had: LoggingUsernamesMistake.

The short version is that if you log unknown usernames, you will inevitably sooner or later wind up logging someone's password (in plain text). They may or may not realize this, and there may or may not be an immediately following real login that gets logged so that an attacker who peruses the logs can conveniently work out who the password belongs to.

From at 2012-08-30 21:15:23:

And the reasons why you want login logging everywhere – they are what follows in that paragraph? Or is there more?

Aristotle Pagaltzis

By cks at 2012-08-31 01:27:28:

I think so (at least I can't think of anything else, more or less). Every authentication point you have is presumably protecting something or giving non-default access to something, so every such point is a place where an attacker may look at something interesting and you'll want to know about it.

(This goes double for authentication points which allow the attacker to do something active, like sending email. But even knowing what an attacker looked at or didn't bother with is useful and reassuring.)

From at 2012-08-31 11:06:01:

Thank you. Bookmarked for later reference.

Aristotle Pagaltzis

By cks at 2012-09-07 15:55:48:

Belatedly: I realized (post-facto) that I misread your first comment as less general than it was and so only answered the question I thought you were asking instead of the bigger one that you actually were. If there's still inobvious things, leave another comment and I'll write more (I can always use more entry seeds).

From at 2012-09-09 04:17:32:

I think you’ve covered them, esp. with the recent entries expanding on issues you didn’t even hint at here, thanks. At least I can’t think of immediate open questions now. If I do I’ll ask.

Aristotle Pagaltzis

Written on 27 August 2012.
« Some brief information about a local spam incident
When Exim generates bounce messages »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Aug 27 00:53:07 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.