Password Management Hardcoded Password
Thank you for visiting OWASP.org. We recently migrated our community to a new web platform and regretably the content for this page needed to be programmatically ported from its previous wiki page. There’s still some work to be done.
This is an example of a Project or Chapter Page.
Hardcoded passwords may compromise system security in a way that cannot be easily remedied.
It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project’s developers to view the password, it also makes fixing the problem extremely difficult. Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability.
The following code uses a hardcoded password to connect to a database:
... DriverManager.getConnection(url, "scott", "tiger"); ...
This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user “scott” with a password of “tiger” unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above:
javap -c ConnMngr.class 22: ldc #36; //String jdbc:mysql://ixne.com/rxsql 24: ldc #38; //String scott 26: ldc #17; //String tiger
Related Technical Impacts
In addition, one should classify vulnerability based on the following subcategories: Ex:[[Category:Error_Handling_Vulnerability|Category:Error Handling Vulnerability]]
Error Handling Vulnerability
Input Validation Vulnerability
Logging and Auditing Vulnerability
Session Management Vulnerability]]