1-616-874-7810 info@vdalabs.com

One thing no security practitioner will argue with is that there has always been a struggle balancing security vs. ease of use when implementing technology solutions. In meeting after meeting a recurring them is “{This group} will never agree to doing that!”. Thanks to my previous experience working in software design and development, I find that I am particularly attuned to the impact that security decisions have on end user experience. Given this background, I have recently had the following question on my mind – “security vs. ease of use – do we have to fight?”

In this post we will be discussing the user impact of security decisions within the context of password policies, and how it is possible to design solutions that are a win-win for both sides.

Passwords are Hard.

In case you haven’t seen it before, here is snippet of “top passwords” list from 2017 care of Fortune:

  1. 123456
  2. Password
  3. 12345678
  4. qwerty
  5. 12345

Does that make you sad? Let’s get more specific – here are some top password formats we see when conducting penetration tests against “Client Companies” (in no specific order):

  • [Season]18
  • [Season]2018
  • [Season]2018!
  • [Month]18
  • [Month]2018
  • ClientCompanies123

You might be detecting a theme here – people are predictable, and they pick the easiest passwords they can. This is a problem for security, right? This is why we see organizations adopting password requirements around length and complexity. You can actually see the effects of this in the above examples. 12345 isn’t long enough, so the user chooses 123456 instead.

Password Complexity Done Bad

Most users will understand that you need complexity requirements that prohibit things as simple as 12345, so let’s say we want a minimum password length of 8. But as a security person, you might be thinking “hey! 8 characters isn’t secure enough alone, let’s add some complexity requirements as well!” So then you get together with your development team and the end result is a password policy like this:

Looks pretty good, right? The combination of 8+ characters including at least one number, 1 uppercase letter, and 1 lowercase letter does make this policy at least somewhat ahead of the norm. But what is being overlooked here is the ease of use from the customer’s perspective. This policy is actively user-hostile in three ways:

  1. The arbitrary 20 character maximum length limit – why prevent someone from using a longer password (or phrase) if they want to?
  2. Special characters allowed… but not these! (@ and <) – this just adds to confusion because at that point, how would someone know what qualifies as a special character? Then the random restrictions make using a password manager a hassle.
  3. Special characters allowed… but not too many!! Why would having more than 3 special characters make a password bad? This also seems incredibly arbitrary and also causes problems for password managers.

These restrictions make it much harder for a user to come up with a password, and even more likely that they will choose bare-minimum, reusable, passwords that meet these requirements like “Password1”.

So – what does a user AND security friendly password policy look like?

Generally if we are looking for a password policy that balances both ease of use and security concerns, our recommendations would include the following guidelines:

  • Minimum password length of between 8-16 characters, depending on risk profile
  • Complexity requirements that are based on minimum entropy – hidden from the user. This could take the form of a traffic light, thermometer, or numeric score (5/10, or 50 of strength 100 required). The strength requirement would also depend on risk profile.
  • Encourage the use of pass phrases through an examples.
  • No arbitrary maximum length or character restrictions!
  • Encourage (or require, depending on risk profile) the use of 2FA.
  • (Extra Credit) actively block passwords based on dictionary words and / or ‘most common passwords’ lists.

Some of these suggestions definitely take more onus on to the technology side for implementation, but with something as important as account security, it is critical to get it right and not frustrate users as much as possible.

Other Considerations – Password Managers

Password managers are another way that users cope with having heightened security needs (and password complexity requirements). A password manager allows a user to remember a single password to unlock the ‘vault’, and then the passwords inside can be arbitrarily complex. This is great for security provided that the vault password is kept safe. It’s incredibly hard to believe, however, that some organizations actively prohibit the use of password managers. This is done by disabling copy-and-paste and other tactics. This is again user-hostile, and really counter to proper security.

What about 2FA?

At the end of the day, however, passwords are hard and even with the use of a password manager, there will still be security issues. Add to that users generally having more and more passwords over time, and not everyone is using password managers, and that is a recipe for password reuse (and disasters). So what can be done about this? One of the best ways to overcome password related problems is through the use of 2 factor authentication (2FA). 2FA adds a second factor to the authentication process, and while that is a burden on users, in many cases that is understandable given the need for better security. A great example of ding this well is how Google handles 2FA on Android devices using Gsuite apps – it works so well, and automatically.

The other good thing about 2FA lately is that certain types of providers have been starting to require it, even without the user being aware. That means that users are slowly becoming accustomed to using these solutions, and so seeing them rolled out to other areas should become less of a surprise. That will be great for security, but what if we could remove passwords from the equation?

Ok – let’s just ditch passwords all together!

VDA is constantly looking for ways to add security that are a win-win for both user experience and security. That is why lately we have been interested in developments around a new standard for the web called Webauthen (link to _highly technical_ spec details). Webauthen will allow for websites (and other services) to completely remove the need for passwords. Instead replacing it with a form of public key authentication backed by cryptographically secure hardware, such as that used on a phone for biometric logon or a security token.

This could potentially be a huge win for both usability and security. A user may only need to use their phone to accept a login, and that login would be very robust from a security perspective. These are the kind of win-win’s we like to see, so we are hopeful that this technology will take off in the near future.