...
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 You may be forced to encrypt passwords or store them as cleartext when you are extending code or an application that you cannot change. For example, a password manager may need to input passwords into other programs as cleartext.MSC18-EX1 You may be forced to encrypt password when using a library that returns the password as a Java string object, resulting in the vulnerability described in the second noncompliant example. In these cases your best strategy may be to use somewhat vulnerable methods such as encryption, unless you can change the other code Application such as password managers may need to retrieve the original password in order to enter it into a third-party application. While this violates the rule, it poses less of a risk because each password is stored with the particular user's permission.
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.
...