Programs that store a password as cleartext (unencrypted text data) risk exposure of the password in a variety of ways. Programs must prevent this information from being leaked. Although a program will generally receive receives the password from the user as cleartext, this should be the last time the password is in this form.
An acceptable technique to limit the exposure of passwords is the use of Hash 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. In practice, one can encode a password can be encoded to a hash value, but decoding remains infeasible. The equality of the passwords can be tested through the equality of their hash values.
It is important that you append a salt to the password you are hashing. A salt is a randomly generated piece of data that is stored along with the hash value. The use of a salt helps prevents prevent brute-force attacks against the hash value, provided the salt is long enough. Each password should have its own salt associated with it. If a single salt were used for more than one password, two users would be able to see if their passwords are the same.
The choice of hash function and salt length presents a trade-off between security and performance. If it takes longer to compute a hash value, then the performance of a brute-force attack will be is lowered. This will come at the cost of slowing down the program when it validates passwords. If a longer salt length is used, then the performance of a brute-force attack will be is lowered at the cost of the extra storage space required.
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.
...
This noncompliant code example encrypts and decrypts the password stored in credentials.pw.
.
Code Block | ||
---|---|---|
| ||
public final class Password { private void setPassword(byte[] pass) throws Exception { bytes[] encrypted = encrypt(pass); //arbitrary encryption scheme clearArray(pass); saveBytes(encrypted,"password.bin"); //encrypted password to password.bin } private boolean checkPassword(byte[] pass) throws Exception { boolean arrays_equal; byte[] encrypted = loadBytes("password.bin"); //load the encrypted password byte[] decrypted = decrypt(encrypted); arrays_equal = Arrays.equal(decrypted, pass); clearArray(decrypted); clearArray(pass); return arrays_equal; } private clearArray(byte[] a) { //set all of the elements in a to zero } } |
...
Noncompliant Code Example
This noncompliant code examples example implements the SHA-1
hash function through the MessageDigest
class to compare hash values instead of cleartext strings.
...
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 can be copied and internally stored by the Java Virtual Machine (JVM). Consequently, Java lacks a mechanism to securely erase a password once it has been stored in a String
. See MSC56-J. Limit the lifetime of sensitive data for more information.
...
In both the setPassword()
and checkPassword()
methods, the cleartext representation of the password is erased immediately after it has been is converted into a hash value. Consequently, an attacker cannot get the password as cleartext after the erasure.
Exceptions
MSC04-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 permitted, even though it violates the rule. The password manager is accessed by a single user and always has the user's permission to store their his passwords and to display those passwords on command. As a result, provided the user is competentis competent, the program's operation will be safe.
Risk Assessment
Passwords stored without a secure hash are exposed to malicious users. Violations of this rule generally have a clear exploit associated with them.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7ed3fee75934aa45-a0d3d644-42dc4cc9-b74fbf3d-60201849225dd2ae394dadbc"><ac:plain-text-body><![CDATA[ | [ISO/IEC TR 24772:2010 | http://www.aitcnet.org/isai/] | "Insufficiently Protected Credentials [java:XYM]" | ]]></ac:plain-text-body></ac:structured-macro> |
CWE ID 256, "Plaintext Storage of a Password" |
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="0b8c7631d5bb1750-43d1232b-458d417a-8b57b400-3e174beced1bfcaa1a3103d9"><ac:plain-text-body><![CDATA[ | [SD:[API 2006 | java:AA. References#API 06]] | Class | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="98ed3e40bb165ed2-bde6312a-4daf48a9-bc488a10-9fa52ec6ce59d1ff44debef3"><ac:plain-text-body><![CDATA[ | [SD:[API 2006 | java:AA. References#API 06]] | Class | ]]></ac:plain-text-body></ac:structured-macro> |
Passwords never in clear text | ||||
Salt (cryptography) | ||||
Cryptographic hash function | ||||
|
...