What is a good way to authenticate a user to a smart phone?

Question

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?

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
Yeah, evil Microsoft. But they're onto something with this [Microsoft Account app](https://play.google.com/store/apps/details?id=com.microsoft.msa.authenticator&hl=en). — 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
@D.W. The threat model would be that which faces usual smart phone users. I am mostly focused on authenticating to a remote server, but am also curious about authenticating to the phone itself. I am interested in authenticating the particular human. — Jonathan, Feb 12 '15 at 01:48
@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 08:02
@D.W. I split the question into two questions, as I see your point. Since I cannot accept two answers, I see it should probably be split into two separate questions. It would be nice if you could accept multiple answers. — Jonathan, Feb 12 '15 at 13:31

score 20 · Accepted Answer · answered Feb 10 '15 at 15:28

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.

answered Feb 10 '15 at 15:28

Ohnana

4,737
2
23
39

Excellent point about the facial recognition being defeated by a picture. I assume face + voice could be defeated by recording the voice as well, but this would probably be harder. It sounds like existing facial recognition software (at least that product) isn't as good as it needs to be for usability as well. These are some great points you mention, I wish I could give you a +2 or +3, you provided a nice list as well as their evaluations :-) – Jonathan Feb 10 '15 at 15:37
I wonder if a combination would be good (e.g. PIN and voice recognition) – Jonathan Feb 10 '15 at 15:45
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
Great point! I would imagine there is some combination that would be good, but it appears voice isn't it. – Jonathan Feb 10 '15 at 15:50
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. – Etheryte Feb 10 '15 at 21:15
What does the random placement of numbers buy you? Randomized screen smudges? – user253751 Feb 11 '15 at 04:51
Pin can be made more secure by limiting the number of tries before defaulting to the longer password – ratchet freak Feb 11 '15 at 08:31
@immibis: yes, it means that unless the attacker knows which numbers were under the smudges, the smudges don't tell them your PIN. The random placement needs to be different each time you use the PIN. Or rather, it needs to be re-randomised with a small probability of being the same ;-) – Steve Jessop Feb 11 '15 at 13:11
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
Actually, I consider the pattern to be extremely secure. Unless you don't clean your screen after use. But a pattern with 7 points and hidding the 'path', is harder to guess than a pin of 8 characters. Since you don't unlock the cellphone to simply check the time, you can be sure that most of the 'fingerprint path' will be unrecognizable to be guessable. A pin can be easily seen since the user must see the keys to click them. The pattern is harder since you have to memorize where it started and check for intersections and colisions and repetitions. – Ismael Miguel Feb 11 '15 at 16:20
1

The newer "face unlocks" have security features like requiring a blink such that a simple photo won't work, but they are optional since they make it harder to use – user2813274 Feb 11 '15 at 17:11
@user2813274, actually, someone defeated it by photoshopping a photo so the eyes were closed, then rapidly switching them back and forth. Cool stuff. – Ohnana Feb 11 '15 at 17:23
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
@Nit What if you put letters on the PIN keypad like a phone does? Then users can remember words and translate them to numbers. – jpmc26 Feb 12 '15 at 01:40
A 10 digit PIN is already almost unusable for most users and they will choose something like 0000000000, but if you also randomize the Buttons, you cannot even use motoric memory for entering the password fast. It will be tedious to enter everything more complex than 111222 – Falco Feb 12 '15 at 10:07

score 14 · Answer 2 · answered Feb 10 '15 at 15:25

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.

answered Feb 10 '15 at 15:25

AlexH

1,168
6
8

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

vrtjason · Answer 3 · 2015-02-10T19:51:59.947

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.

edited Feb 10 '15 at 19:51

answered Feb 10 '15 at 19:07

vrtjason

1,045
9
10

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 – Feb 13 '15 at 15:16

score 4 · Answer 4 · edited Mar 17 '17 at 10:46

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.

score 3 · Answer 5 · answered Feb 11 '15 at 04:32

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/

answered Feb 11 '15 at 04:32

Mitch

31
2

score 1 · Answer 6 · answered Feb 10 '15 at 18:46

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.

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.
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

score 1 · Answer 7 · answered Feb 12 '15 at 23:34

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.

What is a good way to authenticate a user to a smart phone?

7 Answers7

Linked