Authentication - Security Best Practices

Authentication modules are the most exploited pieces in a web application. We look at ten good practices that ensure your authentication system is safe against an attack.

1. Use an external authentication service provider like LDAP if it fits into your architecture. It’s simpler to reuse a tried and tested authentication system than writing your own from scratch.

2. Use SSL to transmit all sensitive authentication information from the browser to the web server. The ‘Login’page, the ‘Change Password’ page and the ‘Forgot Password’ page all sent authentication details and must be SSL enabled. The session id token is a short-lived password with the lifetime of a session, and should also be sent over SSL. Marking the session id cookie with the “secure” attribute ensures that it is sent only on SSL enabled requests.

3. Validate all user inputs, and be doubly careful with login inputs. Define acceptable inputs including their lengths (eg. Usernames are alphanumeric and less than 16 characters). Reject everything that does not fit that rule. Attacks like SQL Injection have devastating effects and are difficult to prevent unless you follow a strict policy and accept only what is allowed.

4. Use a salted hash technique for transmitting passwords, even when you’re using SSL. This ensures two things: one, you’re not vulnerable to a replay attack and two, passwords cannot be stolen from the submit cache of the browser.

5. If your application manages credential storage, ensure that only the 1-way hashes of passwords are stored in the database, and that the table/file that stores the passwords and keys are “write”-able only to the application.

6. Separate the authentication page from the next-page-after-login, and use redirection during login to reach the next page. It is possible to steal passwords if such redirection is not used.

7. Use the session management framework provided by the server to manage your sessions, instead of writing one your own. Session tokens should be strongly random, and expired after a defined period of inactivity. It’s better to re-authenticate the user if there’s a period of inactivity than set long expiry windows.

8. Design your “Forgot Password” feature to send a mail to the authorized email id with a short-lived link that lets the user reset the password. Choose your hint questions so that their answers are not limited in their range (“favorite color” has just a few choices!). Better still, allow the user to have their custom hint question.

9. The “Remember Password” feature is convenient, but very unsafe. Avoid it as far as possible. But if the business requires that feature, do not store the password itself in the cookie, as cookies are stored unencrypted on the client. And remember to use a token that is set to a new value after every login. If that token has a very long lifetime, it soon becomes equivalent to the password. And warn users not to use it from shared computers.

10. Log all authentication failures in detail, including the IP address and the exact HTTP request that triggered it. This aids forensic analysis in case your application is compromised.