In developing an Android application that will store certain user date into a sqlite database, how should I handle a user password securely? How can I encrypt the password so that it does not appear "in the clear" in the database, but so I can decrypt it in the application when needed.
Storing user credentials in a database presents many security challenges. You may want to consider an alternative (e.g. using OAuth 2.0 Authentication). We don't need yet another Android app with security vulnerabilities. Here is a ref for OAuth 2.0 Authentication from Google.
While one alternative that many folks do use is to "hash" the username and password using an algorithm like SHA-1 (MD5 has some vulnerabilities, though it is also used often)
The best approach would be to store SHA-2 (or some other type of hash) of the password, and then compare those hashes instead of the actual decrypted passwords.
Storing passwords is a bad practice and is not secure even if they are encrypted. Remember, everything can be broken. The best you could do is to make things more difficult for the hacker.
Related
I am trying to understanding how the authentication of fb happens on mobile devices(ios/android)?
only for the first time when i installed the fb app, i entered the username/pwd. Thats it. from next time onwards, it will auto authenticate itself.
1) Does the fb mobile app stores the username/pwd on the device in any file?
2) will it use oauth or similar token mechanism? if so, where does the token stored on the device.
I guess, my question is, in which memory/path/filename it is stored, so that it is secured and cannot be accessed by other apps/root users.
Thanks much
That's a good question.
It's dangerous to store a user's password in a standard local directory on a device, for the obvious reason that if the phone is compromised a hacker may have access to a password that is likely shared between accounts (do you have a different password for every service you use?).
However, storing a username to the device's default storage is not-so-problematic, and that is generally the method of choice. For iOS this would be NSUserDefaults.
Now, in the case of passwords and tokens (which are certainly necessary and FB would not cut corners on having token-based auth), both being secure contents that ought to be protected, they are generally stored in some sort of encrypted keychain. In the case of iOS, 256-bit encryption by virtue of Keychain Services.
Therefore, when you build an application with auto-login you retrieve the password and token from the keychain on load. However, if the device were to be lost and end up in the wrong hands all of this data would be encrypted and inaccessible.
Of course, let's not pretend this method is fool-proof: http://arstechnica.com/security/2015/06/serious-os-x-and-ios-flaws-let-hackers-steal-keychain-1password-contents/.
EDIT: Although my background is iOS, I am aware that Android uses Keystore as their alternative.
https://developer.android.com/training/articles/keystore.html
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.
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 haven't been able to find a way to open a password-protected SQLite database on Android. Since the device can easily be rooted, I am thinking of password protecting the database file. However, I am not having much luck finding anything built into the Android platform.
I don't think that Android framework supports password protection on databases. Your best bet is to encrypt your data. See SO question: Android Sqlite Password Encryption
You can encrypt SQLiteDatabases. Android does not support full-database encryption so you'd have to implement that yourself if you want to.
If you want to go down the encryption route, you're much better off just encrypting the sensitive information yourself and storing it in a database field, as per Morrison's answer.
All that said -- where are you putting the password for the encryption function? You'll probably need it somewhere in your application! In which case someone can just disassemble your code and then find the password, and decrypt the info (although it will be a bit more work).
Unless you're hashing info (one-way) then without hardware encryption on a device (and even that has flaws) you cannot store anything on the device perfectly securely -- you're always going to need to decrypt the info some time and for that the password has to be on the device somewhere.
If you want really robust security then store sensitive information on a server (preferably in a really secure location), not the device, and only communicate between the device and server over encrypted channels (HTTPS). You'll also need to authenticate the device in a secure manner. But to do that you need to store some sensitive information ON the device in order to authenticate the device with the server, unless you force the user to enter a password every time (recommended if security is a must).
If the information is stored on a server you can't necessarily prevent someone who shouldn't gaining access (by finding the password you have stored or phishing the user if it's stored in their head), but you can revoke access to the information.
I'm creating a app to store encrypted data.
In this question, the OP si advised to store user's credential in clear.
But what if I'd like to store an encrypted password created with SecretKeySpec (the one used to encrypt data)? From my understanding the secret key is itself encrypted.
So I can I store and retrieve it.
Note: I'm not asking how to store preferences, just if my understanding of how SecretKeySpec works and how to, sort of, serialize and retrieve the encrypted password.
EDIT: Sorry, I forgot to specify it needs to be compatible with API level 4.
Straight from the developer website.
Be Smart About Security!
It's important to understand that AccountManager is not an encryption service or a keychain. It stores account credentials just as you pass them, in plain text. On most devices, this isn't a particular concern, because it stores them in a database that is only accessible to root. But on a rooted device, the credentials would be readable by anyone with adb access to the device.
With this in mind, you shouldn't pass the user's actual password to AccountManager.addAccountExplicitly(). Instead, you should store a cryptographically secure token that would be of limited use to an attacker. If your user credentials are protecting something valuable, you should carefully consider doing something similar.
Remember: When it comes to security code, follow the "Mythbusters" rule: don't try this at home! Consult a security professional before implementing any custom account code.
Now that the security disclaimers are out of the way, it's time to get back to work. You've already implemented the meat of your custom account code; what's left is plumbing.
Wow. I really don't think storing the user's password in the clear is a serious option.
Check out AccountManager which was designed for this purpose. Although it got downvoted in the question you linked to, SampleSyncAdapter really is a good resource for an AccountManager example, and the only one I know of included with the SDK.
Edit - about javax.crypto, I think it is a lower-level API than AccountManager. From the docs:
Many servers support some notion of an
authentication token, which can be
used to authenticate a request to the
server without sending the user's
actual password. (Auth tokens are
normally created with a separate
request which does include the user's
credentials.) AccountManager can
generate auth tokens for applications,
so the application doesn't need to
handle passwords directly. Auth tokens
are normally reusable and cached by
AccountManager, but must be refreshed
periodically. It's the responsibility
of applications to invalidate auth
tokens when they stop working so the
AccountManager knows it needs to
regenerate them.
I'd hate to deal with this on the level of javax.crypto if I didn't have to.
u can simply declare both username and password as an if statement if condition matches u can start the activity in case of wrong u can simply generate a toast of wrong input.but u can not retreive password from there if u lost by any mean but yess u can create many passwords for a single user.i added this thing to my application and working well for me.