...
Hash functions allow programs to indirectly compare an input password to the original, without storing a cleartext or decryptable version of the password. This approach minimizes the exposure of the password without presenting any practical disadvantages.
Cryptographic Hash Functions
The value that a hash function outputs is called the hash value. Another term for hash value is message digest. Hash functions are computationally feasible functions whose inverses are computationally infeasible. This means that in practice, one can encode a password to a hash value, while they are also unable to decode it. The equality of the passwords can be tested through the equality of their hash values.
...
Java's MessageDigest class provides the functionality of various cryptographic hash functions. Be careful not to pick a defective function such as MD5. Hash functions such as SHA-1 and SHA-2 are maintained by the NSA, and are currently considered safe.
Noncompliant Code Example
This noncompliant code example encrypts and decrypts the password stored in credentials.pw.
...
An attacker could potentially decrypt this file to discover the password. The attacker could be someone who knows or has figured out the encryption scheme being used by the program.
Noncompliant Code Example
This noncompliant code examples implements the SHA-1 hash function through the MessageDigest class to compare hash values instead of cleartext strings.
...
While this fixes the decryption problem from the previous noncompliant code example, at runtime this code may inadvertently store the passwords as cleartext. Java string objects are immutable, and they can be copied and internally stored by the JVM. Consequently, Java provides no mechanism to securely erase a password once it has been stored in a String. See MSC10-J. Limit the lifetime of sensitive data for more information.
Compliant Solution
This compliant solution addresses the problems from the previous noncompliant code example, by using a byte array to store the password.
...
In both the setPassword() and checkPassword() methods, the cleartext representation of the password is erased as soon as it is converted into a hash value. After this happens, there is no way for an attacker to get the password as cleartext.
Exceptions
MSC18-EX0: Applications such as password managers may need to retrieve the original password in order to enter it into a third-party application. This is okay even though it violates the guideline. The difference here is that the password manager is accessed by a single user. The program will always have the user's permission to store their passwords in this way. Therefore, provided the user is competent, the program's operation will be safe.
Risk Assessment
Violations of this rule have to be manually detected because it is a consequence of the overall design of the password storing mechanism. It is pretty unlikely, since it will occur around once or twice in a program that uses passwords. As demonstrated above, almost all violations of this rule have a clear exploit associated with them.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
MSC18 MSC05-J | medium | likely | high | P6 | L2 |
Bibliography
| Wiki Markup |
|---|
\[SD:[API 2006|AA. Bibliography#API 06]\] Class {{java.security.MessageDigest}} |
...