2

I am making an Android app that needs to be very secure. For authentication to the server, it will use 2-factor authentication that includes:

  • username/password
  • sms verification

I can't use client certificates(with private keys), as in my case it wouldn't be practical.

Password will be stored securely on a server(probably hash and salt). But, I am having trouble figuring out the best way for password to be inputed on Android app which will be used as a client.

I am currently considering 2 options:

  • Ask user for password every time he uses the service
  • Save the password to phone DB and reuse it every time a user uses the service

The first option is good because the password is never stored on the phone(except temporary in RAM), but the password can be stolen if a device is compromised by a keylogger.

I read about ways to install a keylogger to an Android device, and I found out that the most common way is to make the victim install a custom keyboard that will be used for all apps.

This is explained by D.W. here: Keyloggers on Smartphones?

The second option is immune to keyloggers(except the first time user enters a password), but it has the risk of some malware dumping the database. I haven't found that much info about SQLite security on Android.

Also, the second option bears increased risk if someone gains physical access to the device. However, this risk can be lessend by using some kind of a pin code to protect the access to the app.

And the second factor of authentication(SMS in my case) can also be compromised, either by malware on the phone or by intercepting the SMS at the provider.

So, my question is: Is there a known way to dump a database of an app on an un-rooted android device, and what is the likelihood of that happening?

  • if you can store a password in the db, why not a client cert? – schroeder Mar 20 '17 at 14:28
  • because the issuance of the client certs would be complicated in my case. the app is intended for mass usage, by ordinary people. So it's easier for them to get the username and password. Also, if I send the certs by mail and they are stored in phone memory, aren't they exposed to the same kind of vulnerability the stored password is? It would be great if I can issue them a secure element like smart micro sd, but newer devices doesn't support micro SD anymore. – user3362334 Mar 20 '17 at 14:37
  • I was thinking that you could upload the cert upon first successful login - no user interaction required – schroeder Mar 20 '17 at 14:40
  • that's better idea than sending it by mail, but still leaves the possibility of it being compromised if a phone SQLite database is compromised. I am trying to find out are there known ways to do that if a user installs some malware on an unrooted phone. – user3362334 Mar 20 '17 at 14:46
  • yep, but at least the account password is protected, someone would have to get the device and the db and use the app to log in (but then they would have access to log in anyway) – schroeder Mar 20 '17 at 14:50
3

There's quite a bit to unpack with this question, and I will do my best to answer the question noting that I am not an Android developer.

For starters, the essence of Two Factor Authentication in the traditional form, is something you have and something you know. If you allow storage of a password in the device you are more-or-less mitigating any security benefit you would have by implementing 2FA as simply possessing the device could lead to compromise. With that said, in my opinion, you should not provide the ability to store the password in the device.

Password will be stored securely on a server(probably hash and salt)

If you want your application to be secure then you will definitely randomly salt and hash.

It may also be worth noting that NIST has recommended against using SMS for two-factor authentication. so perhaps you'd want to look into something like Google Authenticator.

I can't say whether or not SQLite databases can be dumped on un-rooted phones, but given the ubiquity of Android malware I would operate under the assumption that the phone could be compromised by the unintended installation of a malicious app.

  • Thanks for the article. I didn't consider TOTP and HOTP. I'll look more into how Google Authenticator works – user3362334 Mar 20 '17 at 14:56
  • Still, the key used for calculating HMAC is stored on the phone and can be compromised in the same way the stored password can be(that was my question actually, can it). And that key can be used to generate the OTP. On the other hand SMS, although having other vulnerabilities, doesn't store any permanent data on the phone that can be used(the sms verification code changes for every request and has a short timeout) , so I'm still not sure what is more secure, but the fact google uses that kind of authentication certainly means something – user3362334 Mar 20 '17 at 15:10
  • @user3362334 It looks to me as though you've thought thoroughly about the risk / benefit of using SMS and if you think it works for you then go ahead. There are still plenty of orgs using it and one could easily argue that 2FA w/ SMS is better than no 2FA. – DKNUCKLES Mar 20 '17 at 15:13
1

It is just my opinion, but you should not try to re-invent a square wheel when round ones are just around. As an old Unix user, I think that a good application should do one single thing and do the best at it, instead of trying to do everything including bringing a coffee.

Assuming that your application is not a password vault, you should not even considere to provide any password management feature: if one of your users wants his password to be stored somewhere in order that he does not have to type it on each and every connection, just let him use his favourite password manager. The way, he will decide whether he preferes a local storage, a cloud storage, or no storage at all, and the problem of dealing with keyloggers will be for the password manager developper - the question should be already addressed by any correct password manager...

IMHO, you should only document how to use some well known password managers like the excellent Keypass, 1Password, or Lastpass in your app, and just concentrate your efforts on your own features.

0

A better option is one that's not one of the two you're considering: an access token-based scheme like OAuth. This has the effect of remembering the user, but they can revoke a specific token without changing the entire account. This is useful if they lose a device, for instance. You can also make tokens expire every so often, which prevents a stolen token from giving the permanent access a stolen password would provide.

Google provides a set of tutorials on how to handle account authentication on Android. You should probably read over that, or at least research more into AccountManager.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.