Strengthen User Authentication and Preserve User Experience

Roman Yudkin

Alphanumeric passwords have long been the primary method of authentication and access control on the Web. In recent years, however, relying on passwords as the sole method of authentication has proven to be unsustainable and not secure.

Research shows that authentication-based attacks were used in the majority of major data breaches in 2012. Simply moving beyond passwords to implement stronger forms of user authentication would prevent nearly 80 per cent of hacking attacks on companies.

Because people often use the same password on multiple websites, a large-scale password leak at one site creates a domino effect that harms security for many other websites and applications. When 1.5 million user credentials were leaked from Gawker Media Group, spammers and hackers immediately used those credentials to access user accounts on other websites. Hundreds of thousands of accounts on Twitter were compromised and used to spread spam and malicious links. Amazon and LinkedIn had to enforce password resets for their entire user communities.

Such debacles harm not only the individual users whose accounts are compromised; they also harm the organization, website or application itself. The negative repercussions of a data breach can include legal liability, fines, loss of customers, damage to brand reputation, plus the cost of fixing security and IT systems amidst a crisis.

When hackers stole more than 8 million user passwords from LinkedIn and eHarmony accounts in 2012, LinkedIn estimated it spent more than $1 million to clean up the breach and would need to spend another $2-$3 million for additional security upgrades. In 2011 Sony was forced to spend more than $170 million to remedy the fallout from a data breach that leaked more than 100 million PlayStation passwords.

Mobile developers must also consider better authentication methods. The majority of smartphone and tablet owners do not password protect their devices, despite having them connected to sensitive applications including work networks and banking applications. Users do that because typing passwords to log into mobile apps is too cumbersome. Experts at the CTIA Wireless conference even stated that growth of mobile commerce will be stunted until new, easier-to-use authentication methods are developed.

To achieve effective, strong user authentication on websites and applications, developers must balance security with usability. Do this by evaluating the security needs of the business as well as the characteristics of the user population. Is the user base comprised of employees, business partners, or the general public? This will help determine risk level and how stringent the authentication requirements should be.

Recommendations For Strong Authentication

Make sure the basics are covered

Since most websites and applications will likely choose to continue using a password as the first layer of authentication, make sure these basic security measures covered:

  • Enforce a dictionary check to ensure that users cannot choose common words for their password.
  • Require a strong username that includes a numeric character. Often the username is the easiest portion of the login credentials for a hacker to guess. Do not use the user’s email address as their username.
  • Limit the number of failed login attempts to three and temporarily suspend account access unless the user can authenticate through other means.
  • If the login fails, don’t identify which portion of the credentials was incorrect. Stating that the ‘password is incorrect’ or the ‘username doesn’t exist’ enables hackers to harvest account information. A general statement such as “Incorrect login, please try again” helps prevent account harvesting.
  • Use SSL to create an encrypted link between your server and the user’s web browser during account enrolment, the login process and the password reset process.
  • Provide users with advice on how to choose a strong username and password. Research shows that users do choose better passwords when given advice on how to do so. One option is to have a password strength meter built into the page.
  • Hash user passwords using bcrypt, scrypt, or other hash algorithms specifically designed to store passwords. Do not use SHA1, MD5 or other algorithms that were not designed for hashing passwords, as they are not secure.
  • Use Salt. Use a unique salt for each user account/password and store that salt with the password. An additional layer of system wide salt that is not stored with the password can also add extra strength if the database is stolen because it is not stored with the passwords but is known to you.

These steps may seem rudimentary to some readers, but a study conducted by researchers at Cambridge University showed that most websites did not even enforce these minimum standards.[i]

SaaS solutions for generating one-time passwords

With the growth of Software-as-a-Service (SaaS) providers, it’s easier than ever to adopt authentication solutions that generate one-time passwords for users without any hardware investment or significant integration efforts. While one-time passwords will not stop a sophisticated man-in-the-middle threat, they do protect against the most common security threats: users choosing weak passwords, reusing the same password or having their passwords stolen using keystroke-logging malware.

By generating one-time passwords for users each time authentication is needed, organizations can ensure strong passwords are used and that previously stolen or leaked passwords cannot be used to access accounts.

The growing number of user devices with touchscreens enables new approaches to SaaS authentication schemes, including image-based and graphical approaches. Increasingly users are asked to draw a pattern, touch points on a picture or identify a series of secret images to authenticate. When evaluating such approaches, it’s important to make sure the solution generates one-time passwords and is not simply a static pattern or image. User’s fingerprints and smudges on the touchscreen can reveal their secret pattern or touch points if it is a static approach.

One way to generate one-time passwords using an image-based approach is to have the user choose a few secret categories of things – such as dogs, flowers and cars. Each time authentication is needed the user is presented with a series of pictures on the touchscreen and must tap the ones that fit his previously chosen categories. The specific images are different every time and displayed in a different location on the screen every time, but the user will always look for his same categories. As the user clicks or taps on the pictures that fit his categories, a one-time password is generated behind the scenes and submitted to the server for verification.

Graphical authentication approaches are easier for users to remember than complex passwords and they are faster for users to perform on smartphones and tablets than typing an alphanumeric password. For this reason, they are a good method for adding a layer of security or a one-time password without inconveniencing users.

Risk-based authentication

Organizations requiring even stronger security should consider integrating a risk engine with their authentication solutions. Using behavioral and contextual risk profiling, risk engines can dynamically trigger additional layers of authentication only when needed. This increases security without inconveniencing users because users will rarely encounter the additional steps. Risk-based authentication solutions should identify device reputation, and evaluate the geolocation of the user’s IP address and time of day they are accessing the site.

Also examine the frequency of the login attempts, which could indicate a brute force attack. If a high-risk or suspicious situation is identified, require an additional authentication step from the user. The additional authentication step could simply be second layer of authentication, or it could be a second factor of authentication.

Multifactor Authentication

Organizations whose websites or applications could be a high-profile target for hackers should adopt out-of-band, multifactor authentication. Multifactor authentication involves at least two of the following authentication factors:

  • Something you know (i.e. a password, secret image categories or other shared secret)
  • Something you have (i.e. a mobile phone or authentication token)
  • Something you are (i.e. biometrics such as a fingerprint)

Multifactor authentication solutions that rely on the mobile phone as the second factor are increasingly popular. The most common approach involves sending an authentication code to the user’s phone via an SMS text message and having the user type the code into the web page to authenticate. Knowing that banks often use this approach, cybercriminals are increasingly targeting the SMS channel for attack. Using malicious software they are able to compromise a user’s online account, intercept and reroute the authentication text messages to their own phones, then use the code to gain access to the user’s account.

A more secure approach is to adopt a multi-layered, multifactor authentication solution that remains completely out-of-band from the web session on the PC. Organizations can use push technology to send an authentication challenge to users’ smartphones. Users must solve the authentication challenge on their phone and send back their response/approval via push technology, which uses a server-to-server communication channel and is more secure than SMS.

For example, using the image-based authentication approach described earlier, when a user logs into their online bank account on the PC they enter their username and password. Using push technology, the bank sends an image-based authentication challenge to the user’s smartphone. The user must tap the images that fit his secret categories and tap a submit button to send his selection back to the bank for verification. The process remains entirely out-of-band from the web session because there is no data to type into the web page on the PC.

In addition to being out-of-band, the process is multi-layered and multi-factor. The user must have possession of the registered second factor device (their phone) but also apply a shared secret (knowledge of their secret categories) on the phone. Even if someone else had possession of the user’s mobile phone or intercepted the delivery of the out-of-band authentication challenge, they would not be able to complete the process because they would not know which images to identify.

When evaluating multifactor authentication solutions that rely on the user’s mobile phone as the second factor, look for solutions that remain completely out-of-band from the web session on the PC and those that use push technology rather than plain text SMS.

Biometrics and Behavioral Biometrics

Biometrics and behavioral biometrics are also increasingly viable authentication options. Most laptops, smartphones and tablets now come with built-in video cameras that can be used for facial recognition, and fingerprint scanners are quite common in mobile and desktop environments. Smartphone applications can be used for voice recognition. However, drawbacks of biometric authentication include the need to maintain the equipment and ‘body parts’ to get accurate readings; biometric ID data must also be stored in databases and is therefore susceptible to theft and forgery.

Depending upon the type of organization or account being accessed, users may not be willing to provide biometric data for authentication. For example, users may be willing to use a fingerprint scanner to authenticate for their bank account, but not for a social networking or shopping site.

Behavioral biometrics are technologies that tracks the user’s behavioral patterns such as keystroke speed and mouse movements. These and other behavioral profiling techniques can help to successfully identify individual users, especially when used in conjunction with another authentication factor. Behavioral biometrics are usually analyzed behind the scenes, unnoticed by the user, so they do not inconvenience the user, which helps improve the usability of security.

Conclusion

Authentication standards on most websites and applications are woefully lacking. Relying solely on passwords puts the organization, its users and its data at risk. Not every website needs multifactor authentication, but most can benefit from using multiple layers of authentication or one-time passwords. User education is also critical for improving authentication. Unless the user clearly understands the reasons for additional authentication requirements, they will find ways to circumvent the policies.

Finally, it’s important to remember that ‘security’ is a process–organizations must continually re-evaluate security needs, identify areas for improvement and make a security roadmap for future improvements. A website or application can never be completely secure, but developers and security professionals should aim to strengthen security to the point where it will deter most attackers while maintaining ease of use for end-users.



[i] “The password thicket: technical and market failures in human authentication on the web” by Joseph Bonneau and Sören Preibusch

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Anthony

    I find that some of the minimum standards you quote are actually barriers for users on most sites:

    “Enforce a dictionary check to ensure that users cannot choose common words for their password.”
    This forces a user to select a difficult-to-remember password. If your site is one that they don’t use regularly (ie isn’t Facebook, or Twitter) then they’ll probably completely forget their password, forcing them down an often painful password-reset process. Surely only recommended on busy sites, or those with highly sensitive information (such as ebanking)

    “Require a strong username that includes a numeric character. Often the username is the easiest portion of the login credentials for a hacker to guess. Do not use the user’s email address as their username.”
    As above, if your site isn’t one that the user logs into regularly, the chances of them remembering a username instead of just using their email address is slim. I have numerous sites that I need to log into occasionally (mobile phone operator, satellite TV, gas and electric provider) and some force usernames on me, others email addresses. The username ones I always struggle to log into because they have these different definitions of what an acceptable username is, or what was available at the time. Usernames are great for sites such as discussion forums, where you need an avatar and to protect your email address from the prying public, but otherwise I prefer to use email addresses as usernames. Of course, on forums, your usename is easy to see, so it makes more sense there to log a user in with an email address that is not being displayed hundreds of times around the site. As for forcing numbers into usernames; this creates an additional world of pain and will put most users off of signing up. I’d much rather use a simple username (if an email address is unavoidable) and consider an additional step, such as confirming a couple of letters from a pre-determined secret word if required

    “Limit the number of failed login attempts to three and temporarily suspend account access unless the user can authenticate through other means.”
    This I DO completely agree with, and in some cases (PCI environments, for example) only an administrator should be able to reactivate once suspended. However, this only addresses front-end security and not the back-end data that has been compromised in the Sony/LinkedIn examples

    “If the login fails, don’t identify which portion of the credentials was incorrect. Stating that the ‘password is incorrect’ or the ‘username doesn’t exist’ enables hackers to harvest account information. A general statement such as “Incorrect login, please try again” helps prevent account harvesting.”
    I’d rather aid account harvesting than provide vague error messages to the user. Usability always recommends that you highlight where you’ve gone wrong. I could be trying loads of different passwords, trying to log in, only to lock someone else’s account because I didn’t realise that my username on this site was actually “anthony2″ and not “anthony1″, because someone decided that letting me log in with my email address as a username was a bad idea. In fact, I’ve recently given up with a website because I needed to reset a password and it asks for my email address and username to reset. I only know the email address associated with it, so now I can’t get in and spend the credit that I already have. Too complicated! The only exception would be where you may need to use sensitive data to log in, such as a bank card number. I wouldn’t want to confirm that this was correct or not as part of the process of signing in

    “Use SSL to create an encrypted link between your server and the user’s web browser during account enrolment, the login process and the password reset process.”
    Agreed. Can’t imagine many would disagree. SSL isn’t always an option to everyone though, especially not with a certificate signed by a public CA, such as Verisign

    “Provide users with advice on how to choose a strong username and password. Research shows that users do choose better passwords when given advice on how to do so. One option is to have a password strength meter built into the page.”
    Again, agree. But advise rather than force. If a user chooses to go against your advice then they need to accept the consequences. However, you may want to force higher restrictions on users with elevated privileges. Also, bear in mind that the more rigid your password policy, the easier it is to guess passwords. If you force a capital and a number, you can be pretty sure that instead of “password” being the most common password, that it will just become “Password1″ or “Passw0rd”. Add a symbol and it might just become “Passw0rd!”. These patterns are easily predicted for most users. Allowing the password to be anything at all can sometimes make it even harder to crack

    “Hash user passwords using bcrypt, scrypt, or other hash algorithms specifically designed to store passwords. Do not use SHA1, MD5 or other algorithms that were not designed for hashing passwords, as they are not secure.”
    Again, I completely agree. Personally I use bcrypt in PHP wherever possible. I especially like that we can increase rounds as computing power increases to make it more difficult for anyone to calculate passwords should our database be compromised. In PHP there is also no choice but to salt bcrypt’d passwords

    “Use Salt. Use a unique salt for each user account/password and store that salt with the password. An additional layer of system wide salt that is not stored with the password can also add extra strength if the database is stolen because it is not stored with the passwords but is known to you.”
    Also agree

    There is always a trade-off between making the most secure system, and making a usable system. For MOST sites, it’s more important to make them usable and therefore much of these recommendations will go out of the window. It’s common sense and that would explain why CU find that most sites don’t meet these minimum recommendations. They’re theoretically great, but in practice just add too many barriers, and in this world of high-competition online, the more challenges you throw in front of the user, the less likely they are to ever sign up, never mind come back again. In fact, some of the best signup forms I’ve ever seen ask only for your email address, and you’re signed up. A password is sent to you and you can change it, of course, but no barriers. No complicated signup. And if you want to reset your account? Just give them your email address again. Perfectly acceptable for most sites.

  • Graham Bradley

    “Require a strong username that includes a numeric character.”

    How does this preserve the user experience? Adding hints for strong credentials is great, but restrictions like this, which appear arbitrary to the user, caused a large number of our users to either forget their username or abandom signup completely.

  • http://Microdisk.com Jeff Safire

    Thanks for this valuable info. But, why is MD5 not secure for hashing passwords?

  • http://www.xoogu.com/ Dave

    I agree with Anthony, especially on the point about telling the user whether they got their username or password wrong. Websites that force you to guess what information you got wrong are very annoying.

  • vicky

    how does blind screen reader users solve “image-based and graphical approaches. Increasingly users are asked to draw a pattern, touch points on a picture or identify a series of secret images to authenticate.”