Broken Authentication is the first defense for most web applications. If the attacker cannot log in as a user, there is often little attack surface accessible. On the flip side, once an attacker can log in as a legitimate user, all bets are off. It is important to understand what vulnerabilities exist regarding broken authentication.
Vulnerabilities related to authentication can include:
- Plaintext passwords in transit
- Plaintext passwords at rest
- Weak passwords
- Single-factor authentication
- Password guessing
- Man-in-the-browser attack
- Session hijacking
The following sections explore each of these vulnerabilities.
Plaintext Passwords in Transit
If the application permits a user to log in over an HTTP connection (rather than forcing HTTPS and TLS), then the user’s password will be communicated in plaintext and at risk from eavesdropping. Web apps should never provide a login screen over HTTP or accept a login over HTTP.
Plaintext Passwords at Rest
If the application stores passwords in plaintext, then should that data store be compromised, all of the account passwords would be accessible to the attacker. While symmetric encryption provides some security, it is considered a far weaker control than using cryptographically secure hashing combined with a unique salt (see the “Cryptographic Methods” section for more information).
Weak Passwords
The main proponent to creating a weak password, besides weak password requirements themselves, is forcing users to regularly change their passwords. That might seem counter- intuitive at first, but the perspective on mandating regular password changes has shifted in recent years from being a sensible one to being counterproductive in ensuring a strong password. Forcing users to regularly change passwords often forces users to find the weakest allowable password.
Merely forcing passwords to use a combination of upper and lower case letters, dig- its, and/or special characters, or forcing passwords to be regularly changed, is no longer considered advisable. Many users who are forced to change their passwords regularly will weaken their authentication in one or more of the following ways:
- Choose a password very similar to the old one
- Choose a password that merely passes the trivial requirements
- Choose a password used elsewhere
- Develop bad habits of writing down passwords
- Forget their password more frequently, losing productivity
What might help in addressing some of these points is for the application to screen new passwords against a list of known “weak” passwords to prevent users from using one.
Single-Factor Authentication
Relying upon passwords alone to protect sensitive information is foolish. Not only do passwords get written down or shared, social engineering and phishing attacks can easily obtain many user passwords.
The best protection from this is (at a minimum) supporting, and (preferably) requiring the user provide to a second authentication factor such as a time-based one-time password.
Note that sending an SMS text message to the user’s phone is no longer recommended by NIST (in their publication SP800-63B), as there have been a number of successful exploits against this approach.
Password Guessing
Web systems should detect attempts to brute-force the authentication system by using a bot to try commonly used passwords. This can be done in a number of ways:
- Using a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) mechanism to try to detect bots (either for all logins, or after a certain number of login failures)
- Delaying subsequent login attempts after each failure (and increasing the delay with each failure)
- Locking out the account completely (for an extended period of time, until the user reactivates the account by responding to an email message, or until unlocked by an administrator)
Man-in-the-Browser Attack
Users’ browsers can be compromised through malware such that the authentication information they enter during the login process is captured and relayed to the attacker. As this eavesdrops on the data before it is sent over the HTTPS link, the encryption protection that comes with TLS is ineffectual.
MitB attacks are usually launched via a Trojan that compromises the victim’s browser. These attacks can be mitigated to a certain extent by basic security hygiene:
- Do not install browser extensions or addons from untrusted sources.
- Keep your operating system and browser up to date (i.e. patched).
- Install and update anti-malware or endpoint detection and response (EDR) software.
Browsers are adding sandbox or containerization features (e.g. Site Isolation in Chrome) that limit the ability of a website to affect other sessions or websites.
For particularly sensitive web applications, there are other security controls that are more effective but add considerably to the complexity of using the web applications:
- An out-of-band communications channel can be used to confirm the transaction (for example, for a request to wire funds, especially above a certain threshold, or out of the country, the banking application might place a call to the user requiring personal approval of the transaction by speaking to a banking representative to confirm the identity).
- Requiring use of a hardened web browser that is run from a write-protected USB device to access the web app.
Session Hijacking
As users interact with a web application, the app needs to keep track of which requests came from which users. To connect disparate HTTPS requests to a single user, session tokens are used. These are data sent with every request, unique to each user, that identify the origin of the request and tie multiple requests into a single session.
In order to prevent an attacker from masquerading as an authorized user, it is critically important to ensure that the session token remains secret. If the attacker knows the session token, it can be inserted into communications to make the attacker appear to be the authorized user.
Session tokens can be compromised by:
- Guessing: Secure session tokens must be generated by a cryptographically secure pseudo-random number generator, making predicting session values highly unlikely.
- Brute-force: Secure session tokens must be long enough (at least 128 bits) to make trying every possible session token value infeasible.
Session tokens must also be invalidated when the user successfully logs in (to be replaced with a new session token), and when the user is logged off (either manually or after the session has expired).
