This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

CRV2 AuthControls

From OWASP
Revision as of 11:57, 7 September 2014 by Gary David Robinson (talk | contribs) (Created page with "Overview Authentication is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Overview

Authentication is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.

Description

Authentication is important as it is the gateway to the functionality you are wishing to protect. Once a user is authenticated their requests will be authorized to perform some level of interaction with your application that non-authenticated users will be barred from. You cannot control how users manage their authenticate information or tokens, but you can ensure there is now way to perform application functions without proper authentication occurring.

There are many forms of authentication with passwords being the most common. Other forms include client certificates, biometrics, one time passwords over SMS or special devices, or authentication frameworks such as Open Authorization (OAUTH) or Single Sign On (SSO).

Authentication is just as important within a companies firewall as outside it. Attackers should not be able to run free on a companies internal applications simply because they found a way in through a firewall. Also separation of privilege (or duties) means someone working in accounts should not be able to modify code in a repository, or application managers should not be able to edit the payroll spreadsheets.


What to Review

When reviewing code modules which perform authentication functions, some common issues to look out for include:

  • Make sure your usernames/userids are case insensitive. Many sites use email addresses for usernames and email addresses are already case insensitive. Regardless, it would be very strange for user 'smith' and user 'Smith' to be different users. Could result in serious confusion.
  • Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess. Minimum length of the passwords should be enforced by the application. Passwords shorter than 10 characters are considered to be weak ([1]). Passphrases should be encouraged. For more on password lengths see the OWASP Authentication Cheat Sheet.
  • Password complexity should be enforced by making users choose password strings that include various types of characters (e.g. upper- and lower-case letters, numbers, punctuation, etc). Ideally, the application would indicate to the user as they type in their new password how much of the complexity policy their new password meets. For more on password complexity see the OWASP Authentication Cheat Sheet.
  • It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see Forgot Password Cheat Sheet for details on this feature.
  • It is critical for a application to store a password using the right cryptographic technique. Please see Password Storage Cheat Sheet for details on this feature.
  • For high risk functions, e.g. banking transactions, user profile updates, etc, utilize multi-factor authentication (MFA). MFA is using more than one authentication factor to logon or process a transaction:

Something you know (account details or passwords) Something you have (tokens or mobile phones) Something you are (biometrics)

  • If the client machine is in a controlled environment utilize SSL Client Authentication, also known as two-way SSL authentication, which consists of both browser and server sending their respective SSL certificates during the TLS handshake process. This provides stronger authentication as the server administrator can create and issue client certificates, allowing the server to only trust login requests from machines that have this client SSL certificate installed. Secure transmission of the client certificate is important.


Languages


References

https://www.owasp.org/index.php/Authentication_Cheat_Sheet http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication