There’s now more money and information stored digitally than physically. Secrets unlock the infrastructure holding millions of dollars and intellectual property stored digitally. And that is the reason why cybercriminals are perilously looking for exposed secrets and security mistakes that can be exploited to get privileged access to databases in GitHub and DevOps tools. Cyberattackers are consistently getting rich because of errors made by developers when handling secrets.
The center for strategic and international studies has indicated that close to $600billion is lost to cybercrime annually.
Poorly managing secrets by hardcoding and storing secrets in an env file may be uncomplicated and time-saving. But these practices lead to costly mistakes that open the gates for hackers to make millions yearly by demanding ransom and seizing sensitive information.
Henceforth, it is imperative to avoid these mistakes at all costs by implementing security measures such as using a secret manager, robust encryption algorithms, and protecting data in transit.
In this article, you will learn about some of the mistakes developers make when handling secrets and how to intercept them.
What we will cover in this article
- Hardcoding secrets and exposing them on GitHub
- Poor password management
- Using a weak encryption algorithm to encrypt secrets
- Inadequately protecting secrets in transit
- Not using a secret manager
- Conclusion
Hardcoding secrets and exposing them on GitHub
Using an API eliminates the need to write a program that integrates two applications and also reduces development costs. But enjoying the perks of using APIs comes with the responsibility of managing API keys and secrets effectively.
Last year over 2 million API secrets were exposed on public Github repositories. Many developers hardcode API secrets and keys because it's easy and it doesn't cost anything to hardcode secrets. While they unintentionally forget that the code is being shipped to a public repository.
Interestingly, 15% of leaks on GitHub occur within public repositories owned by organizations, and 85% of the leaks occur on developers’ personal repositories, this data clearly illustrates the complexity of secrets sprawl ~Gitguardian
Hardcoded and embedded secrets allow cybercriminals to perform password guessing which hands the secrets to the cybercriminals if the password guessing process is successful.
String apiKey = "ghgh780i0hut890werxx";
String apiSecret="hiy90jdry8hbuiuh906756";
Once an attacker spots the hardcoded secrets shown above. They can use them to impersonate you or gain highly privileged access to sensitive data and steal any valuable information. Once a security breach occurs, your company loses:
- Loyal customers
- Reputation
- Revenue
- Intellectual property
In some of the worst scenarios, hackers demand millions in ransom.
Here are some tips you can use to prevent hardcoding and leaking secrets:
- Do not store unencrypted secrets in .git repositories
- Use Gitguardian to detect leaked secrets on GitHub repositories.
- Don’t share unencrypted secrets in messaging platforms like slack and email.
- Instead of hardcoding secrets, use a secret manager for storing and managing your secrets.
- Regularly scan and search for hardcoded credentials and vulnerabilities in a project using static code analysis.
Poor password management
Password length, uniqueness, and complexity determine how much time it takes for a hacker to crack or guess the password. A short and simple (weak) password can be easily revealed using password spraying. Password spraying is a technique that involves using a well-known list of passwords like 123456789 to guess your password.
It is a pity to know that there are still system administrators and users who create these passwords, 1234 and abc123, just because they are in a rush and they can easily remember them. And the worst of it all, some people write passwords on a piece of paper and forget to erase them or store the paper safely.
It is important to use long and complex passwords to protect your systems from being penetrated using brute-force attacks. You can make the word “password” complex by writing it as $a55w0rd. But don't use it since it is already known in the password dictionary.
Complex and long passwords are hard to remember, but they are the only way to secure development environments and applications.
Here are seven password management best practices you should follow:
- Always change default passwords.
- Use a unique, complex, and long (8 characters and above) password for each account you own.
- Implement two-factor authentication for your accounts.
- Use a secret manager or a password vault for storing passwords.
- Do not use the same password multiple times.
- Use different passwords for all your accounts.
- Avoid using dictionary words as passwords. Attackers can use a dictionary attack tool to crack your password.
Using a weak encryption algorithm to encrypt secrets
The strength and weakness of the encryption key are determined by the size of the encryption key. The bigger the encryption key size, the stronger it becomes. An encryption key that uses 256 bits is considered to be strong today. An encryption algorithm that uses fewer or insufficient numbers is weak.
Scenario: If you were to use an RC4 encryption algorithm to encrypt SSH and API keys. Hackers would use a cryptanalysis tool installed on a specialized high-end laptop to crack the encryption using brute-force attacks since it has a weak encryption key. For the past two decades, many severe vulnerabilities have been discovered in the RC4 encryption algorithm such as invariance weakness.
Using a secret manager to encrypt secrets
A secret manager implements secret encryption best practices when encrypting secrets. No need to worry about which encryption algorithm is weak and shouldn’t be used. That is why you should use Doppler to encrypt keys that you want to share with your teammates via email or Whatsapp.
Inadequately protecting secrets in transit
Sensitive data that is moving from one network can be intercepted or lost if network security measures are not implemented. Unencrypted secrets that are consistently being shared with teammates through insecure networks are at risk of being seized by cybercriminals.
Tips on how to protect sensitive data and secrets that are in transit:
- Use the Advanced Encryption Standard (AES)-256 to encrypt secrets when transitioning them.
- Implement security measures such as network access control which keeps unauthorized users out of private networks.
- Adding a website firewall is a necessity that should never be forgotten. Henceforth, It is imperative to regularly update and audit firewall software. A firewall will go far in protecting data in transit from cyber-attacks such as brute force attacks, DDoS attacks, cross-site scripting.
- Always use encrypted connections such as HTTPS, SSL, and TLS to protect secrets in transit.
Not using a secret manager
A secret manager is a secure storage system that allows you to store, manage and, effortlessly access your secrets. Ignoring the need for a secret manager is a mistake that begets inconvenience.
Working in a development environment that does not have a secret manager increases the chances of you hardcoding secrets and using .env files to store secrets. Time limitations, few resources, rapid technology advancements. These are often challenging circumstances that developers encounter when developing applications. With these limiting factors being presented. The risk of poorly managing secrets increase because:
- Time limitation causes the developer to hardcode secrets in order to save time.
- Rapid technology advancements force developers to learn new technologies from time to time. Not every developer has access to adequate training, and this leads to developers mishandling secrets because different frameworks and software infrastructure use different techniques of storing and accessing secrets.
In addition, copying and pasting secrets across different frameworks is inconvenient.
A secret manager gives you convenience by managing your secrets while you focus on the critical aspects and components of the software project you are working on.
The table below gives a contrast between a development environment that has a secret manager.
Working in a development environment that has a secret manager | Working in a development environment that does not have a secret manager |
You can retrieve and access your secrets programmatically from the secret manager whenever you need them. | You have to create .env files or hardcode secrets to use your secrets. |
When your secrets are stored on the secret manager, you can deploy them anywhere. You can deploy them on React and Docker or any other framework and programming you are using. | You have to spend your time and effort trying to copy and paste hardcoded secrets or .env files secrets across frameworks used to build your application. |
You and your authorized teammates can access secrets via Doppler API —no need to send secrets through slack or email. | You have to send secrets to your teammates through messaging platforms such slack and email, which poses your secrets to cybercriminals and unauthorized people viewing them if you are using env files |
Conclusion
We, as developers, determine if the millions of dollars will be stolen or stored safely by how we manage secrets.
There may be many mistakes made when handling secrets not included in this article, such as poor security measures, inadequately validating SSL certificates. But handing over the task of manually managing secrets by installing Doppler, a secret manager, is the leading solution to eliminating many human errors made when handling secrets.
brew install dopplerhq/cli/doppler
Perfection is not attainable, but if we chase perfection, we can catch excellence.~ Vince Lombardi
Top comments (0)