How to remove plain text passwords for a secure Java codebase

One of the most common issues identified by static code analysis tools is the presence of clear text passwords written directly to configuration files. It’s usually a standard requirement not to have clear text passwords anywhere in the code base, but their presence is a reality in just about any software development project. All of this begs the question: How do you get plain text passwords from a secure Java codebase?

Most software development infrastructures that use passwords tend to outsource usernames and passwords to extensible markup language and property files. No application should contain plain text passwords in the source code itself. Outsourcing credentials in property files is good software development practice, but the unintended consequence of making it easier for an intruder to locate important application files that contain credentials to access important systems and services.

Hide plain text passwords

An approach sometimes used by developers is to encode passwords in MD5 and place the encoded text in a configuration file. When the running application needs to authenticate, the coded the text is consumed and the password is MD5-decoded by the application. The program then passes the password in plain text to the resource in question at runtime. Of course, such an approach is not foolproof. “The problem is this: if you have access to the code, you can reverse the encoding,” said Sal Pece, software architect at Leone Consulting. “If you can get into the system and see the configuration file, you will 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 the plain text. For example, WebSphere allows developers to scramble their passwords using XOR encryption. As long as the text in the properties file is preceded by the {XOR} decoration, 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 should be aware that there are online tools that can decrypt it,” said Maurice Yu, president of Nth Tier Solutions. “You just have to paste it and you can see the plain text. “

However, the goal of programmatically MD5 encoding or using XOR algorithms is to make it more difficult for someone to access secure Java resources, not to make it impossible. As the IBM Knowledge Center reports, “Password encryption prevents the occasional observation of passwords in server configuration and properties files.”

Secure Java resources

If a hacker can break into the system, there is a much bigger problem than plain text passwords.

Sal PeceSoftware architect, Leone Consulting

Of course, the best way to prevent plain text passwords from being viewed by crafty hackers is to simply not include the passwords in the secure Java codebase. Many resources that are accessible at run time can have credentials provided at setup time, and the application server or microservices engine manages security. For example, when creating a data source on Liferay, the username and password are provided at creation time and managed by the server. Runtime services that access the resource pass their runtime credentials or security tokens to the resource, and the server grants access based on predefined access rights. The role of the developer and the use of clear 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 run time, server-side resources can interact with the vault to obtain passwords that may be needed to authenticate with external services. The server manages credential maintenance, not the developer.

The pragmatism of plain text passwords

The point is this: If a malicious entity has enough access to your server-side resources to be able to read all of your property files, there are likely several ways to damage your system that do not 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 further damage the system in other ways, instead of wasting their time decrypting hidden data.”

But intruders do succeed every now and then, and when it does, organizations always need a finger to point the finger at. If they find a plain text password in the code base, the developer is singled out. Encrypting a password or using Credential Vault will not make an enterprise system impenetrable, but it will keep the software developer out of the line of sight when a security attack is successful and a intrusion into the system occurs.

Comments are closed.