Problem

A method must be provided to confirm only authorized individuals have access to a device, or a site, service or application on the device.

Solution

Do not require explicit authentication by default. Mobiles are personal, so only require authentication for first time entry, very high security situations, and for multi-user devices such as kiosks.

Personal mobile devices also all have built in security methods, so users can lock them if security conscious. During setup, you may remind users of these features instead of adding additional security to your application or website.

User identity, whenever known, should be used and as much information in the system displayed as possible before authentication gateways are passed. Authentication may then only require the password.

Authentication must be presented in context, so it is clear what system the user is gaining access to, and why the level of security is needed. Entry methods must be designed to encourage ease of access, and prevent miskeying.

Variations

The most common method is to extend desktop paradigms and accept input via form fields, as text or numeric entry using the conventional input methods provided with the device and/or OS: hardware or virtual keyboards and keypads.

Text/numeric entry, using conventional input methods, whether hardware or virtual

Virtual, changing pad

Pattern

Additional entry methods, such as voice, are not yet established enough to have best practices in the mobile space, and therefore no design patterns exist.

Remember that entry of credentials is not enough to count as a full security methodology. Recovery, reset and out-of-channel notifications are also required, but are systematic approaches outside the scope of this document. For very high security applications, multi-factor authentication, biometrics and token-based security systems (such as RSA SecureID) must also be considered.

Interaction Details

The Sign On dialogue is usually best when it is the only accessible item to avoid confusing entry with other behaviors. This makes it either a complete page or state, or a modal Pop-Up.

When using a form field to enter passwords, restrict entry methods to those allowed. If the password is only numeric, disregard alpha or symbol entry on hardware keyboards, and only display the virtual numeric keypad.

For small, personal-sized devices like phones, MIDs, and tablets, passwords should not generally be obscured. "Shoulder surfing" is extremely difficult due to the scale and viewing angles. In addition, the user may be relied on to move to a more private area or simply turn around, behaviors that desktop users cannot exercise. Displaying the entire field will greatly speed entry and reduce errors on entry, all of which not only reduce user frustration, but increase security by reducing time on entry and reducing use of recovery methods.

For larger uses of passwords or secure information where the password will be on the page for a while -- such as account creation -- the password may be obscured when the entire field is not in focus.

XXXXXX - START HERE!!!! Pad entry (on screen keypad, standard or custom - preference is to randomized if you go this way)

Pattern entry (on screen gestural shapes)

-- device lock hints: make gestures clear, pattern codes, etc. ALSO, some notes about best practices for pattern and numeric unlock; it is easy to crack a lock by fingerprinty screens, so if truly high security, make it random position -- variation maybe cut by not design but security requirements, and designs that fall from that...

Provide links to seek help on entry, get more information on security of the system, and to recovery and/or reset methods.

When creating usernames and passwords, as for account creation systems, use tools to check that the username is available and the password sufficiently secure as soon as the user moves to the next field. Avoid displaying errors after submission.

Presentation Details

Title and describe... not just app, but section or process. If title does not imply why they need to authenticate, add a description

Label fields

If identified, provide additional user information, such as their avatar photo and name. Do not just ask for the password with no supporting information

Antipatterns

Use caution when obscuring fields. Do not assume that the default password method built into the OS is secure. Most still reveal the character being typed, as required in triple-tap text entry modes. If an obscured entry is required due to use as a kiosk, while attached to a projected device or in other shared situations, be sure to specify how obscured it must be.

Examples