Security - Java Coding Guidelines - page 45

In both the setPassword() and checkPassword() methods, the cleartext representa-
tion of the password is erased immediately after it is converted into a hash value. Con-
sequently, attackers must work harder to retrieve the cleartext password after the erasure.
Providing guaranteed erasure is extremely challenging, is likely to be platform specific,
and may even be impossible because of copying garbage collectors, dynamic paging, and
other platform features that operate below the level of the Java language.
Applicability
Passwords stored without a secure hash can be exposed to malicious users. Violations of
this guideline generally have a clear exploit associated with them.
Applications such as password managers may need to retrieve the original password
to enter it into a third-party application. This is permitted even though it violates this
guideline. The password manager is accessed by a single user, and always has the user's
permission to store his or her passwords and to display those passwords on command.
Consequently, the limiting factor to safety and security is the user's competence rather
than the program's operation.
Bibliography
[API 2013]
Class MessageDigest
Class String
[Hirondelle 2013]
Passwords Never Clear in Text
[OWASP 2012]
“Why Add Salt?”
[Paar 2010]
Chapter 11, “Hash Functions”
14. Ensure that SecureRandom is properly seeded
Random number generation depends on a source of entropy such as signals, devices, or
hardware inputs. Secure random number generation is also addressed by The CERT ®
Oracle ® Secure Coding Standard for Java ™ [Long 2012], “MSC02-J. Generate strong
random numbers.”