My mobile app has users, so after someone log in, I send back the user id to be used for future requests (GET and POST HTTP web service calls to manage user data), and I store it in an sqlite table called user_settings after encrypting it using jbcrypt along with the salt. is this a safe way to do it?
You could use sqlcipher to encrypt the database with a randomly-generated key, created on first startup, that you store in the Android Keystore System.
As #njzk2 said, there is no way to absolutely protect this data. Encrypting the database with a random, unique key, and stashing that key in the keystore, will make things much more difficult for an attacker, even with physical access to the device. In this scenario, the goal is not to keep the attacker from ever accessing the password, but slowing the attacker down enough that the user can change their password before the attacker can use it.
Related
I have an Android App where a user enters some sensitive information in the form of text. I need to store this data on a remote server, to be retrieved by that user from a different device. I want to secure this data against everyone other than that user, especially a rogue database admin - the user should be the only one capable of recovering the information.
My approach is, SALT will be generate in Android app and every sensitive data will be hashed with this SALT and will be stored for later decryption to get the actual raw data.
Is this the correct approach? or Any better approach for this?
If yes,
What if the user change the device?
How to use the same SALT in the new device as SALT cannot be saved in database?
Update: Sensitive data needs to be stored in Firebase Database.
Disclaimer
I'm not a security professional. I'm not an expert. I'm just some random developer on the internet who's done some reading in the past and took a stab at answering your question. Head over to the information security stackexchange if you want more reliable information.
A user enters sensitive information into your program. You want them to be able to recover it later, so you must save it somewhere. How to handle this?
Where to save it?
On the device if it doesn't need to be accessible from elsewhere.
On a server if the user might need to access it from a different device (or recover it).
How to secure it?
Encrypt it.
What to encrypt it with?
A standard, secure algorithm (such as AES), and a key derived from a user provided password.
But users tend to come up with poor passwords. If we're sending this to a server, and the database might be compromised, how to protect against brute force attacks?
Employ a key stretching algorithm, such as PBKDF2.
How secure is this, really?
Well if the user picks a poor password, and then your database is compromised, brute force will be relatively easy.
If the password ever leaves their device (like if you, say, reused the same password for the app to log in to your servers or something) then you're treading in dangerous waters.
I'm writing simple offline dictionary application. All data is stored on SQLite database.
If we assume that database is encrypted, app must use some kind of key, in order to have access to it. Also, we assume that this application is completely offline and does not access to any remote servers.
That means that key will be stored in apllication itself. I was trying to find out a lot of methods of hiding this key in app and all of them are flawed.
Is it even possible to hide this key implicitly in app itself?
If the app automatically displays data, it is not possible to protect that data.
Your app must store the key somewhere. Regardless of how much you try to obfuscate your code, it is still possible to decompile it (or just execute the obfuscated part, until the key comes out).
Or looking at it in a different way: hiding the key is a form of encryption. So now you need a second key to encrypt/decrypt the first key. (But with obfuscation, the 'key' is the program structure, which is less secure than a real cryptographic algorithm.)
The only way to protect the data would be to avoid storing the key by requiring the user to enter the key (as a password, or some separate token) whenever the app is to be used.
This implies that the user is trusted not to give the key away.
I'm developing an app which will connect to server webservice and exchange data. I want to include auto authentication mechanism in application. I'm not really good at security stuff, so I would like to ask you, how to do it properly. I think, that storing users password in sharedpreferences or database and comparing it with password stored in server is not a good idea, even in encrypted form. I guess that there is some better way to do it, right?
Normally the service will return a key of some sort (typically in a cookie), and you pass that key with each subsequent request. The server is responsible for keeping track of who has what key. And of course the key is very large so its unguessable.
On the server side, never store the password. You store a hash of the password, and when an incoming password comes from a login request, you hash it and compare the hashes. Better yet you should salt your hashes as well. If you aren't familiar with security I'd really suggest you use an existing library rather than writing your own.
I'm developing a video game for Android. It will be an online game, which would save user's statistics, achievement, objects, etc. in the local SQLite database.
Thinking about the security... I read that a user can edit all his/her databases saved in a rooted Android device. I would not want the user to be able to edit the database of the game.
So, what can I do? Is there any option to make the DB really secure? Password? Encryption?
Thanks
A determined attacker can get at any data on the device. If you're encrypting data on the device before putting it in the database, then you have to have keys on the device and a determined attacker can get at any keys that are stored in the devices memory or persisted.
The only way encryption would help is if neither the encryption nor the decryption happens on the untrusted device -- merely the storage. You can encrypt the sensitive data on a machine you trust, storing the encrypted bits in the database for later decrypting by a machine you trust.
You can't use a password to secure this either. Passwords stored in the device memory or persisted on the device can be read as easily as private encryption keys.
If you don't care whether the user reads data from the DB, but don't want them to be able to write data, you could have critical data signed by a trusted machine before being stored. Then if the device connects to a trusted machine, it can check the signature to verify that that critical data has not been tampered with.
EDIT:
You can't trust any computation performed on an untrusted device unless you're willing to go to fairly extraordinary lengths -- the only thing you can do is verify data routed through an untrusted system via signatures, and prevent eavesdropping by an untrusted system on data passing through it via encryption.
If there's nothing online, I'm not sure what you can do. You can make it more difficult, but I'd say its unlikely to be absolutely secure. I think what I'd do is take a snapshop of the db at a checkpoint, and send that off to the server, and (basically) check that the data hasn't been changed by a user. If the hashes don't look right, you can cripple the account (or whatever).
I wouldn't get too crazy, though, unless you have a serious game.
SQLite data encryption is possible, for more detail see this.
This may also help.
The issue I am facing is an interesting one and my knowledge of security is strong, but my understanding is weak. That is, I understand the theory, but have had little practical application in this particular regard. I have stored passwords, transmitted them using salt, verified them a hash, etc. My needs here are similar but specific.
I have one application that other external application may "hook" into via a ContentProvider URI. External applications may be developed by anyone, thus I do not have control over them. However, I want to limit some access to subscribers. To facilitate this, each "subscribed" application will have a key registered to its package name. The ContentProvider then needs to verify this key as valid.
My issue is this:
Since it is passed via URI, it is easily possible to intercept the key in transit. Additionally, my subscribers need a method by which they can store their own key without having to connect to a secure server. They cannot store the key as a literal within their app, of course, as this makes for easy vulnerability. I am trying to provide as much of a solution as possible without having to "trust" the security of these other applications.
So, how do we store a key in both my database and their external application, and allow them to send it to me for specifically verified queries? I think my issue in understanding how to do this is the aspect of persistent storage and how it affects the model. That is, with a password model, the password is typed and not typically stored.
FuzzicalLogic
Process the key in an encrypted challenge / response.
Client requests challenge value encrypted with a predetermined per application public key.
If the client then returns the correct value to the server encrypted using the client specific server's public key then the handshake was a success.
Using a per application private key / public key and something like a guid for challenge value, it would be very hard to duplicate.
and the keys never change hands except when registering the application developer initially.