CODEWITHSUNDEEP
javaxamarinkeystoreandroid-keystore
Nick
Nick

Reputation: 1025

Xamarin KeyStore PasswordProtection field

I'm utilising the JAVA KeyStore class to store my users OAUTH tokens for things like Dropbox.

It's working as it is, but I'm concerned about the security of it as I know very little about how, or where it is stored.

http://www.howtobuildsoftware.com/index.php/how-do/ZPR/c-android-xamarin-monodroid-sqlcipher-correct-way-to-store-encryption-key-for-sqlcipher-database

I am basing my code off of the sample above, one thing that is not provided is why the Password field is null.

So my question is, should this be null? Or should it contain a password that is unique to my application, if the latter, where would I protect my apps password, as I'm in a bit of a chicken and an egg scenario here.

Nick.

Upvotes: 1

Views: 222

Answers (1)

SushiHangover
SushiHangover

Reputation: 74174

one thing that is not provided is why the Password field is null.

The issue in that implementation becomes what "password" should be used.

I'm in a bit of a chicken and an egg scenario here.

If a password was hardcoded within the application you might as well use null (IMHO... but I've worked with security researchers and have seen their toolkits and a hardcoded password supplied to a method call is less than 2 minutes of work for them to crack, so I would imagine a hacker can have it in even less time 😉), same as if the "password" was retrieved dynamically from a Web API over a non-secure channel.

Note: It is not that I am saying using a Null/blank password is OK, I am NOT, continue reading.

Prompting the user to input a password (in the form of a swipe pattern, passphrase, pin, etc..) before each keystore usage would make that implementation way "more secure", but at what cost of app|user usability, only you and your users can that determine that for the app's use-case. Personally I like it when my banking app prompts me for a pin and verifies that access via an SMS and another pin to entry, but that might just only be me. 😂

FYI: Being able to nick' your user's OAUTH tokens for multiple sites via just one app and password would be quite enticing for most hackers and researchers.

It's working as it is, but I'm concerned about the security

And you should be. 😜

That implementation you are referring to, IMHO, is very weak. At a minimum, it should be checking and using Android Keystone provider (AndroidKeyStore) if the app is running on at least API level 18. If your app only supports 18+ (or is running on a 18+ device), you should NOT be maintaining your own keystore file (again IMHO... but I can not imagine a security researcher disagreeing, but would love to hear their argument if they think you should).

Using the keystore provider removes you and your app from creating/maintaining/securing that keystore file as the OS does it and it uses the user's token/password/pin/lock-pattern/etc... to secure the actual filestore itself. No more chicken-egg problem.

Of course this does not cover your app checking for rooted device execution, malicious app installs, current security exploits tests, non-patched and/or missing security patches, etc... but at least it is a start 😎. (I've worked in some really secure devops environments).

Also that implementation is not checking for secure hardware; ie. KeyInfo.IsInsideSecurityHardware, KeyInfo.IsUserAuthenticationRequirementEnforcedBySecureHardware, etc....

Google has some good keystore training material that covers subjects like the keystore provider:

https://developer.android.com/training/articles/keystore#java

Upvotes: 2

Related Questions