Logging authentication attempts including passwords

Question

I'm writing a comprehensive authentication system for an application and I was planning on logging failed authentication attempts in order to implement better security. I would like to check failed passwords for both brute force and dictionary attacks, however the only method I could think of doing this is by storing the raw password.

I have mixed feelings about doing this. Although I know that the failed login attempts will be cleared every so often I don't like the idea of raw passwords being stored in a database. I know I mistype passwords very often which are very similar to my real password, or worse yet I'll type a wrong password for a particular login that is actually an active password for another website I belong to.

It would however be impossible to implement advanced security without storing some raw passwords, so I'm trying to think about the best way to do it.

Here are some possible solutions I have thought of:

• Don't store more then 24 hours of login attempts. This isn't really a solution, more of simply limiting the damage if the passwords are compromised.
• Clear a users failed attempts if they are successfully authenticated.

Anyone have any input on this? Is this a good/bad idea? Should I use two-way encryption?

Answer 1

there's a big difference between a user making mistakes and a brute force / dictionary attack: the volume of requests. Don't store failed attempts - you're quite right that the plaintext password should be handled minimally - just look at the pattern of attempts. That should be enough data.

anything else, and your 'advanced security' starts looking like 'advanced attack vector possibilities'.

Answer 2

Logging raw passwords seems like a really bad idea, as you pointed out yourself.

Could you just log the username, and the times of failed logins, without actually logging the passwords? It would be fairly obvious if there was a bruteforce attack if there were hundreds of log-in attempts within a short space of time. You can also log the IP address.

Answer 3

Depending on the authentication protocol you select, e.g., in the case of Kerberos, you may not even have access to the password entered.

Answer 4

I'm not sure what you mean when you mention storing raw passwords- presumably you only want to store the failed password attempts in plain text to analyze for patterns (dictionary attacks) and volume (brute force).

In my limited experience, you would take the user's inputted password, hash it (with a salt, the same salt used to hash the stored password) and compare with the stored hashed value. If the validation fails (the hashed values are not equal), log the plain text version of the password used for the attempt.

I would advise also implementing locking out of an account after a certain number of failed attempts and possibly having an exponential timeout window for when a login attempt can be tried again. If a user enters a password incorrectly to begin, but then enters a password correctly, you might consider deleting the password captured for the failed login for this particular session.

Answer 5

This seems like over-engineering. I would just keep track of failed login attempts & after $x amount of failed login attempts, you then block the IP from attempting another login for 1-24hrs or so.

If you're concerned someone is targeting a specific account you can note the number of failed attempts on a specific username & then take appropriate measures, such as limiting failed logins on that username to 2 or 3 per 24hr period on any ip address.

I can think of ways you could try to detect dictionary/brute attacks via comparison, but you're going to have to collect user input and compare it to previous attempts, this could be a security problem if you're storing slightly misspelled legitimate passwords in a database. Plus this is going to take up quite a bit of CPU power to churn through for every login.

The goal should be to make it intensively slow for brute-force attackers, but not annoying or compromising for legitimate users.

Though now that I am thinking on this a bit more, the prevention method could also be a way of denial-of-service by locking users out of being able to login, so take my suggestion with that in mind.

Answer 6

Have you thought of a set amount of login's then a timed block? If login fails 3x/5x/10x if you want, then lock the account completely for a specified period of time.

By doing this you make it so painstaking for a brute-forcer to use, that they probably just won't bother trying. Logging every failed attempt, and more so even the thought of plain text passwords is a bad idea. Rather use the following analogy:

"If I make my house so difficult to get into, they'll try the neighbours first."

Make life difficult for the brute forcers and they won't bother.

Another option is after a set amount of failed logins, add a captcha. This again, if the captcha is good, hinders their progress dramatically.

HTH,

Kyle

Answer 7

As others have said, Logging passwords is a bad idea.

A much better idea is to throttle login attempts.

If done properly, throttling can greatly decrease the risk of password attacks as well as limiting denial of service attacks.

Answer 8

You could store hashes of failed passwords, if you really want to retain any information about them. It wouldn't allow you tomanually analyze patterns but would allow comparing failed attempts with each other.

That said, I do not think analyzing passwords would yield any useful information.

Answer 9

As others have pointed out, it's a very bad idea to store plaintext passwords and throttling/limiting login attempts is the right way to go.

If you are concerned about the security of passwords, then you should implement password policies when passwords are created, not at the time of authentication. You can then check in memory for dictionary words and have typical policies such as minimum length, must contain a number, a capital letter, etc.

Of course, password policies can be annoying to users, but they can, theoretically, ameliorate your concerns about weak passwords.

The ugly truth is that passwords are a poor way to prove identity, but the alternatives are more expensive and cumbersome.