...
| Wiki Markup |
|---|
Hardcoding sensitive information, such as passwords, is an extremely dangerous practice. |
...
This is because adversaries who have access to the class files can decompile them to discover the sensitive information. Additionally, once the system goes into production mode, it can become unwieldy to manage and accommodate changes to the code. For instance, a change in password may need to be communicated using a patch \[[Chess 07|AA. Java References#Chess 07]\]. |
...
|
Noncompliant Code Example
...
| Code Block | ||
|---|---|---|
| ||
class Hardcoded {
String password = new String("guest");
public static void main(String[] args) {
//..
}
}
|
Notably, when the password is no longer required, it is free to be garbage collected. This is because String objects are immutable and continue to persist even after they are dereferenced, until the garbage collector performs its job.
Secondly, a A malicious user can use the javap -c Hardcoded command to disassemble the class and uncover discover the hardcoded password. The output of the disassembler as shown below, reveals the password guest in cleartext.
...
This compliant solution uses a char array to store the password after it is retrieved from an external file existing in a secured directory. The password is immediately cleared out after use. This limits the exposure time.
...