Any time an application stores Programs that store a password as cleartext (unencrypted text data) , its value is potentially exposed risk exposure of the password in a variety of ways. To Programs must prevent this information from being inadvertently leaked, this exposure must be limited. While . Although a program will generally receive the password from the user as cleartext, this should be the last time it the password is in this form.
An acceptable technique to limit the exposure of passwords is the use of Hash functions, which 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.
...
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 In practice, one can encode a password to a hash value, while they are also unable to decode itbut decoding remains infeasible. The equality of the passwords can be tested through the equality of their hash values.
...
| Code Block | ||
|---|---|---|
| ||
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
public final class Password {
private void setPassword(String pass) throws Exception {
byte[] salt = generateSalt(12);
MessageDigest sha_1 = MessageDigest.getInstance("SHA-1");
byte[] hashVal = sha_1.digest((pass+salt).getBytes()); //encode the string and salt
saveBytes(salt, "salt.bin");
saveBytes(hashVal,"password.bin"); //save the hash value to credentials.bin
}
private boolean checkPassword(String pass) throws Exception {
byte[] salt = loadBytes("salt.bin");
MessageDigest sha_1 = MessageDigest.getInstance("SHA-1");
byte[] hashVal1 = sha_1.digest((pass+salt).getBytes()); //encode the string and salt
byte[] hashVal2 = loadBytes("password.bin"); //load the hash value stored in password.bin
return Arrays.equals(hashVal1, hashVal2);
}
private byte[] generateSalt(int n) {
//Generate a random byte array of length n
}
}
|
Even if when an attacker knows that the program stores passwords using SHA-1 and a 12-byte salt, they she will be unable to get retrieve the unencrypted password from password.bin and salt.bin.
While Although this approach 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 lacks a 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.
...
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 immediately after it has been converted into a hash value. After this happens, there is no way for Consequently, an attacker to cannot get the password as cleartext after the erasure.
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 permitted, 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 and always has the user's permission to store their passwords in this waypasswords and to display those passwords on command. 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 Passwords stored without a secure hash are exposed to malicious users. Violations of this rule generally have a clear exploit associated with them.
...