I have 'secured' the communication between my android application and a tls server providing a financial transaction service, currently in development.
The security credentials are stored in a BKS keystore included in the Android apk. The password to the keystore is visible in plain text in the application source:
keyStore.load(is, "passwd".toCharArray());
I am concerned that if someone was to reverse engineer the app, they would be able to impersonate another user and compromise the security of the service.
I was wondering whether there is a fault in my implementation, if anyone else has this concern, and what the best method of securing against this possibility is.
Whenever you store security data on the client it can be compromised by reverse engineering. You may try to obscure it in the code but determined hacker will figure it anyway. So the only way to make it more secure is not to have the password openly in the code. May be you can just ask user for some pin code at the start of the application and use it to decrypt the password?
Are credentials stored in your app unique per user, i.e. every user gets it own apk with unique credentials? If you only have one apk with same credentials then this is as good as no security. Even worse, it gives false feeling of security.
You (your employer) should really hire a security expert to design your system from security point of view.
Here's what I'd do:
- App comes without security credentials.
- Every user is generated security credentials on server.
- Every user gets secret activation code which is generated in secure environment and delivered via alternative channel. Preferably via snail mail. Activation codes are time-limited and can be used only one time.
- On first use user types into app the activation code which enables a one-time download of credentials over a secure (https) channel.
- User provides password to encrypt the credentials while stored on device.
- Every time the app is used user must provide this paswword. If app is not used for some time the app must timeout the session and ask for password again when user wants access.
But don't take my word for granted. You still need a security expert if there are financial transactions involved.
I believe that Diffie-Hellman Key Exchange is what I was looking for. I'd rather not have to re-implement my own version of DH using a complicated process which involves the user.
currently programming for a Processing company-
their are a set of rules and regulations for a transaction application -OR- a POS APP(Point Of Sale application)
the rules are listed online as PCI validation, a certain amount of security has to be issued or it will be a law suit from Visa,inc or Many other Company's.
about your Question, it doesn't follow PCI compliance as that is a security issue.
please read the PCI compliance so that their is a complete understanding of Security, its not good to compromise Cardholder Data.
:)