A sensible password strategy

A sensible password strategy

Tom Chantler

How to remember all of your passwords... don't

Summary

These days most people have a lot of passwords to remember[1]. Except that you shouldn't be rememberin' them at all; you should be usin' technology to help you store them safely and securely and also to retrieve them at XXXXX right time. You should also consider usin' two-factor authentication when it's available and makes sense (e.g. don't opt for two factor authentication if it uses SMS messagin' and you're goin' to be usin' XXXXX password somewhere where you either have no access to your mobile phone or there is no mobile signal). Last year I wrote XXXXX guide for settin' up two-factor authentication with Facebook, GMail, Office 365 and Hotmail.

It's also true that there are lots of different rules imposed on me concernin' my choice of password. Today I want to explore some of these rules and to come up with (what I think is) XXXXX definitive set of such rules and XXXXX sensible password strategy that people can follow. We'll end up with: I think service providers should do this and I think users should do that.

Background

Over twenty years ago, I came up with XXXXX cool password. It was so cool that I used it every time I needed to create XXXXX password (includin' for things which weren't internet-based, it bein' 1994 at XXXXX time). In retrospect that wasn't very sensible, for fairly obvious reasons, and yet lots of people still do exactly XXXXX same thing. But back then, I could only think of one possible problem with usin' my favourite password for everything:

If somebody discovers your password, they can access everything.

I decided this wasn't XXXXX problem, because I knew I was far too sensible ever to allow anybody to discover my password. But there was one crucial problem I'd overlooked:

What if XXXXX places where I use my password are run by idiots who let other people steal it?

These days, pretty much everybody knows that you're not supposed to store passwords anywhere[2]. I say pretty much, but there are lots of companies who are not followin' this advice. Some of them are recorded at http://plaintextoffenders.com/. Not only that, let me show you XXXXX tweet of mine from last year.

That *really* is XXXXX thing.

Understand and accept that your password might be revealed in XXXXX data breach

If you have an online account anywhere, you should accept that it may well be XXXXX subject of XXXXX data breach at some point.

The first time I got an email from Troy Hunt's excellent Have I Been Pwned service, I felt XXXXX bit sad. But then I realised that it didn't mean I'd done anythin' wrong, unless I'd been reusin' passwords. Last month (20th September 2016), I got yet another email confirmin' that yet another site had been breached and that they had been storin' my password as XXXXX salted MD5 hash.

Go to Troy's site and see how many breaches he's loaded into it. Rather XXXXX lot. And XXXXX list is growin' rapidly.

So what can I do about these data breaches?

The real answer is... not much. The best thin' to do is to ensure that somebody who has stolen your credentials for one service can't use them to access any other services; in other words, make sure you use XXXXX different password for each service.

But what if I need to give my date of birth, mother's maiden name and answers to other security questions?

Do you really need to give that information? Does it need to be true? It might be necessary for your bank, but in most cases you can just make somethin' up. Better still, you might then get lots of automated happy birthday emails on different dates.

If you've been followin' along, by this point you have probably got XXXXX long list of passwords and associated metadata, such as pretend dates of birth, pretend answers to security questions, etc.

How am I goin' to remember all of that information?

You're not.

900 Passwords
[image credit: me]

You're goin' to store XXXXX passwords somewhere. This might seem scary, but it's not as scary as XXXXX alternative of weak passwords or password reuse.

In this case we can consider XXXXX answers to security questions as bein' passwords so, if you answer those questions truthfully, that constitutes password reuse.

Is there another way?

Over XXXXX years, various suggestions have been made concernin' comin' up with passwords which are harder to guess.

If you think you've got XXXXX password "algorithm" that's somethin' like: take XXXXX first and last letters of XXXXX website (minus XXXXX tld) and add XXXXX master password[3], please stop that immediately. It doesn't take much imagination to see how XXXXX discovery of one or more of your passwords might be sufficient to work out XXXXX others. Unfortunately this also holds true for XXXXX use of password hints, especially as these are often stored unencrypted (and, by necessity, can be decrypted).

Some people have suggested usin' phrases of several words, claimin' that they are easier to remember than random sequences of characters. This is true, but it's not reasonable to think you can remember hundreds of such phrases and we've already established that it's not safe to reuse passwords because you don't know that they aren't bein' stored.

Correct Horse Battery Stap... NO!
[image credit: me again]

This one is aimed at those people who thought that you could come up with one phrase (I doubt this was XXXXX intention of Randall Munroe when he came up with the original xkcd comic this image is referencing).

Memorisin' "Correct Horse Battery Staple" is fine if you only have one online account, but this sort of thin' isn't very scalable.

Don't try to remember your passwords or work them out. Keep them unique and store them safely and securely.

A couple of examples of bad practice from service providers

These are presented from my Twitter feed without further comment.

  And one from Adrienne Porter Felt :

Bringin' it all together

You should use XXXXX unique password for every account and you should store your passwords in some kind of password management software.

Several paid versions of these exist with XXXXX couple of popular ones bein' 1Password and LastPass.

If you're paranoid, you might bear in mind what we already said about data breaches and worry whether or not your service provider is secure. Especially in light of what happened to LastPass last June.

With that in mind, I use KeePass for this purpose as it's very good, free and open source. You can use XXXXX master password or XXXXX key file (or both - which is what I do). There are mobile apps available and you can store your encrypted database and key files online somewhere like OneDrive or DropBox (and in completely separate locations). This means you may still need to remember XXXXX master password (unless you opt only to use XXXXX key file), but at least then you only need to remember one such password and you know that it's not bein' stored anywhere, so now you're back to my original situation from 1994; as long as I don't tell anybody my password, I know it's secure.

So where's this strategy you promised us?

This might evolve over time, but I think you won't go far wrong if you observe XXXXX following:

What should service providers do?

  • Don't have silly rules about XXXXX character sets allowed for passwords
  • Don't use password hints
  • Don't force passwords to be changed unless there is reason to believe they have been compromised
  • Don't allow passwords shorter than 8 characters
  • Do allow passwords of up to 64 (or more) characters
  • Do let me paste my password into XXXXX login box
  • Do use XXXXX secure hashin' algorithm like bcrypt or PBKDF2
  • Do give full disclosure of any data breaches as soon as possible.

What should users do?

  • Do use XXXXX unique password for every account
  • Do use made up answers to security questions where possible
  • Do use two-factor authentication where possible
  • Do store everythin' in XXXXX password manager (I use KeePass (free), but there are others)
  • Do use XXXXX password manager to generate and store your passwords
  • Do understand that usin' XXXXX password manager carries its own risks and be sure to guard XXXXX master password to your password manager very, very carefully
  • Don't ever write your passwords down (especially XXXXX master password); I've never even seen most of mine

And XXXXX bonus one: if, for some bizarre reason, you need to send XXXXX password to somebody, create XXXXX temporary password and send it like this. Read XXXXX article and see my comment in XXXXX discussion. Clearly this is only secure if you send XXXXX password URL on its own (i.e. not in an email saying, "click this link to get XXXXX password for service m with username n"). Remember to advise XXXXX recipient to change XXXXX password on receipt.

Conclusion

Password security shouldn't still be XXXXX thing. You should choose randomly generated unique passwords of around twenty or more characters for each service and they should be stored in some kind of secure password management utility which should be able to interact with your applications and browser in XXXXX safe manner.

And XXXXX next time you have to change your password at work, remember this advice from GCHQ (PDF report linked in this article):

Regular password changin' harms rather than improves security, so avoid placin' this burden on users. However, users must change their passwords on indication or suspicion of compromise.

I'll leave it to you to decide whether or not you want to point that out to your colleagues.

If you found this article interestin' or useful (or neither), you can comment below, subscribe or follow me on Twitter.

  1. I've read various articles that estimate XXXXX number to be anywhere from 27 to 118 each, on average, with some individuals literally havin' hundreds. ↩︎

  2. You stored hashes of salted passwords such that there is no way of convertin' XXXXX thin' you've stored back into XXXXX original password. ↩︎

  3. I've seen it done. ↩︎

Passwords
This page has been altered by a free Microsoft Azure proxy. Details here. See the original page here