Differences between revisions 13 and 14
Revision 13 as of 2010-11-06 05:26:19
Size: 7934
Editor: shoobe01
Comment:
Revision 14 as of 2010-11-06 05:37:06
Size: 8554
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
{{attachment:SignOn-TouchSK.png||align="right"}} {{attachment:SignOn-TouchSK.png|Username and password fields do not change, but submit and cancel can change depending on the interaction methods available, and the OS standards. Touch and pen devices are very different from scroll-and-select.|align="right"}}
Line 16: Line 16:
{{attachment:SignOn-Detail.png||align="right"}} {{attachment:SignOn-Detail.png|Anonymous users, such as the first time you sign into an account, must provide a username and password. When just checking credentials on a second visit, display their information and only ask for the password.|align="right"}}
Line 29: Line 29:
{{attachment:SignOn-Create.png||align="right"}} {{attachment:SignOn-Create.png|Creating credentials is very similar to entering them for Sign On. When the field is in focus, make it entirely visible. If it will be on the screen for a while, it can be obscured when out of focus.|align="right"}}
Line 51: Line 51:
== Presentation Details ==
Line 52: Line 53:
== Presentation Details ==

Username and password fields do not change, but submit and cancel can change depending on the interaction methods available, and the OS standards. Touch and pen devices are very different from scroll-and-select.

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

Consider whether your specific situation requires explicit authentication. Mobiles are personal, so should only require authentication for first time entry, or for very high security situations. Mobile-like multi-user devices such as kiosks will also require authentication.

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.

Anonymous users, such as the first time you sign into an account, must provide a username and password. When just checking credentials on a second visit, display their information and only ask for the password.

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 on-screen keyboards or keypads.

A custom keypad may also be provided, which the user may tap or drag across in a pattern, for increased security or additional ease of entry.

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.

Creating credentials is very similar to entering them for Sign On. When the field is in focus, make it entirely visible. If it will be on the screen for a while, it can be obscured when out of focus.

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.

When the password field may be on the page for a while -- such as account creation -- the password may be obscured when the entire field is not in focus.

An optional method to enter a passcode, for touch and pen devices, is to provide a custom keypad. This may use conventional characters, such as numbers, or special symbols to add a layer of obscurity. These are most used as an increased security method; the order of the items changes each time, preventing observers from determining the passcode string by looking at finger patterns or examining the screen for marks.

SignOn-Pattern.png Another method, especially useful for securing device lock screens, is to provide a pattern entry. A grid of numbers or symbols is provided, and a series of adjacent items must be selected as a single gesture, such as an L or U. While fewer combinations are possible, this can be done with minimal visual input, and may also be configured to learn specifics of the approved user's gesture speed and accuracy. Gestures outside established bounds may require entry of conventional passwords as a backup confirmation method

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 (a related entry method) 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.

A "Cancel" function must always be provided in case the user cannot recall their credentials, or must perform some other task instead.

Presentation Details

SignOn-Gesture.png Password entry screens and Pop-Up dialogues used for authentication of a process must be labeled in a manner reflecting the portion of the process and need for authentication. For example, "Sign on to purchase." If the title is insufficient, add a description, but keep it brief; users are unlikely to read much, and will gravitate to the entry fields.

Label each field, and be sure to use the same terms each time they are presented. Indicate the allowable input methods, and the current input method, for each field. This may be simply by locking a virtual keypad into the allowable mode.

If the user has been identified by device, cookies or so on, provide the known and non-secret user information, such as their avatar photo and name. Do not just ask for the password with no supporting information. Avoid demanding usernames when this is already known, or has actually been printed on previous screens (or in the header of the Sign On screen).

Buttons to submit Sign On forms must, whenever possible, be contextually labeled. Use terms such as "Continue" to remind the user they are in a process, and avoid "Sign On" and the even more generic and technical "Submit" whenever possible.

When two equivalent buttons are presented -- as opposed to "Cancel" existing as a Softkey, and "Submit" as an on screen button -- the "Submit" choice should be designated as the preferred selection; the OS standards should include a method of indicating button preference such as color, icon use or border treatment.

The label for the "Cancel" function should always use the common term or symbol designated by the OS to denote canceling or going back from the current action. For devices with Softkeys, or OSs with Softkey-like buttons, the Cancel function at least should be displayed as a Softkey button.

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.

Avoid using any desktop paradigms without considering the consequences. For example, do not use dual fields to attempt to solve the entry problems associated with obscured entry.

Be careful to use terminology absolutely consistently throughout the process. If documentation refers to a passcode (because it is a number) do not suddenly use the term "Password" on the Sign On screen. Also try to use correct terms when possible. Enough users are used to authentication systems many of them understand the difference between recovery and reset. Do not conflate or confuse the terms.

Examples

Sign On (last edited 2013-04-11 00:01:18 by shoobe01)