29

What would be a good way to authenticate a user to a smart phone? By good, I mean that it is both secure, and user-friendly. Passwords don't seem to be the best fit because a password needs to be long to be secure, but it is hard to type a long password on a smart phone. Some thoughts I have begun to think about are biometric measures (e.g. possibly facial recognition), and / or a token. I am interested for this question in authenticating to the phone. As pointed out in the comments, my original question was too broad, so I am splitting the other portion into another question here: What is a good way to authenticate a user to websites and applications with a smart phone?

  • 4
    Are you asking about how to authenticate a user TO the phone, or authenticating VIA the phone? – schroeder Feb 10 '15 at 18:51
  • @Schroeder Actually, both, however, I am more focused on authenticating via the phone. – Jonathan Feb 10 '15 at 18:57
  • 1
    Yeah, evil Microsoft. But they're onto something with this Microsoft Account app. – E.V.I.L. Feb 10 '15 at 21:12
  • This question is extremely broad, and vague. Secure against what threat model? Please explain what schemes you have already considered and the extent to which they meet your needs. Also please clarify what you mean by authenticating: do you mean authenticating to the phone (the phone app needs to verify which human is using it), or authenticating to a remote server? If the latter, do you need to authenticate that it is a particular human, or that it is a particulate phone/device connecting to the server? Asking about all of those is too broad for one question. – D.W. Feb 11 '15 at 23:53
  • 1
    @Jonathan, authenticating to a remote server is very different from authenticating to the phone itself. They don't belong in the same question. Trying to cover all of this in one question is just too much; it's too broad. – D.W. Feb 12 '15 at 8:02
20

Look at the authentication methods for unlocking phones. On my galaxy S4, there are:

  • Swipe (no security)
  • Face Unlock (low security)
  • Face and Voice (low security)
  • Pattern (medium security)
  • PIN (medium to high)
  • Password (high)

From personal experience, the face unlock is kind of hard. You have to train it, and then you have to stick your face in the right light with nothing on it to unlock your phone. Also consider people with disabilities or injuries -- someone who has been burned in an accident will be locked out of their device! There has also been research in defeating the recognition engine with pictures, and it's pretty easy to do because anyone can see your face.

The password as you said is very hard to type. Tiny phone keyboards make capital letters very hard.

However, the two methods of authentication that I find the easiest from a user's standpoint are the PIN and the pattern. The pattern can be lifted from the screen oils (blech) so that weakens it.

A large, number only keyboard that has randomized the placement of numbers is a good compromise between usability and security. Place a minimum length on the pin (like 10) and you'll be able to have security comparable to a password.

  • 3
    @Johnathan, what if someone is in a quiet room? Or they are ill and cannot speak, or their voice changes, or XYZ happens? You have to think about all the situations that your app will be used in. It will be stronger security, but ease of access is a huge factor too. If you can implement a great system that solves these issues, awesome! Go for it, and share your work with the world. – Ohnana Feb 10 '15 at 15:48
  • 1
    Do not create "Remember me" features. That tends to leak user credentials. Yeah, i know you can encrypt it, but remember that there are reverse-engineering techniques that might reveal source-code pieces (depending on the platform), maybe giving up the encryption password and other inside nasties... In this case, i think that "the best move is not to play". – DarkLighting Feb 10 '15 at 17:00
  • 7
    Minimum pin of 10 numbers? No one will use your application. – Nit Feb 10 '15 at 21:15
  • 3
    On Android, face recognition is a convenience feature. You always have to provide an alternative unlocking mechanism. – musiKk Feb 11 '15 at 13:43
  • 3
    @user2813274 The blink test has been demonstrated to be foolable with simply waving a pencil up and down in front of the printed face. – Hagen von Eitzen Feb 11 '15 at 23:30
14

You don't mention what sort of service it's for, but as a user the least irritating auth method on phones for me is SSO. I'm already signed into Google & Facebook anyway, so typically it's just a case of pressing "Yes" and we're all done.

  • I am thinking this might actually be the best way so far to authenticate to apps / websites via a smart phone (as long as the single sign on method is secure, and that is a big assumption)! I would think this would be good to carefully incorporate into the solution (considering security aspects). – Jonathan Feb 11 '15 at 13:30
  • I think this is most likely the best Option if your user has an account in the SSO service. Then you don't have any extra effort, and you don't have any liability – Falco Feb 12 '15 at 10:08
6

If you have the user's mobile phone number (and if the user affirms during registration that this phone number can receive text messages), you can use this ability to enable 2-step authentication with SMS. Following successful authentication with a username and password, take one more step. Send the user a text message, by using the API to an SMS gateway provider such as Twilio or Plivo (it costs money, but prices for SMS gateway providers tend to be very low in the U.S.). The text message that you send them would contain a randomly-generated integer that you create for them, maybe 6 to 8 digits long. Let the user type in this integer into a form field and authenticate them with it. To make it easier for the user to type it, you can configure the form field to bring up a dialpad keyboard on their screen, containing only numbers for the buttons, like this:

<input type="text" name="smstoken" id="smstoken" pattern="[0-9]" autocomplete="off">

Once they have submitted the form with the correct integer that they received in their text message, they're fully authenticated. This form of 2-step authentication ensures that users not only know something (their correct username and password) but also have something (a random number received in realtime via text message), heightening your application's security.

Make sure that you fully advise the user beforehand that he may be charged by his mobile provider in order to receive the text message.

  • 1
    I'd add in storing a special authentication token on their computer that lasts a set amount of time. 2 weeks. If that authentication token exists, don't prompt them for a password. (This is also the design of how gmail authentication works). – Steve Sether Feb 10 '15 at 22:05
  • 1
    I think you're missing the point here. Two-factor authentication like that doesn't help when you're logging in from your phone, which is what the OP is implying. – nyuszika7h Feb 11 '15 at 14:43
  • @Steve Sether: Agreed, it might improve convenience to enable token-based authentication on future logins, while requiring 2-step authentication only when the user doesn't have a matching and unexpired token. But I didn't mention that, because I wanted to stick to answering the OP specifically. – vrtjason Feb 12 '15 at 19:26
  • @nyuszika7h: I provided my answer before the OP was split off. – vrtjason Feb 12 '15 at 19:49
  • @vrtjason: this don't help I guess if phone is stolen and someone knows the username/password – user68288 Feb 13 '15 at 15:16
4

Your best bet might be to use the standard methods as mentioned in Ohnana's answer along a strong second-factor authentication using U2F.

Yubico's YubiKey NEO allows secure TLS-channel second-factor authentication, even over NFC, if I remember the spec correctly. You're using a hardware security module, so this, combined with a strong inconvenient password would be a very strong way of verifying that the user is who they claim to be.

Even crazier would be to write a GPG smart card driver for Android which would use the OpenPGP applet in said YubiKey NEO to have a server/phone-initiated one-time challenge where the user would have to enter the key to their smart card in order to decrypt, sign, and return a challenge from the server/phone. You'd need a USB dongle, though, as there's no NFC protocol for GPG if I recall correctly.

The sky's the limit. Make sure the phone's encrypted with a strong inconvenient passphrase, and make it power down if more than 5 incorrect login attempts.

3

You could utilize some form of near field communication.

For example, write some tags that unlock the phone when the tag is tapped to the back.

Another good thing to check out is Yubikey: https://www.yubico.com/products/yubikey-hardware/yubikey-2/

1

You should also consider the specific smart phone (iOS, Android, Windows, etc.) as different phones vary in how they operate and what features they provide.

Apple has opened up access to Touch ID in iOS 8. So, for Apple devices, you can require a user to sign in the first time using their password. After they sign in the server can supply a unique key for that device. Store that key in the keychain and allow subsequent logins to be unlocked through the Touch ID API.

You do add a couple of possible security concerns that I know of.

  1. You store what is essentially the equivalent of a password on the device. Even though it is encrypted, it is still locally stored and could be decrypted. You can mitigate some concerns here by requiring the password for some operations. For sure, when changing the password; but there might be other cases.

  2. Touch ID can be hacked by obtaining the owner's fingerprints from the device itself.

Despite these, you do encourage users to use better passwords. And that should provide better security overall.

  • I'm not sure I see how this does not apply. I suggested using a password to log in to a server (the something else) initially and then Touch ID for subsequent access. In other words, using a phone to store a secure key for access to that something else. – David V Feb 10 '15 at 18:51
  • The device is not the only place you can obtain the owner's fingerprints from. – nyuszika7h Feb 11 '15 at 14:45
1

The premise of this question is a little flawed because it implies there is a "one size fits all" answer. This isn't the case. The authentication needs to fit both the application requirements and the user. Some applicaitons/devices need more protection than others. Likewise, some users need more protection than others.

I think the best approach is to allow a range of options and let the user choose the option they prefer. The disadvantage of this approach is some people will just go with the easiest, most convenient method. However, solving that problem is really about increasing user awareness. Forcing a solution along the "We know best" line is unlikely to gain much support and will frustrate some users who are able to assess their risk exposure appropriately and just find the imposed solution inconvenient or out of step with their requirements.

For authentication purposes on a general device, such as an phone, you probably need to cover the three main approaches i.e. something the user knows (e.g. password), something the user has (e.g. token, possibly hardware generated from a dongle or SMS code etc) and something the user is i.e. biometric - fingerprint, voice print, etc. However, the key would be to allow the user to select whether they just want a password/pin or a combination. My 15 year old daughter will probably only want a pin, but thats fine as all she really uses her phone for is facebook. On the other hand, I work in security, have access to sensitive data and want more protection, so I might go with biometric, password and token.

For specific applications, the approach should be similar, but can be simplified. An application has a more defined use profile. This means you can make a more accurate assessment of the security risks. If the application has little sensitive data and low 'benefit' to unauthorised individuals, then a simple pin or password may be sufficient. As the risks increase, then you need to increase the range of available authentication methods. In some cases, where the data sensitivity is above a certain threshold, you may enforce a minimum standard.

The other thing to consider is user education and solutions available to make some of this a little easier. For example, it may be appropriate to encourage the use of a password management application. This can reduce the impact/inconvenience of typing long/complex passwords on a small mobile device screen. You might have a password management app which you log into once at the beginning of a session and from that point on, whenever you go to a site/application which requires a password, the password manager fills in the details for you. Some of the better ones even provide support for 2 factor and biometric systems. Obviously there not a silver bullet, but they can address some of the inconvenience associated with authentication with only a small increase in risk, which may well be offset through the use of more random and stronger passwords etc.

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.