Gareth D.
—According to the official Java Cryptography Architecture, you should not use String
to collect passwords. The guide instead recommends using char[]
as an alternative to safely and securely store passwords. Below we consider the reasons why.
While String
may seem like the logical data type to store passwords, a few issues makes it unsuitable. For starters, strings in Java are immutable. This means that once created, String
cannot be modified. This is for multiple reasons, including thread safety, class loading, and security. Once created, all strings are added to the string pool, a Java heap where all string literals are stored. These strings remain available in memory until garbage collection takes place. Since they cannot be overwritten, it means our passwords stay in memory, vulnerable to being read by attackers.
A character array, char[]
, on the other hand, can easily be overwritten or zeroed out after use. It is actually used by core Java methods such as javax.swing.JPasswordField
and javax.crypto.spec.PBEKeySpec
. Using char[]
adds an extra layer of security as our passwords and other sensitive data are no longer held in memory any longer than they should be.
Another reason for not using the String
data type for passwords is that our application can easily and accidentally log it. This could be logging to the console, a log file, or a remote logging server. This is a huge risk as the user’s password will be logged in plain text and vulnerable in the case of a breach. This has occurred with industry leaders like Twitter and GitHub.
Storing passwords as a char[]
helps prevent accidental logging. When a character array is logged, it prints out the object’s memory location by default instead of the array’s contents, whereas String
prints out the string’s contents. The following example shows this:
public static void main(String[] args) { String password = "Password"; char[] securePassword = password.toCharArray(); System.out.println("String: " + password); System.out.println("Char array: " + securePassword); }
The output is as follows:
String: Password Char array: [C@568db2f2
It’s important to note that the use of char[]
for passwords is not a substitute for hashing or encryption of passwords, as it only increases security at the application level. Passwords should still be hashed for security purposes when being stored.
Tasty treats for web developers brought to you by Sentry. Get tips and tricks from Wes Bos and Scott Tolinski.
SEE EPISODESConsidered “not bad” by 4 million developers and more than 100,000 organizations worldwide, Sentry provides code-level observability to many of the world’s best-known companies like Disney, Peloton, Cloudflare, Eventbrite, Slack, Supercell, and Rockstar Games. Each month we process billions of exceptions from the most popular products on the internet.
Here’s a quick look at how Sentry handles your personal information (PII).
×We collect PII about people browsing our website, users of the Sentry service, prospective customers, and people who otherwise interact with us.
What if my PII is included in data sent to Sentry by a Sentry customer (e.g., someone using Sentry to monitor their app)? In this case you have to contact the Sentry customer (e.g., the maker of the app). We do not control the data that is sent to us through the Sentry service for the purposes of application monitoring.
Am I included?We may disclose your PII to the following type of recipients:
You may have the following rights related to your PII:
If you have any questions or concerns about your privacy at Sentry, please email us at compliance@sentry.io.
If you are a California resident, see our Supplemental notice.