When we are developing our solutions, it is common for us to need to connect different services. These services commonly require some type of credential, apikey, token or any access information. As an example, we have database access credentials, Google API keys, digital certificates, AWS credentials, etc. But what would happen if this information fell into the wrong hands?
For this reason we need to be careful with some information!
Checklist
Secrets in the Code
We must not leave any secret fixed in the code:
Secret hardcoded
// 🚫 BAD
const db = new DB({
user: 'DbUser',
pass: 'DbP@ss0rd!'
})
To solve this, we can use Environment Variables
// ✅ GOOD
const db = new DB({
user: process.env.DB_USER,
pass: process.env.DB_PASS
})
Or Password Vault:
Hashicorp vault
const vault = require("node-vault")({
apiVersion: process.env.VAULT_VERSION,
endpoint: process.env.VAULT_URL,
});
​
const roleId = process.env.ROLE_ID;
const secretId = process.env.SECRET_ID;
​
const run = async () => {
const result = await vault.approleLogin({
role_id: roleId,
secret_id: secretId,
});
​
vault.token = result.auth.client_token;
​
const { data } = await vault.read("secret/data/mysql/webapp");
​
const databaseName = data.data.db_name;
const username = data.data.username;
const password = data.data.password;
​
console.log({
databaseName,
username,
password,
});
};
​
run();
This type of information can be in several places:
- Code
- Settings Files (web.config, .env, application.properties, etc.)
- READMEs
Access Management
Ok, we've already removed the secrets found in the code, wikis, etc. But what about the access information that people need to have, such as a bank consultation credential or log panel, what does that look like? How will the development team fix a problem or gain access to the platforms?
It is common for team members to have passwords, certificates or keys to access environments and tools. Taking care of this information is also important.
To do this, some precautions need to be taken:
Nominal Credentials
Each team member who has access to a tool or platform must have their own credential, with a specific profile for their needs.
​
Access Scope
When problems occur in production or a new functionality requires an analysis of the environment to avoid breaking changes, the team needs information.
Instead of restricting access to everything, creating friction and delaying work demands, let's focus on one question:
What needs to be protected?
You may come to the conclusion:
- They cannot perform write operations.
- They cannot access personal, sensitive and confidential data.
Great, this is where the work is.
Reach out to the team and say:
"Hey people, we're giving you freedom, we're just not going to enable access to people's data and writing operations so as not to compromise the environment, okay?"
It's MUCH better than asking:
"What do you need?"
For the simple reason that in a WAR ROOM no one knows what they need (besides coffee and an aspirin, of course) and in the end you need to give access to everything because of the pressure.
Scratchs
​​
CWE-798: Use of Hard-coded Credencials
- Someone unauthorized has access to production credentials simply because they have access to the source code or documentation.
- Someone put the code in a public environment (public personal github, pastebin, etc.) and the secrets were leaked.
Guides
- SAMM - Secret Management
- OWASP Cheat Sheet - Key Management
- OWASP Proactive Controls - C8 - Protect Data Everywhere
- OWASP Cheat Sheet - Cryptographic Storage
Tools
- Password manager (personal / teams).
- For personal use, it is free, open source and can be used on multiple devices.
- For companies, it can be used as a vault.
- We recommend bitwarden for personal password manager use.
- Open source password manager for teams.
- It can be installed in different ways, but the main thing: it has a docker-compose.
- Vault for storing passwords, certificates or any other sensitive information.
- There is a free and self-hosted option.
- Command line tool for detecting hardcoded secrets.
- It runs on docker and is capable of detecting more than 700 types of credentials.
- You can scan Github, Gitlab, FileSystem, Logs and S3 Buckets.
Trufflehog with Docker
docker run -it -v "$PWD:/pwd" \
trufflesecurity/trufflehog:latest \
github \
--org=trufflesecurity
- Gitlab (in all its versions) natively has a scan for hard-coded secrets.
- The free version is limited compared to the ultimate, but it is a great option if the company does not want to adopt an external tool or wants to use 100% of the platform they already pay for.
- Github has a built-in secret scan as well.
- It runs automatically in all repositories, but there are extra options if Advanced Security is purchased.
Usefull Links
Tutorials
- Creating a Node.js App that Records and Retrives Secrets from Vault
- Github :: Removing sensitive data from a repository
- Truffle :: How to Rotate Tutorials
Videos
Top comments (2)
Check this link out for Secrets Scanning and mitigating. the key need when scanning for secrets is to validate the secret. Invalid secrets cause way too much noise.arnica.io/solution/secrets
I wonder if they offer so much data to security engineers as this solution is not known on the market even after 5 years, something is not right! This is not a place to advertise a bad product.