|
|
|
|
CWE-321 Individual Dictionary Definition (Draft 9)
Weakness ID
| Status: Draft 321 (Weakness Base) | | Description | Summary The use of a hard-coded cryptographic key significantly increases the
possibility that encrypted data may be recovered | | Likelihood of Exploit | High | | Common Consequences | Authentication: If hard-coded cryptographic keys are used, it is
almost certain that malicious users will gain access through the account in
question. | | Potential Mitigations | Design: Prevention schemes mirror that of hard-coded password
storage. | Demonstrative Examples | C/C++ Example: int VerifyAdmin(char *password) { if (strcmp(password,"68af404b513073584c4b6f22b6c63e6b")) { printf("Incorrect Password!\n"); return(0) } printf("Entering Diagnostic Mode...\n"); return(1); } Java Example: int VerifyAdmin(String password) { if (passwd.Eqauls("68af404b513073584c4b6f22b6c63e6b")) { return(0) } //Diagnostic Mode return(1); } | | Context Notes | The main difference between the use of hard-coded passwords and the use of
hard-coded cryptographic keys is the false sense of security that the former conveys.
Many people believe that simply hashing a hard-coded password before storage will
protect the information from malicious users. However, many hashes are reversible (or at
least vulnerable to brute force attacks) -- and further, many authentication protocols
simply request the hash itself, making it no better than a password. | | Relationships | | | Source Taxonomies | CLASP - Use of hard-coded cryptographic key | | Applicable Platforms | All |
|