Android Question Encryption the right way...?

wimpie3

Well-Known Member
Licensed User
Longtime User
I am sending out an encrypted string to my server. The secret key is obfuscated thanks to B4A's obfuscation compilation. Furthermore, the data is transferred through a secure https connection.

Is this the correct way to send sensitive data over to my server? Or is there something else I should do?

What are the chances that B4A's obfuscation protocol gets hacked and my secret key gets exposed?
 

nwhitfield

Active Member
Licensed User
Longtime User
One way to add an extra level of security would be a type of key exchange.

In one of my apps, though we don't encrypt the payload (though it is over https), this is how it works:

1. The app has a key in it, which is common to all installations; this is known as the app key
2. On first run, the app generates a unique ID from the device info, and sends that, plus the app key to the server
3. The user authorises the app on the web site, and the app can then retrieve a unique user authorisation key for that device
4. When the app wants a session with the server, it transmits the user key and the app key
5. The server returns a session key, which is used to authorise all subsequent transactions until logout or
6. If the IP address changes, or a timeout occurs, the session key is invalidated and the app has to go back to step 4

So, yes, someone could grab the app key, even after obfuscation, and use that to write something that talks to the server

However, on the server side, we have mechanisms to revoke the app key too, as well as the individual user/device keys.

That gives us the flexibility to, for instance, disable any app that breaches our terms and conditions, as well as allowing a user to revoke access via a device that they've lost.

If you wanted to beef up your security, I'd suggest that you do something similar to this, where the login process returns a new secret key that will be used for that specific session.

You might include some error response that the app can use to indicate to the user that its request has been denied, and an update must be downloaded, which would contain a new initial key. And it may be a good idea to include some form of device id as well, so you can block devices, as well as app versions.

How complicated you make it all depends rather on how likely you think it is that people might want to do this - if talking to your server gives a way to access people's money, or to send a spam message to thousands of people, it might be appealing. If it allows them to fake the location of a bicycle, perhaps less so.
 
Upvote 0

wimpie3

Well-Known Member
Licensed User
Longtime User
I'd love to see a "how to..." or a "best practices..." on this subject, Erel. I think a lot of developers rely on the obfuscation of the private key for their secure internet traffic (which is apparently not such a good idea).
 
Upvote 0
Cookies are required to use this site. You must accept them to continue using the site. Learn more…