A UX Challenge: The Mobile Password

Passwords on mobile phones: How I loathe thee.

Even prior to the emergence of the mobile web, password fields had their own set of User Experience flaws.  From complex and confusing requirements (password length, special characters, etc) to poor instructions, difficult input fields to delays for recovering passwords, it’s not uncommon for users to abandon log-in and sign-up forms resulting in lost business and unhappy customers. 

Now with rise in popularity of mobile usage, a whole new batch of pain points has emerged: complications arising from large fingers, limited screen space, and small keyboards all add up to an oft-frustrating user experience.

While these constraints may limit us in rethinking our standards, they also offer a new set of capabilities unique to touch and mobile devices, which may in turn hold the key to better mobile passwords.


What we're told: Make your passwords strong

For security issues, users need to enter in "strong" passwords.  'password123' doesn't cut it.  Some interfaces won't even let you continue a process if you have chosen a weak password. 

Desktop solution

To alleviate the pain in this step, we saw the emergence of AJAX password strength checkers and mircrocopy that gave us tips (use numbers and at least one capitalized letter).

Password strength checker and microcopy with instructions

The mobile pain point

Strong passwords often require the need to shift between multiple mobile keyboards.  For instance, you might click a button to capitalize, then switch to the number keyboard, then switch back to the alphabet keyboard, then once again switch back to number keyboard.  Can’t find that special symbol? Oh yeah, you’ll need to click again through the number keyboard and then to the symbol subset.

Standard iPhone keyboard and the subset with number and symbols

What we're told: There's someone leaning over your shoulder trying to steal your password.

The password field type uses bullets to obfuscate the characters you've entered, allowing you only see the last character you inputted.

The default styles for 'input=password' field

Desktop solution

Users are asked to enter their password in twice to reduce errors.  AJAX error checking helped catch mismatches before form submission. 

Example of immediate validation 

For some systems where the password was known to be long and complicated (WEP passwords on wifi networks), the user should opt to "Show Password."

Since WEP passwords can be difficult strings of characters to remember, Apple added the option to 'Show Password' to reduce errors

The mobile pain point

Keyboard entry errors aren't news to product engineers.  Predictive text, a learning autocorrect, and keyboard shortcuts are implemented on mobile phones and touch devices.  But none of those tools are available for password fields.  It's hard enough dealing with writing out an unusual word and string of characters on a mobile keyboard, but now you have to add additional care and observation to see if you hit the write key with your awkwardly large fingers.

Various Solutions for Mobile Passwords

Show password option

A simple user-side solution that has a checkbox where the user can opt to choose to switch the bullets within the field type to visible characters. 

From Luke Wroblewski’s design of the Polar app.

The interface could be designed in several ways: have a checkbox checked on default, change the styling to a on/off slide, use a button that toggles between "Show Password" or "Hide Password", or place the option to perform an action within the field itself (as seen in the example above).

The simplicity of this solution is what makes it so appealing.  The system itself doesn't need to adapt its structure (as some of the solutions below require).  Be aware that it's important to maintain the HTML5 input type, as including just a simple text field has it's own problems on mobile devices of autocaptilizing, autofilling, and autocorrecting.

As lovely as this solution is, the issue with the need to use multiple keyboards on strong passwords is still present.

Mobile PIN alternative

When logging in from a touch device, allow the user to choose a number instead on the next log-in. offers the user the option to set up a PIN if on a mobile device

The problem of having to use multiple keyboards for strong passwords is eased with allowing the user to use a simpler 4 to 6 digit PIN.

On the user's end, they have to now remember two pieces of credentials to access their account or information: the username/password for non-touch devices and the username/PIN for touch devices.

Additionally, we run into disparate messages: passwords can only be strong if they have a mix of characters, numbers, and letters but that doesn't matter as much on mobile devices.  A user is left feeling unsure if their PIN will be secure enough to prevent hacking attempts and their confidence in the system may wan.

The system has to be adapted programmatically to now log that PIN alongside the user's existing credentials.  Not entirely hard, but the system also has to be able to deal with password reset requests when the user forgets this new bit of information.

Gestural passwords

Similar to the PIN solution above, users create gestural passwords either by sliding from one point to another in a matrix grid or drawing symbols over an image (as seen on Windows 8).

Windows 8 uses gestures as an alternative to the standard password.  Users draw shapes or lines over a selected picture.

Gestural passwords feel more secure to than PINs and are less easy to hack than the smaller finite possibility of a string of numbers.

Implementation into the system would require a much more complex solution than the PIN, having to take into account not just the tracking of the gestural positions on the screen but also coding for the large range of existing and future touch screen dimensions.

Should anything hinder the user's capability to gesture—physical disabilities, visual impairment, lack of gestural accuracy, a broken touch screen—the gestural password would do little good.

Device authentication

The user’s device is logged in and approved and all future log-ins could either be made easier with a PIN or gestural password or require no password at all.

Adds another level of authentication and improves user confidence when used in conjunction with a PIN or shorter, alternative means of verifying identity (such as picking an pre-selected image from a group or answering a multiple choice question with person information correctly).

System not only needs to adapt to accommodate information, but also to provide interface or means of allowing user to manage their devices.  If a phone is lost, stolen, or sold, authentication should reset for that device.

Solution only works for single-user devices.  Shared items could not use this feature.


An app is downloaded on the device that allows username and password fields to autofill.  A single, master password is used on the device, or even a PIN or gestural password. 

1Password is a popular desktop and mobile app for managing passwords

The burden to adapt systems to different password types falls not on the website engineers, but rather on the app developers.

The only users that benefit are those that download and use the software.  They bear the cost (if a paid app) and data requirements (memory, storage). Additionally, mobile manufacturers control how apps and plugins work with the native browser.  For 1Password, iOS Safari doesn't work with the app and so users must use the app's built in browser.

Fingerprint or face detection

Touch devices become exact enough to scan a fingerprint or face, even in low light situations.

Apple's iPhone 5 allows for Touch ID

As unique a password as there could be, users would get a high level of security that required little or no error on their part when input was required.

Not suitable for when requiring multiple users per login.  The capability to do this relies heavily on the capability of the device and technology to allow for detection.

Honorable mention: