Demystifying Cyber Risks: Credential Management

Securing Passwords and Secrets

Passwords are still the most widely used method to authenticate a user to a system. According to NordPass, in 2021, the average internet user had around 100 passwords for various online services.

Let's face it, humans are not the best at generating or memorizing small detailed random bits of information. Unless they're obscure music lyrics from a 1990 rock song (this skill can help you create secure passwords - more on this later).

It is vitally important to ensure that a system can strongly validate that you are you and that no one else can masquerade as you by guessing or spoofing your credentials. For this reason, we need to care about how we are creating secure and unique passwords.

Suppose you are a system developer or maintainer. In that case, you may also have system-to-system secrets to manage the generation and storage. System secrets, while they perform the same functionality as user passwords. that or authentication of one system to another. We can take different approaches to generate and store them that improve the security of the intersystem authentication.

This blog post will describe the risks associated with the generation and storage of passwords and secrets, both as an end-user and a system developer. We will identify the current industry best practices you can implement to reduce these risks.

What are Passwords and Secrets

In our previous blog post, we discussed the various authentication factors:

 - something you know

 - something you have

 - something you are

 - adaptive (risk-based) authentication

A mixture of these factors should be used to strongly authenticate a user to a system (known as Multi-Factor Authentication (MFA)).

Passwords and secrets are the "something you know" authentication factors.

Passwords and secrets are a string of characters only known to a specific user (or system) and the service they need to authenticate to.

Passwords and secrets are technically the same things. When we refer to a password, we generally refer to a secret known by a user. When we talk about secrets, we usually refer to a secret key used for machine-to-machine authentication.

The risks associated with passwords and secrets are very similar. However, the mitigation strategies can vary as password security needs to consider the human factor, while secrets security can take advantage of different strategies such as automation. We will dive into these a little later.

While MFA is important to a secure authentication system, we can't forget about ensuring that our "something you know" passwords and secrets are generated and stored securely.

Passwords

Password Entropy

The primary feature of a password is that it is only known by the user and the system they are trying to authenticate to. No one else should be able to guess or predict your chosen password. The most obvious approach to achieve this is by choosing a complex password.

A more scientific term for complexity is entropy. Entropy is a measure of how unpredictable a password can be (given it is randomly generated). There are 2 ways to increase the entropy of a password:

1. Increase the symbol count
1. Symbol count is how many different options there are for one character. e.g., numerals (0-9) have a symbol count of 10, compared to the ASCII printable characters, which have a symbol count of 95.
2. the higher the symbol count, the higher the entropy
2. Increase its length
1. Password length increases its entropy exponentially. e.g., a two-digit pin has 10 possible combinations 10^2. If you add one digit, you have 100 possible options 10^3. Add 1 more digit, and you have 1000 10^4.
2. Entropy grows exponentially as you increase its length.

If you want to dive deeper into password entropy, the Wikipedia description is pretty good.

With a password-cracking application such as Hashcat and a reasonably powerful computer, a password with low entropy may be easily guessed. This process is known as brute-forcing. The application will try every possible password within the keyspace to find the correct one. According to Hive Systems a:

• 9 lowercase characters password can be cracked in 10 seconds
• 9 ASCII characters password in 2 days
• 10 ASCII characters password in 5 months
• 11 ASCII characters password in 34 years.

As we can see, a password with a high number of symbols and a longer length becomes exponentially more challenging to crack. However... this is based on the randomly generated password, which we know humans are not that great at doing by themselves.

For this reason, organizations have attempted to require users to generate more "random" passwords by enforcing various password complexity rules.

The Password Complexity Debate

Over the years, the industry recommendations for password complexity have evolved, and there is still debate about the validity of some of the requirements recommended by different organizations.

Historically, password complexity rules have consisted of a mixture of the following:

• A length greater than 8, 10, or 14 characters
• Must contain:
• lowercase, uppercase, number, and special characters
• Cannot contain repeated characters
• Cannot contain sequential characters
• Cannot contain known weak passwords
• Must be changed every 30, 60, or 90 days
• Cannot use a password you have previously used
• The list goes on.

Creating a password was becoming complex for the average human brain, and good luck remembering what you set. While security professionals thought they were mitigating risk, they were not considering the human factor, which was actually causing increased risk.

Users wrote their "secure" passwords on post-it notes and stuck them to their monitors or under their keyboards. They remembered one or two "secure" passwords and reused them across multiple systems. They just incremented a number whenever they were required to change the password. We cannot blame users for these practices as the systems should have been designed to help, not hinder them.

Let's look back at our description of password entropy. We can see that length actually has a more significant impact than complexity. This fact was popularized in 2011 by XKCD's Password Strength comic strip:

​​

Around this time, organizations began to refer to passwords as passphrases to promote choosing a lengthy password (made up of random words) over the previous complexity practices. You know those song lyrics you've got stuck in your head? They are an excellent seed for a passphrase:

Never gonna give you up

Never gonna let you down

Never gonna run around and desert you

Your passphrase may end up being: "UP-down-Desert-U!".

This approach was further standardized when the US National Institute of Standards and Technology (NIST) updated its guidance on passwords in 2017 (in NIST Special Publication 800-63) to the following:

• Verifiers should not impose composition rules.
• Passwords must be at least 8 characters in length.
• All printing ASCII characters, space characters, and Unicode characters should be acceptable in passwords.
• When establishing or changing passwords, the verifier shall advise the subscriber that they need to select a different password if they have chosen a weak or compromised password.
• Verifiers should offer guidance such as a password-strength meter to assist the user in choosing a strong password.

The Importance of Uniqueness

Let's be honest; we've all been guilty of reusing a "great" password for multiple systems. However, A password is only secure if it is known by only the user and THE system it is used to authenticate to. We break this fundamental rule when a password is reused across multiple systems, as now, a third party is involved in maintaining the confidentiality of the shared secret.

When a system is compromised, the attackers may attempt to exfiltrate the database that stores the user credentials. Suppose these credentials have not been stored securely. In that case, the attackers may be able to extract the cleartext password for every user of the system. These are known as "password dumps".

Password dumps are widely bought, sold, and shared on the shadowy corners of the internet to be used in what is known as "credential stuffing" attacks. In a credential stuffing attack, an attacker will have compiled a list of passwords known to have been used by their victim from password dumps and will attempt to log in to various other sites with these known credentials. Suppose a user has reused a password in a password dump on another system. In that case, the attack may be able to log in and compromise your account.

These attacks have become extremely common due to:

• The ever-growing list of password dumps from compromised services,
• The low processing power required (compared to password cracking and brute-forcing), and
• The prevalence of password reuse.

If you are interested in knowing if your credentials have even been included in a publicly released password dump, then check out https://haveibeenpwned.com/. Have I Been Pwned (HIBP) allows you to search for your email addresses to see if your details have been included in a data breach? The HIBP database contains evidence for over 11 billion compromised accounts - so it's highly likely you may be in there...

While we can shout at users, "Don't reuse your passwords," as loudly and as frequently as we want to, it will not stop it from happening. Therefore we need to find better strategies to mitigate this risk.

One such mitigation strategy that popular web browsers have recently implemented is breach notification in their applications. These services notify users when they have chosen a weak or attempt to use a known compromised password.

Another mitigation strategy against password reuse is to use a password management system. We will go into more details about what these are soon.

Until passwords are a thing of the past, password reuse will be a persistent risk that we must deal with.

The Changing Opinion on Password Rotation

Another controversial topic on the subject of passwords is whether password rotation is an effective or harmful strategy for password security.

Password rotation refers to the requirement for users to change their passwords every X number of days. It was believed that reducing the password's lifespan would reduce the risk of password-based attacks by reducing the time for the password to be valid.

While the positive impacts of password rotations were clear on the surface, such as:

• reducing the window of opportunity for attacks
• minimizing the impact of a successful breach

Unfortunately, human nature was not considered when password rotation was recommended as effective control. Password rotation policies result in users relying upon repetition, sequencing, and context-specific approaches to password selection, all of which reduce the randomness and complexity of the passwords chosen. It also increases the likelihood of the password being written down.

In a study by Widmeyer in 2014, companies lose upwards of $420 of productivity annually per employee due to workers grappling with password issues such as lost or forgotten passwords.

Because of these human-based issues, which weaken the security of the password-based authentication system, both Microsoft and NIST have removed password rotation from their password policies.

How Servers Store Passwords

How servers store credentials, especially passwords, is critically important to the system's and its users' security. Insecurely stored passwords may lead to theft and disclosure, resulting in account compromise and the creation of new password dumps for use in credential stuffing attacks against other systems.

Passwords should never be stored in cleartext or in a form that can easily be reversed into revealing the cleartext password.

To achieve secure password storage, we use what is known as a cryptographic hash of the password. A cryptographic hash is a mathematical function that takes input data and transforms it through a one-way function to produce a fixed-length output. The one-way function has been specifically designed so that it is practically infeasible to reverse.

For example, the input of "hunter2" produces the SHA2 hash of "71a8a7c1fcdbb6de4f7de52ea71fe5f883d83e553cd22464042c35a69fea31a479d3898f8bbcdf58774587b4e9de8e157598dcaf3fa3ff7fa630da8b0f3bad47".

The current best practice is to use the SHA2 or SHA3 family of hashing algorithms. These algorithms were developed by the United States National Security Agency (NSA) and have been adopted as part of the NIST standard.

You may hear or have seen the MD5 hashing algorithm before; however, this algorithm is no longer recommended. MD5 produces a small digest (16 bytes) which results in a weakness known as a collision attack, making it no longer suitable for cryptographic hashes.

However, a weakness of hashing is that hunter2 will always produce that same hash. So if we find a user database that contains that hash, then we know that its cleartext mapping is "hunter2". Large lists of pre-computed cleartext to hash mappings lists exist to perform this at scale. These lists are known as rainbow tables and are quite extensive in size and easily obtained. Sites such as http://project-rainbowcrack.com/table.htm provide various types and sizes of rainbow tables. For example, a rainbow table for the full ASCII range of 1 to 8 characters is a 65Gb file.

To mitigate the rainbow tables risk, system developers must generate password hashes with an additional unique string appended to the end of the cleartext password before calculation. This is known as salt. Salt is not secret and can be stored in the database alongside the user's details. In many instances, the salt is appended to the hash before storing.

For example, if we take "hunter2" as our password and append the salt "34h5mh53" to the password our hash is: f383e8f860ec5c8f06e7d03725859edd23ecf1a79bb0ee15d7ea6f3e322241d03f24d18402dc20b38817206593824b099b7ea8a6114b7a97af7226f0732407e1.

When another user decides to use "hunter2" as their password, a new unique salt is appended such as "ffhv634q", which produces an entirely unique hash - "0a05c120f2c8e0368c1b923cc8dfba99c2140d056da1cfbfa73ccfbd52d540842c7d9cea7fb7f8fa0e8719c960551c786c34db7678ecd22e2ba9391eae0d2cb4".

There is no way to identify that these 2 hashes are related to the cleartext "hunter2" password.

When performing password hashing, it is strongly recommended to not try and implement the cryptographic functions yourself. Instead, it is best practice to use a known secure cryptographic library such as Argon2, scrypt, bcrypt, or PKBF2. These libraries implement additional security controls such as multi-iteration calculations and cryptographic secure salting and storage. Additionally, these libraries have been heavily audited to ensure they are cryptographically secure implementations.

Password Management Systems

We have these requirements for our passwords to be complex, lengthy, and unique. Still, we know as humans that this is not something we can just easily produce or remember, so what's the solution? Password Managers.

A Password Manager is an application that can securely generate and store all your passwords. They do this by creating an encrypted database for your passwords, secured by one strong "master password" you create and remember. Essentially they are providing a service where you are only required to remember one good strong password to access all the other passwords.

Password Managers encourage good password habits as you are no longer required to generate or remember 100s of unique passwords.

Password managers are not risk-free. Suppose your master password is weak or has become compromised. In that case, an attacker may be able to access all your passwords which would cause a significant issue. For this reason, if you use a password manager, it is crucial to choose a strong and unique password. If available, utilize Multi-Factor Authentication alongside your master password.

There are many password managers available to choose from. Most of the popular web browsers contain in-built password managers; however, you need to ensure they are configured to use a master password because, by default, most do not. Other options include cloud-based services or local file-based implementations. When choosing a password manager, do your research and select a solution from a reputable vendor.

System Secrets

While we have focused mainly on user passwords, there are also system secrets, as previously mentioned, that we need to care about.

Secrets used by systems are everywhere yet rarely seen; however, they are essential to the security of our system and information. System secrets can include:

• API keys
• SSH keys
• databases credentials
• system-to-system passwords
• Certificate Private Keys

Cloud-based systems have drastically increased the number and variety of system secrets that developers and administrators need to manage and secure.

Just like passwords, system secrets must be complex, lengthy, unique, and only known to the systems which are party to the authentication process. Additionally, system secrets should only be accessible or modifiable by a minimal subset of system maintainers.

Risks that are unique to system secrets include:

• Hardcoded credentials
• Secrets that are hardcoded within source code or system configuration files are difficult to manage and may be exposed to individuals that should not have access to them.
• Manually managed
• It is very easy to "set and forget" system secrets. . They may never be rotated and may be very difficult to revoke. Most secrets do not age well and may be insecurely configured without an effective management approach.
• For example, not changing system default secrets or forgetting to reissue and renew expiring private keys.
• Highly privileged
• System secrets can be highly privileged as they are usually used for system functionality, such as writing to a database.
• If an attacker could access a system key, they may be able to perform highly privileged system actions.
• Environment management
• It is vital to ensure that different keys are used for different development environments (e.g., Dev, Test, QA, Production).
• Suppose production keys are used within development systems. In that case, production information is exposed to anyone with access to the development environment.
• DevOps misconfigurations
• System secrets are commonly managed within the CI/CD pipeline system of DevOps tools. If not secured effectively, these systems may leak secrets to unauthorized individuals.

We need to implement an effective secret management system to mitigate these risks.

Secrets Management Systems

A Secrets management system manages secrets securely and centrally throughout the secrets lifecycle.

A secrets management system should provide the following functionality:

• Generate
• Cryptographically secure secrets can be generated automatically.
• Generation is use specific. For example, an API key might be 50 random ASCII characters, while a private certificate key would be a 4096-bit RSA key.
• Store
• Secrets are stored within encrypted databases only accessible to those systems with a need to know.
• Secrets permissions can usually be set at a per secret level so that only the secrets relevant to a specific system can be retrieved.
• Use
• Secrets can be retrieved from a secrets management system at runtime, limiting the locations where a secret could be accessed and compromised.
• When used, the secrets management system is also responsible for securely transmitting the secret to its required location. This is usually achieved through some form of encryption.
• Rotate
• Automation enables the implementation of secret rotation. If performed automatically, without manual system administrator intervention, secrets can easily be frequently rotated.
• For example, digital certificates issued by the Certificate Authority Lets Encrypt require that certificates be reissued every 2 months. Without a secrets management system or automation, this would be time-consuming to perform so frequently.
• Revocate
• Revocation can be used when unusual behavior is detected. Revocating unneeded, expired, breached, or weak secrets is essential in effective secrets management.

Like Password Managers, there are many secrets management systems available to choose from. Most cloud providers have native solutions that work exceptionally well with their various cloud services. Other cloud-agnostic or on-premises solutions are available too, which provide very similar functionality. When choosing a secrets management system, research and select a solution from a reputable vendor with the functionality and system integrations required by your applications.

Conclusion

Unfortunately, passwords and secrets are not going away any time soon, and we mere mortals will not evolve quickly enough to be good at generating or remembering all the passwords we need to.

Additionally, attacks against credentials are becoming more prevalent, sophisticated, and impactful. According to the Verizon Data Breach Report 2022, over 45% of breaches resulted from the use of stolen credentials.

While this all sounds quite doom and gloom, fortunately, we have technological solutions available to us to help mitigate these issues. Using password and secrets management systems, we can utilize centralized management and automation to better generate and store our passwords and secrets.

Secure Credential Management

Prompt

• password complexity considerations and why - (hint: Password Hash Cracking - talk about where that is relevant)
• Contrast the value of password complexity with the value of enforcing a known bad password list
• password rotation and NIST guidance about not enforcing rotation of credentials unless the password is identified in a breach
• Access keys and where they're commonly stored (developer/SRE/DevOps user machines + CI/CD Systems)
• Access Key rotation considerations
• Preference for Temporary Access Keys over permanent Access Keys.