10 things you can do as a developer to make your app secure: #5 Authentication Controls
This is part #5 of a series of posts on the OWASP Top 10 Proactive Development Controls:
In the previous post, we covered how important it is to think about Access Control and Authorization early in design, and common mistakes to avoid in implementing access controls. Now, on to Authentication, which is about proving the identity of a user, and then managing and protecting the user’s identity as they use the system.
Don’t try to build this all yourself
Building your own bullet-proof authentication and session management scheme is not easy. There are lots of places to make mistakes, which is why “Broken Authentication and Session Management” is #2 on the OWASP Top 10 list of serious application security problems. If your application framework doesn’t take care of this properly for you, then look at a library like Apache Shiro or OWASP’s ESAPI which provide functions for authentication and secure session management.
Users and Passwords
One of the most common authentication methods is to request the user to enter an id and password. Like other fundamentals in application security this is simple in concept, but there are still places where you can make mistakes which the bad guys can and will take advantage of.
First, carefully consider rules for user-ids and passwords, including password length and complexity.
If you are using an email address as the user–id, be careful to keep this safe: bad guys may be interested in harvesting email addresses for other purposes.
OWASP’s ESAPI has methods to generateStrongPassword and verifyPaqsswordStrength which appliy a set of checks that you could use to come up with secure passwords. Commonly-followed rules for password complexity are proving to be less useful in protecting a user’s identity than letting users take advantage of a password manager or entering long password strings. A long password phrase or random data from a password manager is much harder to crack than something like
Password1!
which is likely to pass most application password strength checks.
Password recovery is another important function that you need to be careful with – otherwise attackers can easily and quickly steal user information and hijack a user’s identity. OWASP’s Forgot Password Cheat Sheet can help you design a secure recovery function, covering things like choosing and using good User Security Questions, properly verifying the answer to these questions, and using a side channel to send a reset password token.
Storing passwords securely is another critically important step. It’s not enough just to salt and hash passwords any more. OWASP’s Password Storage Cheat Sheet explains what you need to do and what algorithms to use.
Session Management
Once you establish a user’s identity, you need to associate it with a unique session id to all of the actions that a user performs after they log-in. The user’s session id has to be carefully managed and protected: attackers can impersonate the user by guessing or stealing the session id. OWASP’s Session Management Cheat Sheet explains how to properly set up a session, how to manage the different stages in a session id life cycle, and common attacks and defences on session management.
For more information on Authentication and how to do it right, go to OWASP’s Authentication Cheat Sheet.
We’re half way through the list. On to #6: Protecting Data and Privacy.
| Reference: | 10 things you can do as a developer to make your app secure: #5 Authentication Controls from our JCG partner Jim Bird at the Building Real Software blog. |
