Skip to content

Passwords Evolved: Authentication Guidance for the Modern Era

26/07/2017

Longer is (Usually) Stronger

Let’s get into the nuts and bolts of things and we’ll start with something easy: this is not a good password policy:

That first sentence in that pop-up is probably one of the most common poor password anti-patterns going, that is a short arbitrary length. It kills password managers (more on them soon), it kills pass phrases and subsequently, it kills usability. On that last point, the tweet above is from a 2016 blog post of mine on how we keep failing at the basics and along with Etihad’s bad policy (which incidentally, they allegedly do “because security”), I show how PayPal effectively locked me out of my account due to a similar policy.

So how long should you allow a password to be? No, not “as long as you want” because there is a size at which you have other problems. For example, at over 4MB you’d exceed the default ASP.NET max request size. Here’s NIST’s view:

Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length

No reasonable person is going to use a website with a 64-character password limit then turn around and say “this site’s security is crap because they didn’t let me use more than 64 characters in my password”. But just to be sure, make it 100. Or 200. Or stick with NIST’s thinking and make it 256, it doesn’t matter because it’s going to hash down to the same number of characters anyway.

NIST also makes another important if not obvious point when it comes to password length:

Truncation of the secret SHALL NOT be performed

This is really the simplest of concepts: don’t have a short arbitrary password length and don’t chop characters off the end of a password provided by a user. At the very least, an organisation defending this position should say “we know it’s bad, there’s legacy reasons, we’ll put it on the road map to be rectified”.

All Characters Are Special (But You Don’t Have to Have Special Characters)

I want to look at two different aspects of special characters and I’ll start with this one:

Typically, certain characters are disallowed as a means of defending against potential attacks. For example, angle brackets may be used in XSS attacks and an apostrophe may be used in SQL injection attacks. However, both of these arguments show serious shortcomings in the security profile of the site in question because firstly, passwords should never be re-displayed in the UI where an XSS risk could be exploited and secondly, because they should never be sent to the database without being hashed which would mean only alphanumeric characters prevail. Plus of course you have output encoding and parameterisation even if you were inappropriately handling passwords by re-displaying them in the UI and saving them in plain text to the database.

NIST is pretty clear on this – don’t do it:

All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.

It’s also worth noting their point on Unicode characters; there are many precedents of sites restricting perfectly valid language characters simply because they don’t fit into what a site’s developers consider “normal”. Then, of course, there are passwords like this:

The ❄️ 🌟 🔦 ⚪ on the mountain 🌙 🌠. 🙅🏻 a👣 to 🐝 👀. A 🏰 of 😢, and it 👀 like☝️️ the 👑. The 💨 is 🐺 like this 🌀 ❄️ ☔️ 🏠. 🙅🏻 keep it in, ☁️ 💡 ☝️️ tried.

If someone really wants to have a password that’s an emoji representation of the first verse of “Let It Go” from Frozen, good on ’em!

The other aspect of special characters is this from NIST:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets

Wait – what?! You mean people aren’t required to have lowercase, uppercase, numbers and symbols?! This goes against so much of conventional password wisdom and it’s not until you step back and think about it logically that it really makes sense. To demonstrate this, I recently wrote about how password strength indicators help people make ill-informed choices, the premise of which was that mathematics alone (which is what most password strength meters use), does not help us make strong passwords. Requirements such as these leave scope to use passwords such as “Passw0rd!” and rule out passwords such as lowercase passphrases.

Microsoft has precisely the same guidance as NIST in their aforementioned documentation:

Eliminate character-composition requirements

What tends to happen when there are requirements around password complexity is that people first try something basic then they tweak characters until it comes up to the minimum requirement of the site. Microsoft explains the problem as follows:

Most people use similar patterns (i.e. capital letter in the first position, a symbol in the last, and a number in the last 2). Cyber criminals know this, so they run their dictionary attacks using the common substitutions, such as “$” for “s”, “@” for “a,” “1” for “l” and so on.

This will almost certainly still be a bad password and almost certainly one they’ve previously used in other places too so all that’s been achieved here is that the user has been put through a level of frustration in order to still arrive at a bad password!

Password Hints Are Definitely Out

Anecdotally, password hints are far less frequent today than what they used to be. This was the premise of “hey, people forget passwords, let’s make it easier for them to remember” and it meant that at signup, as well as providing a password you could provide a hint as to what the password actually is. The problem is that this hint is shown to unauthenticated users because that’s the precisely the point at which it’s needed. The other problem is that because this is usually a user-provided piece of data, it’s probably going to be terrible.

Adobe stored password hints in their database that was disclosed back in 2013. Just to illustrate the terribleness of these hints, I went back to take a look at the data and thought I’d highlight a few of them here:

  • my name
  • adobe
  • usual
  • password
  • email

These were all stored in plain text too so think of what that meant once the system was compromised. For obvious reasons, NIST thinks these are a bad idea:

Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant.

Like I said, they’re rare to see in an online system these days anyway but just in case you were thinking about doing this, don’t!

Embrace Password Managers

I’ve been going on about the value of password managers for a long time now, since early 2011 actually when I wrote about how the only secure password is the one you can’t remember. The premise is simple and I’ll boil down to a few bullet points:

  1. We know that passwords must be “strong”, that is that they shouldn’t be predictable or readily brute forced so in other words, the longer and more random, the better.
  2. We know that passwords shouldn’t be reused because disclosure by one service puts the user’s other services at risk. This is the whole credential stuffing problem I referred to earlier.
  3. People cannot create strong, unique passwords across all their services using only their brain to remember which one they used where.

Now some people will argue that a password manager means putting all your eggs in one basket and they’re right; if that basket gets compromised it’s going to be bad news. But this is an exceptionally rare event compared to the compromise of an individual service which consequently exposes credentials. Further to that and as I wrote more recently, password managers don’t have to be perfect, they just have to be better than not having one.

But this post isn’t intended to provide guidance to individuals about how to secure their accounts, rather it’s aimed at people building services. This means that regardless of your personal views on password managers, you shouldn’t be doing this:

This is typical short-sightedness and I could easily point to dozens of other tweets of a similar nature. It entirely neglects the 3 bullet points I outlined earlier and what it’s essentially doing is saying “hey, create a password you can easily remember and yeah, it’ll be weak and probably the same as your other ones, but do it because security”.

The NCSC is quite explicit about this and has the following in the infographic accompanying their Password Guidance: Simplifying Your Approach resource:

Allow users to securely record and store their passwords

In other words, don’t break password managers and don’t trot out lines like in the tweet above. But the NCSC goes even further, providing the following recommendation targeted clearly at how organisations enable their staff to create and manage passwords in a secure fashion:

You should also provide appropriate facilities to store recorded passwords, with protection appropriate to the sensitivity of the information being secured. Storage could be physical (for example secure cabinets) or technical (such as password management software), or a combination of both. The important thing is that your organisation provides a sanctioned mechanism to help users manage passwords, as this will deter users from adopting insecure ‘hidden’ methods to manage password overload.

Have a think about the environment you work in at present – do they have password strength criteria? Do they possibly have annual training or posters on the wall, each encouraging unique and complex passwords? Inevitably there’s at least some control and education around this, but do they actually provide you with a “sanctioned mechanism” to help you achieve those objectives? Almost certainly not and I know this because it’s one of the questions I often ask when I run training in organisations. It’s amazing that this gap prevails.

Let Them Paste Passwords

Closely related to the use of password managers is the ability to paste passwords into the login screen. There are plenty of password managers that can auto-fill credentials, but there are occasions where either pasting is still necessary or where a service blocks a password that hasn’t been typed in character by character (easily identified with a bit of JavaScript). It means we have situations like this:

Back in 2014, I wrote about the “Cobra Effect” that is disabling paste on password fields. I explain the meaning of this term in the blog post but in short, a cobra effect occurs when an attempted solution to a problem makes the problem worse. When a website blocks the pasting of passwords in an attempt to improve security, they force some users to weaken their passwords to the point where they’re dumbed down to easily typed versions.

The NCSC is behind me on this one too:

Anti-password-pasting code on a wall

They even coined a term for the anti-pattern – SPP or “Stop Pasting Passwords” – and they go on to debunk common myths around the “risks” of pasting passwords. They also reference my cobra effect article mentioned earlier which is nice endorsement from the British Government!

NIST echoes the NCSC’s position with this statement:

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

Let there be no doubt about it: there is unanimous support from both sides of the Atlantic for encouraging the use of password managers as well as not actively blocking them.

Do Not Mandate Regular Password Changes

I had an easy way of remembering how long I’d been using a password for in my previous corporate job: I’d take the number in it that I incremented every time the company forced a quarterly password rotation and divide it by 4. I got about 6 years out of that particular password, only ever changing 1 or 2 characters at a time. If you’re working in an environment that mandates regular password changes, you’re very likely doing the same thing because it’s an easy human control to deal with a technology requirement that’s seen as an impediment.

Let’s think through the rationale of this approach for a moment: the premise of a regular password change is that should that password be compromised, forcing a change means it is no longer valid, ergo it cannot be used by malicious parties. The problem is, attackers have got up to 3 months in the example I gave earlier or in some cases, even longer:

Think about it: attackers don’t generally just sit around waiting, they get on with the business of exploiting accounts. This is the same flawed logic which led to Lifeboat covering up their breach last year based on the following screwy rationale:

When this happened [in] early January we figured the best thing for our players was to quietly force a password reset without letting the hackers know they had limited time to act

Per the tweet above, the NCSC agrees that forcibly rotating passwords is a modern-day security anti-pattern saying this about the practice in their password guidance documentation:

carries no real benefits as stolen passwords are generally exploited immediately

And it makes its way into the associated infographic too:

Only ask users to change their passwords on indication of suspicion of compromise

Microsoft is also on the same page here:

Password expiration policies do more harm than good, because these policies drive users to very predictable passwords composed of sequential words and numbers which are closely related to each other (that is, the next password can be predicted based on the previous password). Password change offers no containment benefits cyber criminals almost always use credentials as soon as they compromise them.

Now this is not to say “don’t force password cycling and do nothing else”, rather it’s a recognition that there should be a broader, more evolved approach to password management. For example, the NCSC also recommends the following:

  1. Monitoring logins to detect unusual use
  2. Notifying users with details of attempted logins, successful or unsuccessful; they should report any for which they were not responsible

Which brings us neatly to the next section:

Notify Users of Abnormal Behaviour

Reference:

https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: