|
|
|
|
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 |
|
- Weakness
- Base
- Variant
- Class
- Chain
- Composite
- Category
- View
- Deprecated
