Wednesday 30 March 2011

The ghost of password future

I was reading about Pico and it raised an excellent point regarding the recommended length of passwords that got me thinking about the long term feasibility of passwords.  For as long as I have been in the security industry (just over a decade) an 8 character password (involving 3 character sets) has been considered, in rough terms, 'good enough'.  The reason that 8 characters is 'good enough' is if you do the math on how long it would take to brute force then the resulting time it would take is 'long enough'.

So what about Moore's Law?  Moore's Law says that we will double the number of computations every 18 months (the actual law is transistor count every 2 years), and these days the law relies on multiprocessor cores in order to be true (which is fine for this discussion since brute forcing passwords can be done in parallel). 

So according to Moore's Law, we need to increase the length of passwords by 1 bit every 18 months to keep constant the time it would take to brute force a password.  Unfortunately we use 8 bit bytes to represent characters in passwords (actually only 7 bits are used).  So this means every 10.5 years (7 bits x 1.5 years), call it a decade,  we need to add a another character to our passwords in order to protect them from brute-forcing. 

So in 2050 the recommended password length will be 13 characters.

A quick Google did not reveal a definitive answer to the length of password that people can typically remember, but I don't think it's a stretch to go with; shorter easier, longer harder.

So what does the future hold for passwords?  It looks pretty grim.  The length of passwords will need to go up, but our ability to remember long strings of characters is unlikely to change.  People will do what they always do and find a way to satisfy the password length requirement by creating a password that is easy to remember but which does not necessarily gain any security benefit from being longer.

[I have glossed over many of the technical details of brute-forcing, Moore's Law, processor power, character sets, etc. because I wanted to focus the point of the post on the fact that password lengths seemingly must get longer.]

Saturday 12 March 2011

Password changing needs to change

Companies tell people they need to change their passwords but I think companies are the ones who need to change. 

In many enterprises users must change their passwords every 3 months or so.  When was the last time a website asked you to change your password?  What about your banking website, how often do they tell you to change your password?  It's funny isn't it, there seems to be a real double standard about changing passwords.

So why do companies tell people to change their passwords?  Well the thinking is that if you change your password then if it has been exposed at some stage you have minimised the opportunity to brute force it, and if cracked then you minimise the opportunity to use it.  You can't really argue with the logic, those are sensible reasons to change you password.

What you can argue with is why is the burden on users to mitigate the risks of their password being exposed?  The answer is clearly that we don't have any other good mitigations to those risks other than users changing passwords.  Hold on ... we just established that websites don't make users change their passwords, so websites are either mitigating the risk or accepting it.  So who is right, the companies or the websites?

Well as much as I would like to argue the merits of the security of either approach, or have a detailed discussion of risk as a function of the assets the passwords are protecting, I think I would be missing the point.  Websites don't ask users to change passwords because it's a usability issue, it would put too much burden on the user and that might drive the user to a competitors website.  Companies have a captive audience, and they aren't trying to make users happy, they are trying to secure business assets.

For some people this might be a perfectly reasonable justification, and clearly it is not without merit, but all decisions have consequences.  One of the consequences, and this is pretty common knowledge, when users have to change passwords they often choose related passwords, marginally different from their old one, so it is easy for them to remember.  The irony of this it circumvents the mitigation of changing passwords, as changing the password doesn't require the attacker to start from scratch again.

So what's the solution?  Well clearly there isn't a well known one otherwise more companies would be using it.  I think there is a lot that companies can learn from the web experience though:
  • Get users to use a local password manager, since their password never leaves their machine the risk of exposure is substantially minimised and the enterprise can still enforce a rule of changing passwords.  Moreover the quality to passwords used can be increased exponentially.  I'm not up to speed on password managers for the OS, but if they don't exist then someone out their should create the market for them.
  • Use mechanisms to identify the fraudulent use of passwords.  I'm not sure how mature this market is for systems within an intranet, but web sites have mechanisms, so there is at least some framework for new solutions.
  • Use Single Sign-On.  I'd be the first to admit that this can create more security issues if not implemented correctly, but done well it definitely helps minimise risk and is the ultimate in convenience for users.
 With most companies intranets resembling a mini-Internet of web applications it makes sense for companies to start incorporating some of the hard fought lessons web sites have learnt when it comes to the balance between usability and security.

Sunday 6 March 2011

XDP

I have just uploaded a project to google code that I have been working on, it is called XDP, which stands for eXtended Data Protection.  It is like the Microsoft DPAPI, except better!

Why is it better?  Well the DPAPI only lets you encrypt data locally to yourself or the machine, whereas XDP allows you to encrypt data to another local machine user or group, or if you are part of a Domain, you can encrypt to other Domain users and Domain groups.  What makes XDP different to other technologies like PGP or GPG is that, like the DPAPI, it does not require the user to worry about key management, as it uses the DPAPI to manage keys.  It is the only non-certificate method I know of to encrypt data to other people in a Domain environment.

Check it out at http://code.google.com/p/xdp/.

Feedback welcome!