Page History

Hardcoding sensitive information, such as passwords, is an extremely dangerous practice. Doing so can have the following many ominous effects:

• The sensitive information can become accessible to whoever has access to the source code, for example, the developers.

• Wiki Markup
  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]\].

• In certain cases, it can also violate the fundamental principle of recalling the memory used to store the wiping out sensitive information from memory, as soon as the required operation has concluded. A carefully administered heap dump or application monitoring through a JVM debugger can expose the sensitive information if it persists over an extended period of time.
• Malicious users may use decompilation techniques to resurrect the hardcoded sensitive information. This is a critical security vulnerability.

...

Notably, when the password is no longer required, it is left at the mercy of the garbage collectorfree 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 malcious malicious user can use the javap -c Hardcoded command to disassemble the class and uncover the hardcoded password. The output of the disassembler as shown below, makes available reveals the password guest in cleartext.

...

Hardcoding sensitive information can lead to critical security vulnerabilitiesallows a malicious user to glean the information.

...

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Other Languages

This rule appears in the C Secure Coding Standard as MSC18-C. Be careful while handling sensitive data, such as passwords, in program code

...