Exploring CWE-261: Weak Encoding for Password
Writer’s comment: This blog is the third in a multi-part series focused on OWASP’s A02:2021 – Cryptographic Failures vulnerability and most of the 29 associated Common Weakness Enumeration (CWE).
Introduction
Passwords are some of the most commonly used authentication mechanisms. To authenticate to a system, a user provides a password, which is compared to a value stored on the server. If the two values match, then the user is granted access. Otherwise, access is denied.
While passwords are easy to understand and easy to implement, they are also easy to get wrong. Many of the most common cryptographic failures described by OWASP under the A02:2021 – Cryptographic Failures vulnerability deal with weak password storage. CWE-261 Weak Encoding for Password addresses the use of weak encoding algorithms to protect password security.
Why Passwords Need Encoding
For a password-based authentication system to work, the server or application performing the authentication needs to store some authentication data. A password-based system works by checking if the user knows the right password, so the server needs to be able to evaluate if a password is right or wrong.
The simplest way of accomplishing this is by simply storing a list of passwords on a computer. When a user tries to authenticate, an application can perform a string comparison to determine whether or not the stored password matches the user-provided one.
However, this approach to password-based authentication has significant security issues. If a computer or application is storing a master list of passwords, then anyone with access to that list has the ability to access and take over any user account. To address this potential security issue, password management best practices state that authentication data should be stored in a way in which the breach of this data does not expose the password itself.
An application should accomplish this through the use of a strong hash function. Hash functions are one-way, deterministic functions, meaning that it is impossible to determine the input from the output but hashing a particular input will always produce the same output. Additionally, hash functions are collision-resistant, meaning that it is infeasible to find two inputs to a strong hash function that produce the same output.
An authentication system using hash functions to protect passwords can compare the hash of a provided password with a stored password hash. If they match, then the user knows the correct password since it’s impossible to find an incorrect password that would generate the right hash.
However, if an attacker gains access to the file containing the hashes, they can’t easily retrieve the associated passwords.
Where Password Encoding Goes Wrong
Ideally, passwords will be stored in a way that protects them from being compromised if the encoded version is exposed. However, password encoding can go wrong in a variety of different ways, including:
- Storing Passwords in Plaintext: The simplest way in which a developer can fail to encode passwords is to not use an encoding algorithm at all. If passwords are stored in plaintext, then they are at significant risk of exposure.
- Using an Encoding Algorithm: Simple encoding algorithms like Base64 may make a password seem more secure because the password is not stored in plaintext and can’t be found by string matching. However, these algorithms are completely reversible, meaning that anyone can extract the password from the encoded version.
- Using a Weak Hash Algorithm: Some hash algorithms have become insecure because their hashes are short enough that modern computers can find collisions. Using one of these weak hash algorithms exposes the hashed password to brute force guessing attacks.
Case Study: Facebook
Password management best practices state that passwords should be stored in a hashed format at all times. However, in 2019 Facebook revealed an internal password storage issue that stretched back to 2012.
Facebook applications created by Facebook developers had access to plaintext password data. When these applications generated logs on company servers, these log files could include plaintext password information. Facebook determined that hundreds of millions of plaintext passwords were stored unprotected on corporate servers and that approximately 2,000 Facebook employees had access to these logs and made requests for log data that included users’ plaintext passwords. However, an internal investigation found no evidence that these compromised passwords were abused by Facebook employees.
Storing Passwords Securely
Storing authentication information is necessary for password-based authentication systems. A system needs something to compare to in order to determine if a user-provided password is correct.
When implementing a password-based authentication system, it is important to store authentication information properly. A few best practices for password management include:
- When possible, use an existing, reputable library for password storage
- When writing password storage code, follow OWASP guidance found in the Password Storage Cheat Sheet
- Limit access to plaintext passwords within an application
Up Next
To help build understanding of how cryptography can go wrong and how to fix it, we’ll continue to dive deep into prevention measures and most of the 29 CWEs related to OWASP’s A02:2021 – Cryptographic Failures vulnerability in a series of blogs. Each blog will describe the weakness, why it happens, a real-world case study, and recommended mitigations.
We’re incredibly passionate about tipping the balance of power in the good guys’ favor by openly sharing our knowledge and experiences with the internet community. To keep up with this series and our other research and cryptography content, make sure to subscribe to our blog in the page footer below.