Anatomy of a Password

CIAM plays a critical part in any SaaS solution to provide secure customer identity and access management, and one of the core aspects of this is authentication. Arguably, when it comes to user authentication — i.e. Login — and user registration, passwords are still the most common method for securing access to SaaS applications, even though momentum towards a Passkey future continues to grow:

In a world where cyber threats are constant and evolving, passwordless authentication mechanisms like Passkeys would be preferred. However, whilst the use of passwords still prevails, they must be handled, processed, and stored in a way that protects against the most advanced forms of attack, while ensuring a seamless and user-friendly experience.

My name’s Peter Fernandez, and in this article, I’m going to explore the anatomy of the password and the mechanics of password authentication within a CIAM integration, focusing on the security requirements for password workflows and the acquisition, processing and storing of user passwords.

Workflow

In a recent article, I wrote about some of the various attack vectors from a CIAM perspective, and, unsurprisingly, a large proportion of these are associated with password workflows.

In a typical CIAM integration, passwords are used as part of the various user Authentication scenarios, and such use typically follows a structured progression:

1. User Registration: A user creates an account by providing personal information, such as their email address, and a password. During this process, the password is validated, often with additional requirements such as length, complexity, the inclusion of special characters, etc.
2. User Login: When the user attempts to log in, they provide their credentials, i.e. their username/email and password. If the credentials match, the system grants the user access. If there’s a mismatch, the login attempt is rejected, and the user may be given a chance to reset their password.
3. Password Reset: Where a user forgets their password and needs to change it so that they can obtain access.

In all of the above, there will be some form of Password Transmission and Password Storage, so it’s vitally important that once the user submits a password, it’s handled in a secure manner — invariably involving some combination of both encryption and hashing as the password is transferred within the system.

In the sections below, I’ll explore the intricacies of password processing as part of the various workflow requirements. However, before getting into more detail, it’s worth considering the fact that the use of Social providers — something which is easy to achieve when integrating CIAM via an application-independent IdP — can be an effective mechanism for handing off password responsibilities to an upstream 3rd party, as discussed in a previous article:

Handling

As described in another article of mine, the use of an application-independent IdP should be preferred as part of a CIAM integration, and such an integration should prefer to leverage OpenID Connect as the protocol of choice; see the following for more details:

As part of this, the best practice recommendation of using the Authorization Code Flow supported by OIDC means that the handling of passwords should only ever be performed by the IdP, alleviating the need for application developers to be constantly and consistently aware of password policies and handling requirements.

If you subscribe to a 3rd party CIAM SaaS solution, then a lot of what you pay will be for the privilege of letting the 3rd party vendor take care of all the password handling (and storage) for you. There will undoubtedly be things you’ll need to manage yourself, such as password policies, and if you choose the DIY route, you’ll also need to be aware of the storage considerations regarding aspects such as encryption for transmission and database storage. So, the option could be to simply do away with handling passwords altogether, by prioritising Social authentication instead: for a DIY implementation, this is a great way of creating a low-cost CIAM integration which doesn’t require the potentially costly infrastructure for password support!

Encryption

The first consideration is when it comes to protecting the way a password is handled once it is acquired via user interaction. A CIAM IdP is typically implemented as a regular web application (as in a web application incorporating a backend service) and with an API-first approach as discussed in the following article:

This means that all communication between the user and the IdP, and the B2C/B2B SaaS Application and the IdP, is performed over HTTP, either directly or via the Browser. By virtue of this, security-sensitive data is more often than not transferred across the internet, so it must be securely encrypted to prevent it from being intercepted/hacked.

Fortunately, when using the HTTP protocol, it’s relatively easy to do this: any password that a user can supply, along with anything else of a security-sensitive nature, for that matter, can be encrypted by performing all communication using HTTPS.

Encryption is defined as a two-way cryptographic process, meaning that data can be encoded, often referred to as enciphered, as a variable-length string of characters, typically producing a result that’s complete gibberish but which can be deciphered back to its original value. The critical property of a cypher function is that it’s robust enough that computationally trying to brute-force the process of deciphering can’t be achieved within a reasonable time frame; i.e. if the key used by the cypher function is unknown, then trying to guess it is virtually/practically impossible.

HTTPS is facilitated by the use of a Certificate, which must be issued by a recognised Certificate Authority and which is typically created using public-private key cryptography enabled via a robust and specialised algorithm designed specifically for the purpose, e.g.:

• SHA-256: a.k.a. Secure Hash Algorithm – 256, and its often used companion SHA-512 (where additional security is required), both one-way compression hash functions designed to efficiently create unique cryptographic keys with minimal compute requirements.
• ECC: short for Elliptic-Curve Cryptography, being an approach based on the algebraic structure of elliptic curves over finite fields that allows smaller keys to be generated that provide equivalent security (compared to systems such as SHA).

Hashing

The next consideration is when it comes to password validation and subsequent password storage. A password must never be stored in its plain text form! Why? Well, imagine if, for some reason, the data facility in which the password is stored was compromised, how a bad actor could gain access to passwords potentially being used elsewhere; yes, most users still reuse passwords despite best practice recommendations to the contrary!

Likewise, a password shouldn’t be stored encrypted, as an encrypted password can potentially be decrypted, thus resulting in the same issue as if it were stored in plain text form (though requiring a more convoluted process because of the requirement to decrypt).

Instead, secure hashing should be performed on a password before any information is stored in some form of database/data storage facility. This also means that any password supplied as part of the authentication process needs to be hashed before it can be compared with the value stored: password validation is performed by comparing two hashes, not by comparing plain text values.

Hashing is a one-way cryptographic process that converts the plain text version of a password into a fixed-length string of characters, typically represented as a hexadecimal number. The critical property of a hash function is that it is computationally infeasible to reverse the process (i.e., get the original password in plain text from the hash).

However, simply using a standard cryptographic hash function (like MD5 or SHA-1) is insufficient for password storage due to vulnerabilities that allow attackers to exploit weaknesses in the algorithms. In modern CIAM systems, secure password hashing typically requires the use of specialised algorithms designed specifically for password storage, such as:

• bcrypt: One of the most widely used password hashing algorithms, bcrypt incorporates a salt (random data) to ensure that even if two users have the same password, their hashes are different. Additionally, bcrypt is adaptive, meaning its computational complexity can be adjusted over time to remain resistant to brute-force attacks.
• PBKDF2 (Password-Based Key Derivation Function 2): PBKDF2 applies multiple iterations of a cryptographic hash function on the password, making brute-force attacks more difficult by increasing the computational cost of each password guess.
• Argon2: The winner of the Password Hashing Competition (PHC) in 2015, Argon2 is a modern hashing algorithm specifically designed for password hashing. It is highly resistant to both brute-force and side-channel attacks, offering both memory-hard and time-hard features. It comes in two variants: Argon2d optimised against GPU cracking and Argon2i optimised for resistance to side-channel attacks.

The upside of using specialised algorithms is that the computed password hashes are more secure, however, the downside is that these algorithms require more computational processing to perform, resulting in the need for more resources — particularly where constant-time validation constraints need to be observed (see below for more) — potentially resulting in increased costs if your IdP implementation is on cloud-based infrastructure.

Salting

A key part of the password hashing process is the use of a salt. A salt is a random value that is combined with the password before hashing. The salt is unique for each password and ensures that identical passwords do not produce identical hashes. This prevents attackers from exploiting precomputed hash tables (called rainbow tables) to quickly uncover hashed values.

Salting also provides protection against dictionary attacks, where an attacker uses a list of common passwords to generate hashes and compare them with stored hash values. By adding a unique salt to each password, even if two users have the same password, their hashes will differ.

Key Stretching

Key stretching refers to the practice of applying a cryptographic function multiple times to slow down the hashing process. This is typically used alongside algorithms like PBKDF2, bcrypt, and Argon2. By increasing the number of iterations or the amount of memory consumed, key stretching makes it more difficult for an attacker to perform brute-force or dictionary attacks.

Validation

For password authentication to be secure, it is essential that the process of password validation, where a system compares the hashed value of the input password to the stored hash, occurs in a safe and secure manner. As discussed, password validation is typically performed by the backend component of an IdP, and a key consideration here is to ensure that comparison is done in a constant time (meaning it should take the same amount of time regardless of the values being compared). If the mechanism for comparing hashes isn’t performed in a constant time, attackers could potentially gain insights into a password hash by measuring how long the validation takes to fail an invalid password as opposed to pass a valid one.

Storage

Once a hashed (and salted) password has been registered for a user, it needs to be securely stored, otherwise, there’s no way to compare values when a user goes to authenticate. In fact, both the salt and the computed password hash need to be stored for any given user. The security of the stored password hashes and associated salts is of paramount importance, and here a number of key principles are used for securely storing password-related data:

• Encryption: the password hashes and salts should be stored in an encrypted database, ensuring that unauthorised access to the storage cannot reveal the password data. Full disk encryption (FDE) and encryption at the file level provide strong protection for stored passwords, ensuring that even if attackers gain access to the physical database, the data remains unreadable.
• Separation of Secrets: To prevent a breach from compromising the entire authentication system, it’s important to consider separating sensitive information. Password hashes and salts should be stored in different parts of the database or in separate security modules, making it harder for attackers to access both at once.
• Use of Hardware Security Modules (HSM): For organisations seeking even higher levels of security, Hardware Security Modules (HSMs) offer a physically secure way to store cryptographic keys and perform cryptographic operations. HSMs are tamper-resistant and designed to resist attacks, making them ideal for the most sensitive aspects of password processing.
• Monitoring to Protect Against Data Breaches: CIAM systems should include logging and monitoring mechanisms to detect suspicious activities. For example, multiple failed login attempts, unusual access times, or large-scale data extraction should trigger alerts, enabling rapid response to mitigate a breach.
• Regular Password Hash Audits: To ensure the ongoing security of stored passwords, password hashes should be audited regularly. This includes checking for outdated or weak hashing algorithms, assessing salt length and complexity, and ensuring the latest security best practices are followed.

Change

At some point, it’s almost inevitable that a user will forget their password and so will need to reset it. At some stage, a user may also want to change their password, either because they want to pre-empt any potential security risk or because they have been impacted by one. Poorly designed mechanisms for either can open doors for unauthorised access, while overly complex procedures can frustrate legitimate users; balancing security with usability is essential, and effective workflows for secure password reset and secure password change often end up being one and the same thing:

• Verify Identity Before Resetting: The most important aspect of a password reset/change is verifying the user’s identity before it occurs. This step prevents unauthorised individuals from hijacking accounts, and robust identity verification methods include:
  • Email or SMS Verification: Sending a one-time password (OTP) or link to the user’s registered email or phone.
  • Two-Factor Authentication (2FA): For higher security, require an MFA step before allowing a password reset.
  • Security Questions: Now considered insecure, should be avoided or supplemented with one of the stronger methods described above.
• Time-Limited, Single-Use Links: The act of password reset/change should only ever be handled by the IdP (see above for more details). This typically involves the generation of hyperlinks that are sent to a user (via something like email or SMS), and these links should expire after a relatively short period: typically 10–60 minutes, also becoming invalid after use. This limits the window of opportunity for an attacker to exploit a stolen or intercepted link.
• Avoid Revealing Sensitive Information: Revealing whether a specific email address or username is associated with an account during the reset request should be avoided. Generic responses like “If this email is registered, we will send a reset link” prevent attackers from confirming user information.
• Rate Limiting and CAPTCHA: To protect against brute-force or automated attacks, rate limiting should be enforced on all reset attempts. CAPTCHA can further distinguish human users from bots, reducing abuse of the password reset functionality.
• Communication Channel Security: As with all other HTTP communication, see above, always send reset links over secure HTTPS connections, and ensure emails are sent via trusted, authenticated mail servers. Educate users to avoid phishing by highlighting that your SaaS solution will never ask for a password directly (such as via email or the like).
• Encourage Strong Passwords: After identity verification, users should be prompted to create a strong, unique password, emphasising preferred password policy as described below.
• Notify Users of Password Changes: Send immediate notification to the account’s email address or registered device whenever a password reset is requested and/or a change is completed. This alerts the user if unauthorised activity has occurred and provides them with a chance to react quickly.
• Limit Password History Reuse: Prevent users from reusing recent passwords by checking new ones against a history of previous account password hashes and salts.
• Log and Monitor Password Reset Activity: Monitor and log password reset events for unusual activity. Unusual patterns, such as multiple reset requests for different accounts from the same IP, can signal an attack in progress.

Policies

First off, a CIAM implementation should enforce strong password requirements to ensure that users choose complex and difficult-to-guess passwords, etc. Password requirements often include a minimum length, a mix of uppercase and lowercase letters, numbers, and special characters, and policies should also prevent the use of easily guessable passwords, such as “password123” or “admin.” The example below is indicative of the complexity preferred by the likes of password managers (though an almost impossible ask for someone who is choosing a password without the help of one):

!(3s8my/!u*Jei9T1~t!"Ie<KMOGOA|BzVh1*<

Expiry and Rotation

Policies that also dictate the expiration and rotation (change) of a password should be considered. While traditional systems have relied on periodic password expiry to enhance security, modern CIAM implementations often avoid enforcing mandatory password expiration unless there is a specific security threat. Instead, encouraging the use of password managers and requiring users to update their passwords only when there’s a security breach or when a password is known to be compromised is a more effective strategy.

Account Lockout Mechanisms

To protect against brute-force attacks, a CIAM integration should implement an account lockout policy via mechanisms that trigger after a series of failed login attempts or login attempts from questionable/suspect locations. Additionally, a CAPTCHA or a set of challenge questions can be used as an extra barrier to prevent automated attacks.

Multi-Factor Authentication (MFA)

To strengthen password authentication, CIAM integrations should always encourage the use of Multi-Factor Authentication (MFA), though policies for doing so should be sensitive to balancing security with usability and mitigating friction. MFA adds an additional layer of security by requiring users to provide something they own (e.g. a mobile device or hardware token) in addition to something they know, and you can read more in my article entitled: