How to remove plain text passwords for a secure Java code base
Here are some strategies to remove plain text passwords from configuration files and your code base. It's one way a secure Java app can deter a malicious attack.
One of the most common problems identified by static code analysis tools is the presence of plain text passwords written directly into configuration files. It's typically a standard requirement not to have plain text passwords anywhere in the code base, but their presence is a reality in just about any software development project. All of which begs the question: How do you get plain text passwords out of a secure Java code base?
Most software development frameworks that use passwords tend to externalize usernames and passwords into property and extensible markup language files. No application should actually contain plain text passwords in the source code itself. Externalizing credentials into property files is a software development best practice, but doing so has the unintended consequence of making it easier for a ne'er-do-well to locate important application files that contain credentials for accessing important systems and services.
Masking plain text passwords
One approach developers sometimes use is to MD5-encode passwords and place the encoded text into a configuration file. When the running application needs to authenticate, the encoded text is consumed, and the password is MD5-decoded by the application. The program then passes the plain text password to the resource in question at runtime. Of course, such an approach isn't foolproof. "The problem is: If you have access to the code, you can reverse the encoding," said Sal Pece, a software architect at Leone Consulting. "If you're able to get into the system and look at the configuration file, you'll probably have access to the entire code base as well."
Given the importance of maintaining a secure Java code base, most tools and frameworks provide some type of mechanism for scrambling plain text. For example, WebSphere allows developers to scramble their passwords using XOR encoding. So long as the text in the property file is prefaced with the decoration {XOR}, WebSphere will decrypt the scrambled text on the fly. But it should be noted that {XOR} is an encoding, not a hash, which means it can be reversed. "WebSphere's XOR feature is useful, but you need to be aware of the fact that there are tools online that can decrpyt it," said Maurice Yu, president of Nth Tier Solutions. "You just paste it in, and you can see the plain text."
Nevertheless, the goal of programmatic MD5 encoding or using XOR algorithms is to make it harder for someone to gain access to secure Java resources, not to make it impossible. As IBM Knowledge Center states, "Password encoding deters the casual observation of passwords in server configuration and property files."
Secure Java resources
If a hacker can get into the system, there is a much bigger problem than plain text passwords.
Sal PeceSoftware architect, Leone Consulting
Of course, the best way to avoid plain text passwords from being accessed by crafty hackers is simply to not include passwords in the secure Java code base. Many resources that are accessed at runtime can have credentials provided at configuration time, and the application server or microservices engine manages the security. For example, when creating a DataSource on Liferay, the username and password are provided at creation time and managed by the server. Runtime services accessing the resource pass their runtime credentials or security tokens to the resource, and the server grants access according to predefined access rights. The role of the developer and the use of plain text passwords written somewhere on the file system are completely removed from the scenario.
Another way to completely eliminate the use of plain text passwords in a secure Java code base is to use some type of password service. WebSphere provides a service called Credential Vault. At runtime, server-side resources can interact with the vault in order to obtain passwords that might be required to authenticate against external services. The server manages the maintenance of the credential, not the developer.
Plain text password pragmatism
The fact of the matter is: If some nefarious entity has enough access to your server-side resources that they can read all of your property files, then there's likely a variety of ways they can damage your system that don't involve passwords at all. "If a hacker can get into the system, there is a much bigger problem than plain text passwords," Pece said. "They can do more damage to the system in other ways, as opposed to wasting their time decrypting masked data."
But intruders will succeed from time to time, and when that happens, organizations always need a finger to point. If they find a plain text password in the code base, the finger gets pointed at the developer. Encoding a password or using the Credential Vault won't make an enterprise system impenetrable, but it will keep the software developer out of the line of fire when a security attack succeeds and an intrusion into the system occurs.
