Before you attempt to make a record of incorrect username
and password pairs, take a few moments to think through the
security implications. When an actual user provides incorrect
login information, chances are good that it was just a small
typo; the information provided is *almost* correct. Thus, a
log of the failed attempts is almost as good as a complete
copy of your credentials database; given the log, a cracker
could break into the accounts in just about no time at all.
Do you *really* want to maintain such a risky log? Do you
*really* want a third party to maintain it for you "for free?"
One error I myself make with embarrassing frequency is
to get "out of phase" with the prompts, entering my password
instead of my account name and vice versa. So, even a log
that records only the failed usernames but not the failed
passwords is not safe; a cracker observing that jwilson and
esosman and B##a29a^ and philton had all failed to log in
would have a pretty good idea about a possible password to
try against all the usernames on your system ...
What about logging every attempt, but log only the username if the
username resembles an existing username; log only the password if the
username doesn't, but the password does; accept logins where the
password/username pair is reversed but otherwise valid; and if a login
attempt has neither the username nor the password resemble anything on
the system, log the username if it "looks like English", the password
if the username doesn't but the password does, or just the fact of a
failed login attempt with no additional details save the originating
IP otherwise. (This catches login attempts with username guessing such
as fredp, admin, root, or whatever. Look for dictionary words, common
abbreviations like admin, and common first names as prefixes, and
common last name beginnings like logan as suffixes. If this ever
actually matches a password it was a weak password anyway.)
You can also encrypt the log. The encryption code must be on the auth
server, but it only needs to contain your public key. You keep your
private key on a smartcard, PDA, laptop, heavily firewalled PC, or
whatnot and copy the log to a heavily firewalled machine to decrypt
and examine it from time to time. Nobody can get at the log contents
without first compromising your private key somehow. Compromising the
auth server doesn't get them anywhere since reversing the encryption
or discovering the private key with just the public key is NP-hard.
Note that each log entry obviously needs to be separately encrypted
with this scheme, as the auth server mustn't have the private key and
therefore cannot decrypt, append, and reencrypt.
