Where to store hashes, salts, keys in Desktop Applications
I am trying to figure out where or how i should store application secrets and keys inside a desktop application.
For example a facebook app key or dropbox key and secret.
So I’ve read that i should hash, salt, encrypt etc etc these values. This is to prevent someone from reverse engineering my code and seeing the keys.
The is all good and well, but with all these methods, i’m just storing a salt or hash value somewhere instead of the key itself, in the end. Surely if a hacker can get to the salt/hash and possibly the source code, they will be able to decrypt the encrypted key and get my password/key/secret anyway?
One option I’ve read about that seems the most secure is to not store this value in the desktop app at all, but to call a web service to obtain the key (probably encrypted).
But my question is, even in this case, a decent hacker will surely just do a memory dump or something to see what the value returned from the web service is, and then we’re back at square 1.
The next best alternative seems to be obscurity.
Am I missing something completely?
On a side note, what use will a facebook/twitter/dropbox/etc key/secret be to a hacker anyway?
Surely they would still need a user’s credentials or access token to be able to use it anyway?
Any advice or suggestions will be appreciated.
- Port iPhone application to Android
- From where can I change refresh rate for app already in App Store?
- Cordova: Is it possible to have different app IDs for android and ios platforms?
- How do you store a file locally using Apache Cordova 3.4.0
- Phonegap - automatically including correct cordova
- Callback for Android refreshCurrentAccessTokenAsync in Facebook Android SDK 4.1+
Solutions Collect From Internet About “Where to store hashes, salts, keys in Desktop Applications”
For each user account generate a new access token for the application when they successfully log into your service. Your login service should be designed much like a login for a website:
- The API should only allow a set number (say 5) bad login attempts that reports back to the desktop client that the username/password do not match.
- The API should return a token affiliated with only that user when the user successfully logs in.
- Use SSL and a localized hashing method to pass user passwords to your API
This auth token provided by your API will only work for the individual account and as such should only allow the user to perform operations to their individual account. So for instance, if a user wants to perform an operation they must be able to provide a valid auth token in order to complete the action. Using this method attackers will still be able to obtain an auth key, but that auth key will only be able to perform operations for the account in which it is generated. It will not be able to perform operations on anyone else account. The idea here is to let them mess with data but to keep the bad activity compartmentalized to one account.
From there, if you do have generic API calls (say an image search) that accesses data from multiple accounts make sure that you are never returning or allowing for any account to access all the data in your system outright. Provide only a limited number of records. In this case the system is still performing its job, but at no point allows all the records in your system to be accessed.
I typically implement a service like this:
- User logs in and gets an auth token. I store said auth token in a database associated with that user.
- User calls web service with auth token. I lookup user account by the transmitted auth token and User ID (two forms of authentication) and use the discovered user account to perform all operations. I don’t just assume the User ID is correct, it has to be the one the auth token authenticated against.
- If a user needs to perform a delicate operation like reset a password, my app opens a browser window or browser task in the app where the user can request and administer a reset. I can more-easily secure a web application than one on an unknown client.
Using these methods you should be able to make a fully operational desktop application. There are outliers to this functionality, if you have any post them up in the comments and we can dive further into the problem and see if this solution can still work for you.
- Use User-Defined build settings in custom .plist file
- iOS Swift and localizedStringWithFormat
- Which IDE for Phonegap? Is Eclipse enough?
- Force UITableView to Scroll to Tops of Cells
- iPhone Simulator location
- How can I create a tab view programatically using Objective-C
- NSTableView with Checkbox Cell
- Structs that refer to each other in Swift 3
- iOS – MKMapView place annotation by using address instead of lat / long
- -: index 4294967295 beyond bounds for empty array with arc4random
- Printed double value differs from originally set value
- iPhone Interface Orientation on iOS8
- Twitter / Fabric login button only working once
- XCode 4 Relative #include paths in search?
- SEGV_ACCERR calling removeObserver:self] in dealloc