Hardcoded Credentials (S6437, S2053, S2068)

version: SonarQube 9.9 Datacenter Edition

I tried to understand what SonarQube can find, and can not find, in terms of hardcoded credentials, based on what I see in our real-life code, most of the time with rule findsecbugs:HARD_CODE_PASSWORD.
I spotted 3 main rules that should do the job: S6473, S2053 and S2068. From my understanding

  • S6473 attempts to find all hardcoded credentials based on the API method.
  • S2053 attempts to find hardcoded material for cryptography.
  • S2068 attempts to simply find everything that is named “password” or whatever is configured.

With my sample code S6473 is doing its job.
I have 1 suggestion: it could also try to find usages of javax.mail.PasswordAuthentication similarly to it finding java.net.PasswordAuthentication:

java.net.PasswordAuthentication authentication = new java.net.PasswordAuthentication("user", "hello1!".toCharArray()); // detected by java:S6437
javax.mail.PasswordAuthentication authentication2 =  new javax.mail.PasswordAuthentication("user","hello1!"); // not detected by java:S6437

For rule S2053 I identified something strange:

byte[] defaultSalt = "salt".getBytes();
Cipher pbeCipher = Cipher.getInstance("PBEWithMD5AndDES");
pbeCipher.init(Cipher.ENCRYPT_MODE, key, new PBEParameterSpec(defaultSalt, 20)); // detected by java:S2053

byte[] defaultSalt = { 's', 'a', 'l', 't' };
Cipher pbeCipher2 = Cipher.getInstance("PBEWithMD5AndDES");
pbeCipher2.init(Cipher.ENCRYPT_MODE, key, new PBEParameterSpec(defaultSalt, 20)); // not detected by java:S2053

The salt in the 2nd case is as hardcoded as the one in the first case, but gets not detected.

For S2068, would it make sense adding some more credentialWords to the default config ? I am thinking about:

  • mail.password (used by Java Mail)
  • javax.net.ssl.keyStorePassword (Java Keystore)
  • javax.net.ssl.trustStorePassword (Java Truststore)

I know that you can do this on your own, but these properties are very common and not that different to the already present java.naming.security.credentials.

One last thing: Is there any chance that you provide something to not only detect variable names, but also the calling of methods, like


It would make sense to be able to configure that similarly to the credentialWords of S2068. I will definitely look into creating an own rule that mixes the features of S6437 and S2068.


Hi @youngroman!

Thanks for reaching out and submitting a new piece of feedback about our products’ capabilities. We love hearing what you think about them. This really helps us always build better detection engines and rules.

I’ll try to answer all of your points. Let me know if there is anything I miss.

I am glad to hear that you find rule S6437 useful. We are putting a lot of effort into making it as relevant as possible and knowing that it brings you good value is very nice. Still, we know there is some room for improvement, and this rule’s coverage will certainly increase in the near future.

I filled a ticket on our side to add support for javax.mail.PasswordAuthentication and jakarta.mail.PasswordAuthentication. We will tackle it as part of our upcoming sprints.

I can reproduce this issue on my side. I filled a ticket so that we can investigate it and come up with a better detection logic.

We need to be very careful when adding new keywords for S2068 detection. Primarily, we need to verify the false detection rate increase every time we add a new entry. However, I think javax.net.ssl.keyStorePassword and javax.net.ssl.keyStorePassword should be relatively safe to add. We will look into this. I am in a more mixed filling regarding mail.password.

I don’t think this is something we have under our radar. This rule has not been designed to accept user configuration. While unfortunate, I don’t think we will work on that soon. But don’t be too sad. We have a lot of exciting new features coming up soon!

I hope my answer helped you. Let me know if I can do anything else.


1 Like