PCI DSS v4.0: a bite-size guide to hardcoded passwords
To help organisations transition from PCI V3.2.1 to PCI V4.0 and maintain PCI compliance, Securious has developed a series of articles explaining how to implement the evolved requirements of the standard.
If you’re familiar with PCI DSS v4.0, you’ll probably know that one of the changes to the standard includes prohibiting storing passwords in scripts or files used for interactive logins in a hardcoded format. (Hardcoding passwords means storing passwords directly within code or configuration files in plain text, rather than using a secure method like hashing.)
However, hardcoded passwords don’t only pose a threat to organisations that handle cardholder data (and therefore require PCI DSS compliance). In fact, it’s an outdated and dangerous practice that will leave any organisation vulnerable to attack, and it is still a far more common practice than it should be.
So why does hardcoding passwords happen?
Convenience is one of the biggest reasons – hardcoding passwords can seem like a quick and easy way to set up a system, especially for simple scripts or internal tools.
In some cases, developers or system administrators might not be aware of the security risks involved in hardcoding passwords. Or, sometimes, developers might forget to remove hardcoded passwords during the development process.
Older systems or codebases might still use hardcoded passwords from a time when security practices weren’t as stringent, and updating these systems can be a complex and time-consuming process.
What are the dangers of hardcoding passwords?
Because hardcoding passwords means storing them in plain text, this makes it easy for attackers to find (and use) them. All they need to do is gain access to your code or files, and they’ll be able to easily find the hardcoded password and use it to log in as you.
An added danger is if the same hardcoded password is used across multiple systems or devices, an attacker only needs to find one password, and they can potentially access everything.
Another consideration is that developers might accidentally publish code containing hardcoded passwords, making them visible to anyone online. For example, in the Uber Breach (2014), a seemingly simple mistake by an Uber employee led to a major data breach.
The employee accidentally uploaded login credentials for Uber’s Amazon Web Services (AWS) account onto a public GitHub repository (essentially a public online storage for code). These credentials were hardcoded within the source code, meaning they were written in plain text. An attacker discovered the exposed credentials and used them to gain unauthorised access to Uber’s systems, compromising the data of millions of customers and drivers.
Does MFA address the risk around hardcoding passwords?
Multi-Factor Authentication (MFA) does not directly address the security vulnerability of hardcoded passwords.
MFA adds an extra layer of security because it requires an additional factor beyond just a password to login, like a code from your phone or a fingerprint scan.
But hardcoded passwords are still exposed. Even with MFA, if a hacker finds the hardcoded password, they potentially have the first factor needed to log in. With MFA, they would still need to steal or bypass the second factor, but the risk remains.
While MFA makes it harder to gain access, it doesn’t eliminate the risk entirely if the password itself is easily accessible through hardcoding.
You should therefore eliminate hardcoded passwords, making sure to always store passwords securely using hashing or encryption methods, with MFA providing an extra layer of security on top of your strong passwords.
How to ensure your passwords aren’t hardcoded
Ensuring passwords aren’t hardcoded involves a combination of technical controls (which provide a strong foundation because they automate secure practices and minimise the risk of human error), and user training (which educates users about the risks of hardcoding passwords, and equips them to identify and report potential security issues).
Technical Controls
- Secret Management Tools: These are specialised software applications designed to securely store and manage sensitive data like passwords, keys, and certificates. They eliminate the need to hardcode passwords in scripts or code.
- Password Hashing: This is a one-way encryption technique that transforms passwords into a scrambled format. Even if someone steals the hashed password, they cannot easily reverse it to get the original password.
- Configuration Management Tools: These tools automate the deployment and management of system configurations, including credentials. They can ensure passwords are not accidentally stored in plain text within configuration files.
User Training
- Developer Training: Developers need training on secure coding practices, including the dangers of hardcoding passwords. They should learn how to use secret management tools and password hashing techniques.
- Security Awareness Training: All users who have access to systems or code should be aware of the risks of hardcoded passwords. They should understand the importance of strong passwords and not share them with anyone.
To summarise
In conclusion, hardcoded passwords are a relic of the past, posing a significant risk to any organisation, regardless of your PCI DSS compliance status. While convenience might seem tempting, the potential consequences of a data breach far outweigh the initial time saved.
By implementing a combination of technical controls like secret management tools and password hashing, alongside user training for developers and all system users, you can establish a robust security posture and eliminate the vulnerability of hardcoded passwords.
Remember, strong passwords are essential, but proper storage is just as crucial.
If you would like to discuss this further, please get in touch using the contact form below.
More PCI DSS content
PCI DSS Compliance – the Ultimate Guide