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?
-
4Are you asking about how to authenticate a user TO the phone, or authenticating VIA the phone?– schroeder ♦Commented Feb 10, 2015 at 18:51
-
@Schroeder Actually, both, however, I am more focused on authenticating via the phone.– JonathanCommented Feb 10, 2015 at 18:57
-
1Yeah, evil Microsoft. But they're onto something with this Microsoft Account app.– E.V.I.L.Commented Feb 10, 2015 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.Commented Feb 11, 2015 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.Commented Feb 12, 2015 at 8:02
|
Show 2 more comments
7 Answers
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.– OhnanaCommented Feb 10, 2015 at 15:48
-
1Do 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". Commented Feb 10, 2015 at 17:00
-
7Minimum pin of 10 numbers? No one will use your application.– EtheryteCommented Feb 10, 2015 at 21:15
-
3On Android, face recognition is a convenience feature. You always have to provide an alternative unlocking mechanism.– musiKkCommented Feb 11, 2015 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. Commented Feb 11, 2015 at 23:30
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).– JonathanCommented Feb 11, 2015 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– FalcoCommented Feb 12, 2015 at 10:08
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.
-
1I'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). Commented Feb 10, 2015 at 22:05
-
1I 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.– user45655Commented Feb 11, 2015 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.– vrtjasonCommented Feb 12, 2015 at 19:26
-
@nyuszika7h: I provided my answer before the OP was split off.– vrtjasonCommented Feb 12, 2015 at 19:49
-
@vrtjason: this don't help I guess if phone is stolen and someone knows the username/password– user68288Commented Feb 13, 2015 at 15:16
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.
answered Feb 10, 2015 at 22:00
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/
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 VCommented Feb 10, 2015 at 18:51
-
The device is not the only place you can obtain the owner's fingerprints from.– user45655Commented Feb 11, 2015 at 14:45
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.
