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