The use of hard coded cryptographic keys within software greatly increases the possibility that encrypted data may be uncovered. If the code is open source then everyone can read the keys. If the source is stored privately, attackers can possibly still get access to the code or partial snippets of the source code if they have access to the binary, JAR, APK, etc. Hard coded passwords are different than hard-coded cryptographic keys, in that the latter gives a false sense of security. A myth is that simply hashing a hard-coded password before storage will protect information from malicious users. However, many hashes are reversible and many authentication protocols simply request the hash itself, making it no better than passwords.
Impact of Hard Code Key
The impact of hard-coded keys is to by-pass protection and authentication mechanisms or assume identity of another user. By using a hard-coded keys, it increases the likelihood that the account using the key could be compromised by brute-force or other predictive attacks.
Examples of Hard Code Keys for Java
Examples of Hard Code Keys for Java
Vulnerable Code
public boolean VerifyAdmin(String password) {
if (password.equals("68af404b513073584c4b6f22b6c63e6b")) {
System.out.println("Entering Diagnostic Mode...");
return true;
}
System.out.println("Incorrect Password!");
return false;
Solution: Design out hard-coded keys The hard-coded keys should be designed out of the source code by picking an adequate secure storage mechanism to use, whether a database entry, private key store or online key store. Some examples based upon the context:
- Operating System and Browser Certification/Key Storage
- Using .pfx and .jks Files (Keystores)
- Cloud based key management solutions (AWS KMS, Azure Key Vault, Google Cloud KMS, Other independent vendors)
References
Cheat Sheet Series: OWASP Key Management Cheat Sheet
