Reused Secret
Play Labs on this vulnerability with SecureFlag!
Description
Secrets and keys are used for a variety of purposes, from seeding encryption algorithms to authenticating APIs. No matter the purpose, it is essential not to use the same secret for multiple applications. In the unfortunate scenario that one secret gets exposed, all applications using the same secret are compromised.
In more complex scenarios, a reused secret could be manipulated to bypass security mechanisms that rely on them, such as JWTs (JSON Web Tokens). And, with certain encryption configurations, it becomes possible to fully compromise the encryption layer.
Impact
The impact of a secret being leaked is multiplied with each reuse of a secret. In addition, reusing secrets can have unexpected side effects that an attacker could use against an application.
A common scenario is when a privileged user reuses the same password for accounts that should be segregated. Suppose the password to a personal account of a company employee is leaked, and said employee uses the same password for their organization accounts. In that case, an opportunistic attacker may be able to log in to their work emails or administrative consoles.
Or consider this example, wherein an application that generates hashes uses the same secret it uses to sign JWTs. This secret reuse would allow an attacker to create a hash that can be used to sign arbitrary tokens. Further, due to the reuse, if the secret were leaked for either application, then both would be compromised.
Such a leaked secret could lead to losses of confidentiality, integrity, and availability depending on the context of the exposure. The fact that secrets and keys are ubiquitous across nearly all software also makes the impact of exposure more complex to assess, as it is dependent on the secrets’ purpose.
Prevention
The reuse of secrets can be prevented by:
- Generating a new secret for every use
- Rotating secrets on a regular basis
- Never hard-coding secrets in source code, which encourages reuse
Testing
Verify that secrets and keys are not used for more than one application and that secrets are never exposed in source code, which may encourage developers to copy and use them elsewhere.
- OWASP ASVS: 6.2.6
- OWASP Testing Guide: Source Code Review
- OWASP Testing Guide: Test Application Platform Configuration)
References
CWE - Reusing a Nonce, Key Pair in Encryption CWE - Use of Hard-coded Credentials CWE - Use of Hard-coded Cryptographic Key CWE - Use of Hard-coded Password