Many times we need to have a way for users to authenticate with a system and that is usually done with a username/password combination. A lot of times we have to build our own or use some pre built system (i.e. Forms Authentication).

Now I am not a fan of passwords. I find that they are usually easy to guess and brute forcing them has become faster and faster. Passwords are dying and there are other options but they will differ from implementation to implementation.

If you have to build a password based authentication system then there are some minimum requirements that I feel are required:

Require Complex Passwords
Complex passwords drastically increase the difficulty of breaking a system. Allowing users to put in dictionary words means that it can be broken into in minutes with a dictionary brute force tool. Be careful of your rules though. Having password requirements that result in passwords too complex to remember means more people will write it down.

Store Passwords Properly
So many people store passwords in plain text. Use a hashing algorithm with a good random salt (for more info see my post on hashing for passwords) . Better yet use an iterative hash that will hash your hash multiple times that makes it take a huge amount of time to crack.

Ensure That Data Is Encrypted In Transit
There are many many sites that have a login page unprotected by SSL/TLS. If the credentials are transmitted in plain text to the server then it is easy to sniff the data off the wire. SSL certs are cheap and a quick way to protect data in transit!

Also be careful what happens with the data once it arrives at the server. Does it go across the wire in your network to the database server? Is that connection encrypted?

Password Change Policy
Passwords are getting easier to crack and if you have all the time in the world it becomes much easier. Brute forcing a password over the web may take months (or it may take minutes) but forcing users to change their password every X number of days helps prevent this.

Record and Monitor Failed Login Attempts
Most people don’t log failed logins and even those that do rarely look at the log of failed attempts. If you don’t know that people are trying to break into your system then how can you hope to prevent them from succeeding? If you see someone trying to brute force in you can respond by blocking their IP address and prevent any other attacks they may try.

Don’t Let People Try To Break In Forever
If a user fails to login successfully for X times in a set period something should prevent them or slow them down from trying again.

Account lockout is one way to do this but an attacker could intentionally lock out an account and deny service to a legitimate user that way! Also the lockouts need to be cleared by an administrator which could take time to contact that person and have them clear the flag. Also if an attacker goes after the admin account this could cause a lockout of the only person that can clear the flag! This is why in Windows the Administrator account has no lockout policy. This is a crappy scenario as the one account you REALLY want to crack has no lockout while the crappy accounts with fewer privileges do have a lockout policy.

A better technique in my opinion is tar pitting. Tar pitting is a technique of slowing attempts down. So if someone fails to login more than 3 times we may delay processing another login request for 10-15 seconds. If they keep failing we may increase that timeout. We would not want to algorithmically grow the timeout though (i.e. for each failed login add a 2 second delay). If we did then an attacker may fail logins on purpose so that a legitimate user would have to wait 26 days until they could login (which would also hold server resources for that period too which could lead to a much broader denial of service attack).

Ensure The Password Reset Mechanism Is Secure
One area that is exploited more and more is the password reset ability. The systems where it asks you to answer 2-3 personal questions are fairly easy to attack if you know something about the victim. For example Sarah Palin’s account was hijacked because the personal questions she chose were all over the media (i.e. Where did you go to high school? What was your Mothers maiden name? What is your favourite book?). These “personal” questions are also fairly easy to retrieve via social engineering as people don’t feel that their favourite book is something they should consider sensitive information.

I personally like how ING bank does PIN resets. I need to provide personal information like a SIN plus the amount of my last transfer/deposit to my account. Once I reset my pin I get both an email and a physical letter mailed to me notifying that my PIN has been changed. It is really important to pick a methodology of password resets that use information an attacker could not guess or easily learn.

Conclusion
Those are my BASICS for a login system. It will take a lot of time and resources to build a system that does all of this and that is why I like either leveraging windows authentication or other technologies (like certificates, cardspace, smart cards, passkey devices). It is really not an easy task to build something like this. The authentication used in Windows has been developed and evolved by countless developers over the years and they have though about this kind of stuff way more than we would ever want to.

There is also a great chapter on password systems in the book 19 Deadly Sins Of Software Security that goes into much greater depth (yes there is way more on this subject) then I have.