1

I've recently started to learn about security in Android apps and wanted to implement certificate-pinning. Found some useful information by googling around but I stumbled upon storing the keystore password which contains the server certificate.

As I can't trust the Android filesystem to keep my keystore password secret, mainly because any rooted user would be able to dig it out eventually, I'm starting to wonder whether if it is really needed to securily store this keystore password or not, because this keystore will only contain my server's SSL certificate, which is intended to be public.

I can't think about any malicious attack if somebody could decompile my APK and see the keystore password, as the attacker wouldn't be able to modify any of the app's code and thus change, for example, the targeted server IP or even modify the keystore switching my certificate with some other malicious cert which, in combination with the changes the attacker could made on the targeted IP, would make the app work targeting any malicious server (man-in-the-middle-attack).

I found a quite good example of certificate pinning in Android here on github, but sadly the author doesn't bother with storing the passsword securely, as it is hardcoded at the MainActivity.

So my summed up question would be: Is it really needed to protect a keystore password if that keystore only has inside an intended public SSL server certificate?

From the research I did, I found that on this question the OP addresses the posibility of passing null as the password on the Android code. Maybe I could go with this and store the keystore password at my server instead of packing it up inside the Android app.

Also during my googling I found quite useful articles that might be interesting for anybody looking into this question in the future:

Progress update - Passing null as the keystore password (as I mentioned above as one of the options) if you've set one when generating it will result in keystore bypass: requests get sent anyway and custom keystore does nothing. No exception is thrown or anything, it just works as if you didn't set any custom keystore.

 KeyStore trustStore = KeyStore.getInstance("BKS");
 trustStore.load(keyStoreInputStreamFromResources, null);
Community
  • 1
  • 1
JorgeGRC
  • 1,032
  • 2
  • 18
  • 37
  • Since the public certificate is public, I see no value in keeping it password-protected. – CommonsWare May 10 '17 at 11:28
  • @CommonsWare `openssl` tools require you to password protect keystores, that's why I'm concerned about this, I'm not sure if harcoding this simple password which protects the keystore (as it doesn't need to be secret at all) is a bad practise. Need to get past a security audit and not sure if they will be OK with that... – JorgeGRC May 17 '17 at 07:42
  • Then perhaps you should discuss this with the security auditors. – CommonsWare May 17 '17 at 10:51
  • This is something I've been wondering about also. If `null` doesn't work, maybe setting a throw-away password, i.e., one that is not used for any other purpose, and that doesn't really need to be protected, might be ok with the security auditors? I'm curious, what solution you actually chose that was ok with the security auditors? – auspicious99 Nov 21 '21 at 10:54
  • 1
    @auspicious99 I should probably close this as I'm no longer working in that company where I implemented that. I think I just went with hardcoding a dummy password like `notsecret` or something like that for clarity. At the time I didn't hear anything back from the auditors :) so I guess all good... good luck! – JorgeGRC Nov 22 '21 at 11:21
  • Haha, great to hear that. Thanks for getting back to me, and best wishes in your present company! – auspicious99 Nov 22 '21 at 11:58

0 Answers0