What is the best and safest way to save user credentials on device for an android app.
I was thinking of encrypting data and saving it in preferences.
Is there a way similar to iOS keychain to save passwords?
The best idea is not to save them at all. Encrypting provides very little security in this case because the app itself has to have the decryption key, so the key and data are on the same device. It will prevent only the least determined attackers. An OS level device isn't much better, as anyone with physical access can easily get around it.
The best idea is to use an access token. Get the login data once, send it to the server to login, and have them respond with an id. Use that id in future requests to identify yourself. The server should remember who is associated with each id. Preferably the server will include a timeout mechanism, where after X amount of time the id will be invalidated and the user will need to log in again. Even more secure implementations will match it to some physical id of the device as well, such as the Android device id, requiring attackers to have the device or fake both pieces of information.
The use of an access token rather than saving credentials protects the users in a few ways. First, the attacker will not know the users password in case its reused for other services (like their email). Second, it will not be enough to change their password (because a secure service will ask for the password again to change it) so while the info in the account may be compromised the user can take back the account by using their password to change their password. If the actual password is saved and lost the attacker can change the login info and lock the user out of his account permanently.
Related
In my Android app, I am getting the user information from server using a HttpURLConnection. Each user has a unique Id which may be accessed publicly.
Problem is if a third party, say, UserB has the Id of UserA, then they can abuse it by setting it inside my app (we know that how easy is to decompile Android APKs) then calling the server using my app and getting the output from server (including sensitive private information of UserA).
How can I prevent this from happening? What security tricks do you recommend?
Side note 1: I already have used encryption/decryption methods. But they are not going to stop UserB from abuse because when the UserB sets the Id of UserA, the app calls the server and then they have access to final decrypted output.
Side note 2: I have thought about Phone Number verification, but it is not operational for my app currently.
Side note 3: I cannot restrict the user to a specific device because they have to be able to use it on their different devices.
Side note 4: Libraries like Firebase, Gcm and the like are so secure. It would be a good idea to find out what ways they use to keep hackers from accessing another user's information!
Side note 5: Thanks to Gabor, I noticed that I had to mention that I cannot use a login interface unfortunately. If I could, that would be for sure a primary choice. It's the nature of my app and I can't change it!
That's actually a very good question and a holy grail of all security officers :)
What's I learned is that whatever you do, as long as you cannot protect the physical device against unauthorized access, there's always a risk. The problem is:
* On the one hand, you wish that the app will keep and store an information which authorizes the owner of the device
* On the other hand, you have to protect this information on the device, but because your app needs to be able for accessing it, also the accessing algorithm must be available on the device.
So I would say, there's no "clear" way. What you can do, is to make the cost of obtaining information (in your case) unprofitable.
You said that the user ID is "publicly available". That's ok, but it means that the UserID is not "secure information". I would say, that your users need to be authorized first, and then the server should generate a UNIQUE token, that will be used in replacement of UserID when calling next requests.
You can implement it in many ways, but I will recommend one way, that should be not complex for your users:
Let's assume that all your users are registered. During the registration, each user needs to provide his email, UserID (could be generated) and password. Note that registration could be done in the mobile app or on the web portal.
When the app is going to start for the first time, a user should provide hist UserID (or simply email) and password.
With the first call to the server, the userID and password should be sent to the server, and server generated a Token (unique for every first login so even if the user will use two or more mobile devices each one will use the new token).
With every next call to the server, only the token needs to be provided to authenticate the user/device.
Where to store that token? No matter. I would say in any private storage of the app. You can and should, of course, encrypt it, obfuscate a so one, but whatever you do, if one has access to the device, he can always copy it.
You will say now, that it's not 100% secure. That's right. So I would say if it could not be secure, we should minimize the risk of abuse.
There are also some ways how one can do that.
First of all, in case of abuse, your users should be informed about it. Having a token algorithm, the user can take and action, and simply disable stolen tokens.
In case if the device has been for instance stolen, your users can/should be able to disable tokens (devices) on the web portal (or in another instance of the app) after signing in using email/password authentication.
The only one problem is how to detect that the mobile device has been "cloned". In that case, the user is physically not aware of the abuse.
My guess here is to implement the following algorithm (auth pooling):
1. Let the mobile app send the "keep alive" message with the Token to the server at the certain time when the app is inactive (let's say user xyz#gmail.com should send keepalive always at 10:00, 12:00 and so one).
2. Let the app send the keep alive, with some frequency when the user is logged in (app is active).
3. These frequencies/schedules must be know for the server and app (and could be even public).
In case if the server detects the same token in keep alive nearly the same time, the user should be informed (by the different channel, it could email) about possible abuse.
* NOTE: this is only an idea, I never did that, and I'm also wondering what other things about it, but in my opinion, this is quite simple to implement, and gives you a good change to minimize the risk.
When a user starts using the app, they should log in using their credentials (eg. username and password). From the app's perspective, this is a roundtrip to the server to obtain a token. The token is then stored in the appropriate credential store for the platform you are using, and can be used to impersonate the user in further requests (the token can be sent with requests as for example an Authorize header, practically a bearer token). It also should have an expiry time, after which the user has to provide his credentials again.
Such a token can be a plain jwt you create, or it may come from something like a full oauth2 / openid connect implementation. If you decide to implement it yourself, be careful, it is not straightforward to get it right.
This way, you have proper authentication in place, you know who your users are in subsequent requests, and this way you can enforce access control rules on the server.
I've been reading a lot of threads and decided to to post my conclusion before going on coding. I've found a lot of interesting things (What is the most appropriate way to store user settings in Android application) and this is what I have gathered so far :
We'll suppose that https is always used.
By "remember me", I mean the following : the user will never authenticate on the app ever again because it would annoy him to authenticate even once a week.
When not using a "remember me" feature : Oauth2 is the way to go, exchange tokens are used -> nothing gets stored, most secure
When using a "remember me" feature :
Upon first Register/user/login usage of the app :
Password is hashed by server with its own "private key"/hash and returned to android.
This hashed password is then encrypted before being stored inside SharedPreferences. Given the Hashed password never expires, we now have the following caveats :
If the phone is lost/rooted, only this hash can be retrieved to access user's data on the server : user's data is compromised.
The crypting key is stored inside code which can be decompiled : : user's data is also compromised. Since attacker can uncrypt the hashed password and use it.
Conclusion :
Using a "remember me" feature, while handy for the user, makes it vulnerable.
My question (at last :) )
Is this conclusion correct ? Did I forget an obvious solution ?
I cannot find any safer solution given the constraints (no expiry, use remember me feature)
Thank you for your help !
In principle you are correct, I will add just some technical notes.
https - for higher security use certificate pinning, your .apk should contain either certificates of allowed CAs, or signature of the server certificate, or public key to compare with server certificate (this prevents from man-in-the-middle SSL attack).
On server side store passwords as "strong_hash(salted(password))". Don't ever store plaintext password, or hashed-only. Whether salt is fixed, or generated per user (mangling user name into fixed salt), or per registration (you will be unable to login from different device, which doesn't know the proper salt), that's your choice.
About login (in case the "remember me" token expires): use always challenge-response way, so client will send his challenge to server, server will send his challenge to client, then client will send strong_hash(client_challenge+server_challenge+strong_hash(salted(password))), which server can generate from the stored strong_hash(salted(password)) too, and compare that (sending back "remember me" token, stored both on server/client side in encrypted form, with meta data about date of creation, etc.). If somebody is eavesdropping the communication, the hash sent will be valid only for those challenge values, next try to login on the same user account with different challenges would make it invalid.
If the security of the app data are really vital (like mobile banking), you can beef up the bad security of "remember me" to semi-secure level by encrypting the full "remember me" token by some simple "PIN", requiring the user to enter the PIN every time he runs the app. This makes it impossible to break in by hand (5-8 wrong PINs will delete the token and block the app, requiring full login with challenge+password, or even resetting the device by other channel (phone call, or web app) on the server), and brute-forcing it programmatically can trigger some alert on server API side of suspicious rate of failures for particular user. Yet entering 4+ digit PIN is not as cumbersome as entering full password, and it's usually well accepted by users in applications with high security requirements.
Otherwise yes, "remember me" can be stolen, it's just question how easy you make it, if the device has some tamper-proof keystore unlocked by the user presence, use that one instead of shared prefs, or at least encrypt the values with some key (fixed + generated-per-device part?). But it's just piling up stones on the path, somebody enough determined and skilled can extract the token anyway, and use it on other device to mimic the original user.
I'm not sure what your question is, but I'll use this space to clarify some stuff.
Your findings are correct: "remember the password" (even hashed) locally on device is a bad idea, should not be coded by anyone and users should never use an app that does it.
In reality even on the server side passwords should not be technically possible to be unencrypted. Server side password hashing must always use a 1 way encryption.
You never ever ever ever ever store password locally. Ever! You always store an oauth key locally. Hashed would be nicely. Even better if on the server side that Oauth key is tied to some sort of device ID, meaning that Oauth con only be used with that device.
What makes you think users have to "login again" when using Oauth? The keys don't have to expire (the server might have some expiration mechanism), and even if they do, there're key exchange techinques for that.
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
I've been mostly creating smaller apps and games for Android so far, but am now creating a somewhat big app with lots of users and more sensible data than a highscore.
My normal approach was to just have a table for all users with passwords, authenticate with a simple Login Screen using a HTTP(S) call and that's it.
There's a few things I want to improve for this app though:
Secure Transmission
If I want to encrypt the user's password, where do I need to do it? On the device, before it's even sent? (In case of unsecure networks, like a public WiFi hotspot) Or better on the server, before writing it into the DB? Or should I just use SQL's encryption?
Auto Login
I want users to be able to stay logged in until the log out - how would I best do that? Not just security-wise, but also for the user experience.
My research shows me that using the AccountManager would be best to save the username and password and authenticate automatically when the app is started. Is there anything more to it, any security risks I'm missing here?
Access control
Usually, I would just expect every call made by an app to be valid, since a user can't access anything but the login screen without logging in. But how do I best authenticate a user's request to make sure that it's not an attacker? I can't just send the username/id with every request, so I probably need like a session token that I generate on each login? Or is there a better method?
Is there anything else I've forgot to think about?
I would suggest you to transfer password without encrypting it but by https. Other way would be to implement asymmetric encryption in your app and encrypt password with public key which you will receive from server.
On the server side I would hash password using some hashing algorithm with salt. And store only hash and salt. When users will log in, you can hash incoming passwords the same way and check hashes on equality.
To make auto login, you need to sign all requests from authorized users with a token. Token you will receive from the server after successful login. This token could be stored in Keystore, or special storage which is accessible only for this application.
Signing could be implemented by attaching to request additional parameter with checksum from all request parameters and token.
Additionally I would suggest you to think about unauthorized clone apps, which could pretend to be your app and call your server side API.
If I want to store the username and password to be used inside an Android application, what is the best way to do it? Is it through the preferences screen (but what if the user misses this?), or pop up a dialog box and ask the user for the credentials? If so, I do have to maintain state for the application. How would I do this?
Most Android and iPhone apps I have seen use an initial screen or dialog box to ask for credentials. I think it is cumbersome for the user to have to re-enter their name/password often, so storing that info makes sense from a usability perspective.
The advice from the (Android dev guide) is:
In general, we recommend minimizing the frequency of asking for user
credentials -- to make phishing attacks more conspicuous, and less
likely to be successful. Instead use an authorization token and
refresh it.
Where possible, username and password should not be stored on the
device. Instead, perform initial authentication using the username and
password supplied by the user, and then use a short-lived,
service-specific authorization token.
Using the AccountManger is the best option for storing credentials. The SampleSyncAdapter provides an example of how to use it.
If this is not an option to you for some reason, you can fall back to persisting credentials using the Preferences mechanism. Other applications won't be able to access your preferences, so the user's information is not easily exposed.
You should use the Android AccountManager. It's purpose-built for this scenario. It's a little bit cumbersome but one of the things it does is invalidate the local credentials if the SIM card changes, so if somebody swipes your phone and throws a new SIM in it, your credentials won't be compromised.
This also gives the user a quick and easy way to access (and potentially delete) the stored credentials for any account they have on the device, all from one place.
SampleSyncAdapter (like #Miguel mentioned) is an example that makes use of stored account credentials.
I think the best way to secure your credential is to first think of storing the Password with encryption in the account.db file which couldn't be easily available in non rooted devices and in case of rooted device the hacker must need the key to decrypt it.
Other option is do all your authentication like the way Gmail is doing. after the first authentication with the Gmail server . you got the Auth Token that would be use in case of your password . that token would be store in plain text.this token could be false in case you change the password from Server.
the last option I'd recommend you to enable 2-Factor Authentication & create Device Specific Password for your device. After losing device, all you need is to disable that device.
Take a look at What is the most appropriate way to store user settings in Android application if you're concerned about storing passwords as clear text in SharedPreferences.
You can also look at the SampleSyncAdapter sample from the SDK. It may help you.
Take a look at this this post from android-developers, that might help increasing the security on the stored data in your Android app.
Using Cryptography to Store Credentials Safely
With the new (Android 6.0) fingerprint hardware and API you can do it as in this github sample application.
These are ranked in order of difficulty to break your hidden info.
Store in cleartext
Store encrypted using a symmetric key
Using the Android Keystore
Store encrypted using asymmetric keys
source: Where is the best place to store a password in your Android app
The Keystore itself is encrypted using the user’s own lockscreen pin/password, hence, when the device screen is locked the Keystore is unavailable. Keep this in mind if you have a background service that could need to access your application secrets.
source: Simple use the Android Keystore to store passwords and other sensitive information
The info at http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html is a fairly pragmatic, but "uses-hidden-android-apis" based approach. It's something to consider when you really can't get around storing credentials/passwords locally on the device.
I've also created a cleaned up gist of that idea at https://gist.github.com/kbsriram/5503519 which might be helpful.