What all UX designers should know about login and security

In 2013, several Dutch retail banks were the victim of DDoS attacks. And in this year, Kickstarter and Skype were attacked by hackers. And these were not the only incidents. As online service providers increase their UX maturity level, the community of cyber criminals is also developing strongly. The digital vandals now include international spies, uniform-wearing cyber warriors and PhD-trained criminals, straight out of a Bond movie. (Source: “Why security without usability leads to failure“, Forbes (2013)).

Furthermore, technology infrastructures are moving increasingly beyond (relatively safe) security walls. Data and software are becoming part of the cloud and are accessible through a range of devices. More and more, we have to identify ourselves to gain access to our own digital property. And we want simple and fast access our data anywhere, anytime. But we’re not the only ones.

Now I can hear you think “That’s all very worrying, but why is it my problem as a UX designer? We have enterprise architects and security officers to deal with this issue.”

Donald A. Norman has a different view on this issue. His slogan is “The more secure you make something, the less secure it becomes.” Why? Because when security get in the way, sensible, well-meaning, dedicated people develop hacks and workarounds that defeat the security. Think of all the passwords on Post-its stuck to your monitor, or your house keys under the doormat. Usability and user experience are important pillars of a secure and safe internet. (Source: “When security gets in the way“, Donald A. Norman (2010)).

This is why it is important for UX designers to have a basic understanding of security-related processes and terminology. It is time to take responsibility and make the (digital) world a safer place, including from a UX perspective.

Whether someone is granted access to specific data or not is specified in the access control process, which is based upon three steps:

1. Identification (“I’m person A”)
2. Authentication (“It’s true, you are person A”), and
3. Authorization (“I see you’re person A, with access to B.”)

For example, lets say I want to login into LinkedIn. I enter my user name (Identification) and password (Authentication). Then I can access LinkedIn, but not to its Premium services, because I’m not authorized to do so. You often identify yourself with a username. Increasingly, biometric characteristics such as fingerprint, iris scan, or tokens (smart card, certificate) are used instead as means of identification. After identification you’re required to provide some evidence of your identity, in order to authenticate you. In the offline world, a passport is often used for authentication. In the digital world, there are traditionally three types of evidence for authentication:

1. something you know
2. something you own, and
3. something you are.

For example, ‘something you know’ is a password or a secret sentence. A hacker will often try to take over somebody’s identity by guessing or cracking a password. To prevent this from happening, complex rules are often applied to passwords. With all possible consequences, as discussed before.

‘Something you own’ is an item that the authoritative system has delivered. That can be a specific type of token, or an item the system has checked is in your possession, for example your mobile phone.

‘Something you are’ is a unique personal characteristic stored in an authentication database. For example, your fingerprint, voice, iris, or face.

As you may have noticed, identical types of items or characteristics can be used for identification as well as for authentication. However, an item or characteristic used for identification can’t also be used for authentication within the same process for access control.

Single factor authentication (SFA) entails identification combined with a single piece of evidence. With multiple factor authentication (MFA), multiple pieces of evidence from different categories (knowledge, ownership, or characteristic) are used. A login with user name, password (evidence: knowledge) and SMS code (evidence: ownership) is an example of multiple factor authentication or two factor authentication (2FA).

With adaptive authentication, a fourth type or factor of evidence for authentication is added: context. Context includes parameters such as time, location, device, browser, and application. At an individual level, secure profiles are established containing one or more context items. These profiles are assembled by a so-called risk engine. After the user is logged-in with a single factor, his context is checked against one or more secure profiles. If there is a match, the context will be accepted as the second factor of authentication. If not, the user will have to authenticate the second factor actively.

For example, every Sunday afternoon I do my online banking payments, and I login with my browser. Because it’s a recurring pattern, the context items time (Sunday afternoon), location (IP address), and browser (IE) are stored as a secure profile. I don’t need to authenticate the second factor actively. My user name and password are sufficient.

Besides profiles at an individual level, organizations can assign specific content items or actions to always require additional authentication. Examples might be logging in for online banking from outside your continent (item), or carrying out a payment (action).

Now that we know how to login into a single environment, it’s interesting to dive briefly into Single Sign On (SSO). With SSO, a user logs in only once in order to have access to all environments within the same SSO set. When the user logs out, he’s logged out from all environments within the same SSO set.

SSO is based on the principle of ‘Federated Identity Management’ (FidM), which manages the identity and access rights of users for different organizations and platforms. This is becoming increasingly important due to the decentralization of ICT infrastructures, like we addressed before. SSO entails the management of identity, but not of access rights (Authorization).

What actually happens with SSO? For each environment you log into, your digital identity is known. For example, one environment recognizes me as ‘Wprins’, whereas the other uses ‘Sm@rtyP@nts83’ for recognition. Obviously, both environments don’t know that the same person is behind both aliases. So what is necessary for SSO is a connection between both digital identities in the different environments. From a technical perspective, there are various solutions which are in the domain of enterprise architects. But for those interested in this issue, just search for SSO or ‘Federated Identity Management’.

To clarify things a bit more, there are capabilities like OpenID (or similarly Facebook Connect or Windows Live ID). These are not the same as SSO. These solutions facilitate the use of identical login details for separate environments (for example, login into Runkeeper with Facebook Connect). Contrary to SSO, you still again have to login into each separate environment. No single sign on, but same sign on.

Enough theory for now, let’s look at some examples.

For a long time, retail banks have made use of multi-factor authentication. One of them introduced electronic banking in 1986 using a paper token list. There are still people that make use of such lists.

At several retail banks you login into the online banking environment with a user name and password – single factor authentication. Conducting a transaction requires a step-up authentication. For example, by entering the proper token from the before-mentioned paper list.

I remember that during my work at a Dutch retail bank (2012/2013), they were working on the implementation of adaptive authentication. Unfortunately, I’m not aware of any actual implementation of it.

There’s only one Dutch bank which uses tokens (on paper and through SMS message). All the other retail banks use a kind of internet banking device which generates numbers. Token lists and devices such as these are both examples of the evidence factor for authentication – ‘Something you own’.

Unlike the online banking environments, the mobile apps of all the retail banks use a pincode to login. For these apps, the device on which the app is installed must be registered before the app can be used. This means that the banking apps are actually carrying out multi-factor authentication: A pincode (‘something you know’) and the registered device (‘something you own’). Often you can only transfer a limited amount of money without any step up authentication, because you are already authenticated with two factors.

Currently, I work on a security-related project for an insurance company. In this project, the business requirement for SSO is combined with a legal requirement for MFA. Or as our government phrased it, “For every type of information, there must be an appropriate lock”. And that’s just the point. Whereas step up authentication is applied only for banking transactions, the client envisions step up authentication whenever the user wants to access classified information, which is seen as an additional risk. Information such as personal, financial and healthcare details are unfortunately not neatly packed together, but are distributed over various pages in several environments in the SSO set. In order to prevent frustration, it’s important that users understand when and why step up authentication is required.

The goal is to find a proper balance between security and a frictionless experience for logging in. An interesting challenge.

This post is just a fraction of the complete story. If you want to know more, just search for ‘Human Computer Interaction & Security’ (HCISec), a discipline completely devoted to the topic.

Logging in, registration and security settings are not the core features of a product or website and therefore often receive less attention than other functionality. However these supporting features are essential for the process of secure access control. So, pay special attention to usability and user experience of these features. Often, ‘the devil is in the details’.

For example, do the same security rules apply to all content and functions, or not? Think of a step up authentication to conduct a transaction in an online banking environment. Does the user understand why additional authentication is required? Maybe for a transaction, but when you implement step up authentication to access specific content (for example, access to personal invoices from a health care provider) it’s becoming more difficult. When you require authentication, does it always have to be conventional user name and password. Currently, many users have a smartphone which may provide easy (but not necessarily more secure) methods to login. For example, you can now login by sending a push message to a registered smartphone, so the user only needs to press OK. This is much easier than remembering and entering a permanent password or a one-time password.

Try to divide your (design) project into security levels (single or multi-factor) and additional factors of authentication in order to deliver a suitable, understandable and frictionless login experience for the user.