Pushing Left, Like a Boss — Part 5.12 — Authentication (AuthN), Identity and Access Control

Note: much of this comes from the OWASP Cheat Sheet on Access Control, by Shruti Kulkarni, Adinath Raveendra Raj, Mennouchi Islam Azeddine and Jim Manico. And if not, it may come from one of the other offerings from the amazing OWASP Cheat Sheets Project. For more information on almost any AppSec topic, check out the project, it’s definitely worth your time!

B-Sides Vancouver, 2019

Let’s start with some definitions.

Authentication is ensuring that the user who is using the application is the actual person they purport to be. For instance, when I log into my webmail, it verifies that I am the one-and-only Tanya Janca that owns this account. Not a different person who is also named “Tanya Janca”, and not someone pretending to be me. The real, authentic, me; the person who owns the account.

Identity (digitally speaking) is a hardware or software-based solution for proof of identity of citizens, users or organizations. For example; in order to access benefits or services provided by government authorities, banks or other companies in person, you must verify your identity, usually with a driver’s license, passport or another physical document. However, if you are verifying your identity digitally (electronically), you must use a software or hardware based solution to prove your identity.

Access Control is allowing (or not) users to access systems, features, data, etc. based on the permissions that the system has assigned to that user. For instance, perhaps you have access to the main parts of your building, but there is an electrical room to which you do not have access. Your badge will not get you it. This is access control, and it works the same way with software, granting or restricting access based on your role and/or identity within the system.

As usual, I recommend using the features as provided in your programming framework for AuthN, Identity and Access Management features. I also suggest strenuous testing of your implementation, because if someone breaks these security controls there shall be dire consequences.

General Rules of Authentication (AuthN)

• Applications that use password-based authentication should follow the standards put forth in my book, Alice and Bob Learn Application Security and/or the current NIST Password Standard. Ex: do not forces users to change their passwords often, allow very long passwords, do not force complexity, allow and encourage the use of password managers, etc.
• The principle of least privilege is the practice of limiting access to the minimal level that will allow normal functioning. This principle should be applied not only to the users of web applications, but to the applications themselves, and as they are given access to databases, web services and other resources. For example, it is rare that an application requires a database user that is the database owner (DBO); generally, read/write or CRUD is enough.
• Passwords will be salted and hashed (one-way), not encrypted (two-way), before storing. Use a strong hashing algorithm (again, refer to my book, Alice and Bob Learn Application Security or NIST if you are unsure).
• Passwords will be encrypted in transit (HTTPS only).
• Re-authentication will be performed for “Sensitive Features”. Sensitive features could include, but are not limited to; changing passwords or security questions, changing bank account information, deleting a user account, transferring large sums of money.
• Measures must be taken to prevent or circumvent brute force attacks. Measures could be a maximum number of login attempts, requiring a captcha after 5 failed logins attempts or throttling (slowing down) the system to make a brute force attack more difficult.
• Passwords must be masked (not echoed to the screen) while the user enters the password.
• Validate that a user is authorized to access every new page and for every action. Ensure that this is applied using a pre-approved list of approved users, not a block list of unapproved users. See blog post Pushing Left 5.1 for more information on input validation and approved lists..
• Never assume that “hiding” a page or feature means that it is protected or ‘safe’, that is not enough.
• Login fails and errors should be logged. Ensure not to log sensitive information such as the text used for the attempted password, as it is likely only one or two characters off from the real password. Refer to blog post Pushing Left 5.9 for more information on what to log.
• Brute force attempts (defined as 10 or more successive failed attempts to login in under 1 minute, or 100 or more failed attempts in one 24-hour period) must also be logged. If possible, the IP address of said attacker should be blocked, and account owner notified.

I realize that this list is not exhaustive, as this is a huge topic that could easily fill an entire book. I invite you, my readers, to provide more thoughts, topics and ideas in the comments section below. Thank you for reading.

Up next in the ‘Pushing Left, Like a Boss’ series: HTTPS only.