Stop Trying To Kill The Password

I’ve seen a lot of reports in the last year that have been prompted by the massive password dumps on major websites. The focus of these reports has been about ‘killing passwords’ and replacing them with new technology. The thing is, passwords are actually great, and they don’t need to go anywhere.

First of all, passwords simply aren’t going anywhere. You’re not going to reinvent every websites authentication – we can barely convince sites to stop storing in plaintext, or use something other than MD5, so you’re absolutely not going to convince anyone to change their entire authentication method from the ground up.

On top of that… there’s just nothing wrong with passwords. Passwords on their own are kind of awesome, and, if used properly, way beyond most attacks. If you were to come up with a completely random 16 character password you could rest assured for the next wonderful couple hundred million years of your life you wouldn’t have to worry about anyone bruteforcing it.

The problem is that remembering something like L10F!E4d1I4U8Nhr is difficult, and remembering a unique password for every site is even harder, given that most people have at least a dozen websites that they log into.

So should we dump the password? Definitely not. We should instead move to password management systems, like LastPass, and implement two-factor auth on critical websites. This should have a very small effect on usability while having a very significant effect on security.

With a password manager like LastPass you don’t have to remember any of your passwords, so there’s no reason for you to use the same password twice, or use something easy to remember – you can very easily use 16 character random passwords for every site you visit. The only password you have to remember is your master password, and that’s the ‘point of failure’ that needs to be addressed.

Addressing that master password security is actually not so difficult. LastPass deals with it in two ways.

1) PBKDF2 rounds make bruteforcing far less useful, with a default of 5,000, and an incredibly high maximum value of 256,000. That means every single password attempt will take ~5,000x as long as a single password attempt. You can raise this number significantly to make even weaker passwords way too difficult to bruteforce.

2) Two-Factor Authentication means that even if an attacker has compromised your password they still need access to a physical device that’s used for authentication, such as an Android device, or a piece of paper.

So bruteforcing the master password just isn’t practical anymore, if you use even a slightly strong password with PBKDF2 and 2FA.

It’s dead easy to use and you can access it anywhere with internet connection (or use the Android App, which is great) and it would solve users reusing passwords, users using weak passwords, and other issues.

Of course, websites themselves should always assume the worst. They should always use PBKDF2 or bcrypt, and websites that store critical information should use 2 Factor Auth as well. But, for the users end of things, a password manager solves most issues.

So rather than scrap the most basic authentication mechanism used everywhere, just harden it. It’s not difficult.

Against User Education – In Depth

This post is meant to be a comprehensive overview of the costs and benefits of user education in an enterprise environment (though the same applies everywhere). I have talked time and time again about users not being educated, and why that’s the case. A very significant portion of my posts have been about this subject, and it seems that this subject has gotten a lot more popular in the last few weeks, so I’m going to make a post with definitive evidence.



The costs of a security technique are always to be considered. Sometimes the cost is performance overhead, downtime, annoying popups, money, whatever. Sometimes the costs are worth it, sometimes they aren’t, but they’re always going to be there.

So what are the costs of user education?

1) Time: Your IT staff is going to have to take time to meet with users, or at the very least write something up for them. As a single session is unlikely to be effective (more on this later) it’s more useful to have multiple sessions, and thus a significant amount of time is spent on user education.

2) Money: Your IT staff is getting paid either way. But what about the employees? They’ve got work to do – billable hours. An hour of IT is an hour you’re paying them to learn, and another hour taken away from their work. Is that a significant cost? Maybe, maybe not.

These are really the two costs for user training, as it’s not a software technique, and really just involves taking time to talk to someone. The issue is that it’ snot just the IT staff, which is paid for security, but it’s your everyday employee.



Simple Polices On Deaf Ears

The real meat here is the potential and perceived benefits of this training. This is less clear cut – it’s not a list of things users will or won’t do, but instead I’ll look at how likely your training was to be effective.

Let’s look at one of the simplest policies, probably a policy every company will try to enforce, and something we constantly try to teach users: use a strong password.

Do you know what we’ve learned from password dumps? It’s 2012 and these are still the most common passwords:



Yes, the top password from the Yahoo password dump is 123456, and the next one is “password”, followed by “welcome”. The advice to “use a strong password” is probably the most pervasive and consistent advice in the security community. Honestly, I think it’s the number one thing people will tell you to do, and that goes triple for a corporate environment, where passwords are critical.

And yet passwords have not improved. And I’m quite positive that if you look at a corporate environment you will find very similar results, but with the corporate policies ‘smushed’ on: password12!! instead of password, because someone decided to force them to use a number and symbol.

Users Don’t Care, And It’s Not Irrational

A Microsoft research paper explores why exactly users are incapable of following policies. Why is it that time and time again they don’t follow company advice, or so-called ‘common sense’? The answer is really very simple, and would surprise most people: they’re actually making entirely rational decisions.

Everyone performs rudimentary cost benefit analysis every day, for any task that requires a choice that will lead to a consequence. Should you have some ice cream? Go for a run? Study? Play video games? In our head we make simple assumptions like “well I can study, but it won’t be very fun, but it’ll pay off later” and come to a conclusion.

Users in a corporate environment are no different, you tell them to come up with a strong password and they ask themselves “I can use a strong password and something won’t happen, but I’ll absolutely have a hard time remembering it and it’ll be a pain to type”.

The key point here is that there are definitive and predictable costs and only theoretical consequences. A user is going to be annoyed having to retype their password 5 times. A strong password might prevent an attack.

So you have to convince your users that an attack is imminent and likely, and that the pressure is on them… to which I would imagine they’d ask why it’s their job and not yours.

It Wouldn’t Matter If They Cared

Even if your users could manage to care at all about the security of their systems more than how annoying long passwords are it very likely wouldn’t matter. That’s for two reasons:

1) You can’t get them all to care. If one user is exploited an attacker is on the network. Is the game lost? No. But if you expect user education to save you after this point, good luck.

2) They don’t know anything about computer security. Even if they did care about it, they’re incompetent in the subject. We already know they have zero clue about creating strong passwords, even when policies are enforced, so what makes you think that they’ll be able to do anything else better? They are very unlikely to know how to keep every single program up to date, how to generate strong passwords, how to verify a site is using TLS, how to differentiate between a malicious email and a legitimate one. Humans just aren’t good at that stuff, and you’re not going ot be able to teach it in a reasonable amount of time (again, assuming they care enough to learn, which they don’t).


So I’ve been meaning to write this for a while, and I write about this stuff a ton anyways, but then Schneier put somethign out and it got all this attention and I thought “Oh, look, people actually care.”

So there’s my two cents on the matter. You can see that passwords haven’t changed, you can understand why nothing has changed, and you can consider the potentially very significant costs of implementing user training, and ask yourself if you can’t find a better use for that time/ money.



Padding Passwords For Security

Common attacks on passwords involve bruteforcing and using pre-computed ‘rainbow tables’. Avoiding both of these attacks is fairly trivial – for both it’s a matter of length and an uncommon password. The issue is that remembering many different long passwords is difficult, which is where password padding comes in.

Password padding just means that you take your password and add one or two characters repeatedly. For example:

Password: Ninja

Padded Password: !!!Ninja!!!

Ninja is an incredibly common password, a dictionary attack will probably try it immediately. You’d be cracked in seconds. By adding !!! to both ends we’ve made a dictionary attack less likely, bruteforcing will take significantly longer, precomputed hashes are less likely to work, and it’s as easy to remember as Ninja.

Of course !!!Ninja!!! is still not a very secure password. While that padding is great for avoiding attacks it would still be susceptible to dictionary attacks if they decide to bruteforce the padding.  But attackers don’t get points for “close” – they can be one character away or a million and have no idea which.

Take any of your passwords and consider putting some padding on them. It’s a very simple way to improve password security without having to resort to memorizing incredibly long passwords.

Has Anyone Learned Anything?

You’ve probably heard that Yahoo was hacked. They were hacked through SQL Injection of all things (for those who don’t know SQL injection is kiddy stuff, I could do it and that’s saying a lot) and, to make matters so much worse, they stored the passwords in plaintext – no encryption, not so much as obfuscation. It’s pathetic. 

This is the same exact thing that happened to Sony (twice as I recall) years back. It’s what happened to another site just a few weeks ago. It’s what keeps happening over and over and over again.

Sanitize input. Encrypt passwords. Don’t use MD5.

And then there’s our users. Hundreds of thousands of users and these are the top passwords.


picture taken from sophos blog

The top passwords are all short and awful and the first thing anyone would guess in a dictionary. Except ninja – that’s still short and awful but I actually would not have guessed that so bravo whoever started that trend.

Seriously? How many people’s accounts have to be hacked before the public realizes that five characters is not enough. You can not get away with a five character password. You can not get away with a 6 or even 7 character password. 8 characters is the minimum.

Of course it isn’t the users fault Yahoo was hacked but I think it’s enlightening.

For good measure here’s my link to creating a strong password.