Rory.Blog

Risk Assessed Password Policies - Password Strength

The next stop in my trip through password policies and some of the mistakes that are made is password strength (length and complexity).

It seems that for a lot of IT and IT Security people, there's one inevitable truth about password strength which is you can't have too strong passwords.

Unfortunately not true.

Like any security control password strength should reflect the environment that the system is deployed in and the likely threats it will face.

For most circumstances my feeling is that any password over about 9 characters with Upper and lower case alpha and numeric characters is overkill.

For this to be the case I'd say that the password should not be sent across the network in the clear either as plain text or a straight hashed value and should be stored in place in a salted-hash.

If you consider the threats, this will usually be more than adequate.

1. Online Brute-Force. This attack isn't best mitigated by password strength. Account lockout and alerting are a much better way to deal with this. For online systems I saw an interesting twist on this which was to only lockout the ip address the attack comes from as a mitigation of the DoS potential
2. Rainbow Table. The primary mitigation for this is to use salted hashes, as they mitigate this pretty effectively. However where that's not a possibility (off-the-shelf software) consider disk space required for the tables and the time to calculate. I've not seen any tables that go much beyond 7-8, and indeed one estimate I saw for 7-9 character passwords was that it would require 135000GB of space!
3. Offline Hash attack. This one is wheeled out a lot by advocates of extremely long passwords. One point I'd make is that in many scenarios if the attacker already has access to your password database, he's probably already broken in to your system pretty effectively! However even so, it's worth considering. Offline password guessing is done either through (hyrbid)dictionary attacks or straight brute-force. For brute force my experience has been that even with modern kit it gets too long to be practical for most attackers beyond about 8 characters. Dictionary attacks work very well if users choose dictionary password so it's worth investing in education/auditing to discourage this

So what does all that leave you with ... Well all of these attacks are reasonably mitigated in typical scenarios with 9 character passwords. Only problem is most people can't reliably remember 9 chunks of totally random information, so the key is to reduce the number of chunks whilst keeping up the number of characters.

There's a number of ways of doing this but things like passphrases like "414 million for that? We was robbed" are easy to remember (especially if you're Scottish) but very difficult to crack.

Risk Assessed Password Policies - Overview

I jumped in earlier talking about password rotation policies without actually mentioning why I think password policies are so important, so I'll back up and cover that now.

The use of passwords as authenticators for computer systems has been around for a very long time, and for quite some period the security industry has had a focus on reducing their use, as their shortcomings have been well known. Single sign-on, identity management, two factor authentication etc etc have been themes for quite a while.

But here's the thing, passwords aren't going away, in fact I'd say that their usage is increasing.

At home we've got a hugely increasing number of websites offering us services, from social networking sites like Facebook and myspace to forum sites to e-commerce sites, and all of them use passwords (usually not integrated with any over-arching identity management system)

At work, there's the rise of application service providers and "software as a service" which leads to company staff accessing external websites for business purposes, again usually without identity management support...

So it means that getting your password policy right is actually getting more important.

The problem I've seen is that many companies don't actually risk assess their password policies. They set one level for users and one for "super users" regardless of the system location and other controls. Combined with that you get "best practice" principles that seem really inappropriate for most systems and it can be quite a mess....

Over a series of posts I'll look at some examples of where password policies could do with some attention, any feedback/comments welcome :)

Risk Assessed Password Policies - Password Rotation

I've been meaning to blog about some of the reading I've been doing recently on password policies, but an article in the latest Insecure Magazine tipped me over the edge into writing..

In the article on password management on page 59 the author mentions some elements of a "best practices" password policy which include password rotation every 30 days as a good thing.

I've seen this repeated in many places but I'm not sure where it came from. My opinion is that, in many cases, 30 day password rotation is actually a very bad thing, both from a user experience point of view and also from a security point of view. It's one of those things that gets put in password policies without any real thought of the consequences.

The reasons I've seen stated for rotating passwords are

1. Mitigate password sharing. This doesn't really hold any water, if a user shares their password then they can just share the next one. A much better control is to educate the users never to share their password no matter who asks. This also has the side effect of helping mitigate some social engineering attacks
2. Reducing the window that someone has to crack a password hash. There may be some circumstances where this may help out but really who's to say that it'll be a specific number of days for a password crack. From my experience of auditing windows passwords, you either get it real quick with a hybrid dictionary attack or rainbow tables(in which case the rotation doesn't really help, or you don't get it at all (if you've set password length over about 9 characters most attackers won't be able to brute force a password with a decently designed algorithm. A better mitigation for this risk would be to ensure that password hashes are protected in transit (eg with SSL) and on hosts.

Also password rotation has several possible side-effects which actively reduce security

1. Sequence passwords. Most users when faced with a password rotation will choose a sequence password eg ([password1], [password2], etc), so once an attacker knows one password for the user, they'll pretty easily guess the next one.
2. Helpdesk password reset fatigue. Password rotation (along with some other aspects of password policies I'll come onto later) causes a large number of calls to a help desk. From a security standpoint, we want a password reset request to be an alert that someone is trying to attack one of our systems, but if the people being made aware of that alert (the helpdesk) are swarmed with "false positives" in the form of users forgetting their passwords, inevitably real alerts will be lost in the morass. In order to make password resets an effective control, we should be trying to minimize the number of times that the process is invoked (while maintaining the security of the password system obviously)

There are other elements of "classical" password policies that are just about as annoying, but I'll leave them for next time.

Appropriate trust on the Internet

There's an interesting story at The Register about the recent leaking of embassy credentials amongst others, by an individual in Sweden.

The story is that someone set up some Tor exit nodes and then sniffed the traffic that came out over them.

There's several interesting points that come out from this, I think.

• Understand the type of security provided by a system. Tor is not end-to-end encryption and you are trusting the exit node as you would trust an ISP router.
• What was done here can be done by any ISP employee. A Tor exit node is essentially like an ISP router. Anything that can be gained by sniffing a TOR exit node could also be gained by any employee of an ISP for the traffic that that ISP handles.
• Embassy users are logging on to their services in the clear!? The main problem here seems to be that embassy staff are logging on to e-mail systems in the clear over an untrusted network (the Internet). It seems odd that they'd go to the trouble of using Tor to anonymise their traffic but not go to the trouble of using SSL or an equivalent to protect their logon credentials end-to-end...