Sensitive information such as access credentials, passwords, and cryptographic keys should not be stored in the source code. Hard coded passwords may compromise system security in a way that cannot be easily remedied.
Since so many systems are built using an n-tier model, managing automated authentication to back-end systems becomes a problem that needs a solution. For example, the application code might need to authenticate its connection to a back-end database upon which it relies. Many applications use a simple, hard-coded password in the application to ensure it will be able to connect properly. This is a bad idea for several reasons.
First, source code can generally be accessed by a large number of people at an organization spanning adjacent development teams, QA and sometimes even operations staff. That means the hard-coded secret isn't actually secret at all.
Second, 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.
Finally, when dealing with client-server applications or applets, any secrets embedded in the code itself are easily discoverable. A large number of Java byte-code parsers and de-compilers exist that facilitate the recovery effort.
How to Detect Hardcoded Passwords in Source Code:
IDE plugins can be used for detecting the hardcoded passwords in source code files. The IDE plugins detect the security vulnerabilities like hardcoded passwords while the developers write the code. The IDE plugins also allow writing custom rules based on your company’s security standards/policy. Examples of IDE plugins – OWASP ASIDE (Java), FindSecBugs(Java), SecureAssist(Java/PHP/.Net).
Static Application Security Testing (SAST) tools can also be used to scan the source code and detect the security vulnerabilities like hardcoded passwords in the code. This kind of scanning can be performed after the project development is done. The settings in SAST tools can be changed to optimize the scanning. Examples of SAST tools – IBM AppScan Source, HP Fortify, Veracode, CheckMarx.
Authored by Harihar Prusty