Passwords. Key security measure or waste of time? The real answer is somewhere in between. For some apps, like banking, passwords are a necessary measure – but for mobile apps, there are great alternatives which take the hassle out of user verification.

As computing moves from the desk to the pocket, and usage from the generalist browser to proprietary apps, we might have to admit that the string of sixteen letters, numbers and symbols (or using the word ‘swordfish’ for everything) has had its day.

Why do mobile apps have passwords?

Put simply, it’s a legacy issue. Passwords are a throwback to the times when applications sat on a desktop PC. Desktops weren’t personal devices which could be used at a moment’s notice – they were shared work or family machines with multiple users and a need for individual profiles and authentication. Websites still need passwords for a similar reason – the site needs to verify that you’re still you, regardless of which device you’re logging on from.

This thinking was carried forward into app development, on the basis that ‘that’s how we’ve always done it’. But as mobile technology has developed, more satisfying and flexible options have emerged.

Why are passwords a problem?

Apps already have enough of a buy-in process; users have to find them, download them, install them and learn to use them. Adding another stage to that process – logging in the first time (or worse, every time) – is another factor that encourages the already high drop-off rate witnessed when an app launches..

This leads us to another problem: security. Users aren’t as creative as they think they are, and the vast majority of us (yes, you too) struggle to remember passwords we’re told are secure, instead reusing passwords we can remember for all our apps, from bank accounts to your ‘I luv cats 4eva’ membership login.

The result? Users who abandon apps rather than resetting passwords and systems which compromise the security of other systems. Is your security good enough for your users’ bank passwords? The fact is, it has to be.

Do mobile apps need passwords?

What would happen, really, if apps never asked users to log in? Why do we need email-based verification of new users when we have push messaging? Why are we asking for passwords when mobile devices have secure key storage? Why, in short, are we asking users to do hard work before they’ve even used our app and decided if they like it or not?

What alternatives are out there?

1. Register later – ask the user to register once they’re retained. Once the app has proved its worth, they’ll go through the process to keep it.
2. Social media logins – granting access to an app through a user’s Facebook, Google Plus or Twitter account. Not all users will trust your app with their Facebook account and data, though, and the fastest-growing social media platforms (Snapchat and Instagram) don’t offer the function. But it’s satisfyingly quick and simple.
3. Send an email automatically – instead of the user having to type in their email address, have the app send an email from the user’s account on the device they’re using. This way the user doesn’t have to leave the app for the sake of busywork – again, the goal is to streamline the user experience and eliminate opportunities for the user to drop off.
4. Body scanning –  fingerprints, gestures, signatures, face or voice identification are all viable password alternatives on current mobile devices.
5. Drawing a shape – if it’s good enough for the Android login screen, it’s good enough for your app (although it does have the same problem of re-use as the traditional password).
6. Deferral – if the app is designed to work in a secure location, like an oil rig, or over a secured network, verification doesn’t need to take place within the app, instead the app can trust that anyone who’s already got access to the corporate VPN or whatever is meant to be there.
7. OS improvements – what if mobile operating systems could simply transfer saved passwords from web browser to app, or share keys between related apps, or simply fold all your passwords into one? That last one isn’t quite ready to go yet, but some apps now feature support for third party password tools like 1Password.
8. Contextual biometric authentication – Google’s Project Abacus would replace the password with a trust system, in which apps already know who you are because they’ve been monitoring your gait, speech patterns, typing style and are aware that you’re their regular user.
9. Use the website – if the app is supposed to interact with a website, have the website display something (like a QR code) which the phone can scan and use as its access token.
10. Registration as a paid service – like SleepCycle’s sleepSecure, which brilliantly turns the whole concept on its head and asks users to pay for a login function. Why would people pay for that? Well, data is only available away from the app with a login. You want the data, stump up the cash.

These options won’t work for every app. For banking, email and social media, it’s best to stick with user verification every time. For mobile apps, though, there could well be a better way. We can streamline the process of logging in with a password – or ideally, replace it altogether, with a process that strips out the security compromises and improves the user experience. Any more suggestions? Tell us on Twitter.

For more essential app-development/engineering insight, follow the Calvium blog.