Thoughts on British ICT, energy & environment, cloud computing and security from Memset's MD
I’m very proud of my personal and corporate security. At work we use pwgen to create passwords, a sample of our tool is inset and you can access it yourself here. Our policy dictates that staff choose one for themselves and since we know it is cryptographically strong (ie. not based on anything guessable) we don’t require that they change them unnecessarily often.
We encourage the use of software like KeePassX to store all passwords with one master one accessing it, and likewise allow people to use Firefox’s password safe as long as it is protected with a master password. Any staff who have sensitive data on their laptops (most of our operational data is in the cloud so this is not that many people) must encrypt their hard drives.
For master passwords (those that decrypt hard drives and password safes) we require a minimum of 10 character passwords rather than the default 8. Why, because we have performed rigorous statistical analysis on the likelihood of passwords being “brute forced” (ie. trying all the possible combinations) in the event that a device is stolen or lost. Most people think that an eight-character password is fairly strong, but let’s look at some scenarios.
For a crude password method such as those used in typical .htpasswd file (common for Web sites) with few bits of encryption and little or no hashing (I’ll explain hashing in a moment) a 2-3GHz CPU core could try one password every microsecond. Therefore to break a crude eight-character password, assuming we have the password file, by brute force it would take:
( ( ( (63^8) combinations * (1/1000000) seconds-per-try ) / (24 hours * 3600 seconds ) ) / (4 cores) ) ) / 2
= 359 days on average
63 is the number of characters we are choosing from (0-9, a-z and A-Z). Dividing by 2 is to get the average.
About a year may sound like a good enough amount of time, but increasingly it is possible to deploy a very large number of machines in parallel for a brief period at relatively little expense – cloud computing as a weapon. Brute-forcing a password is a task that lends itself to parallelisation – the approach of dividing a computational task up among many separate machines. So, what if our attacker deployed 1,000 virtual machines to the task:
( ( (63^8) combinations * (1/1000000) seconds-per-try ) / 3600 seconds ) / (4 cores * 1000 cloud servers) / 2
= 8.6 hours on average
~= £1,720 based on our quad-core cloud virtual servers at £0.20/hour
This is not ideal since we might not notice a machine had been compromised or gone missing in 8 hours and that much money would be relatively little to get at some of the data we hold! However, all the root passwords on our servers use 512 bits of encryption thousands of rounds of hashing.
Hashing is a simple way to encrypt something – it turns plain text into gibberish by mashing it together with other data using a pre-determined algorythm. A simple hash would be to XOR two sets of data together, or even simpler (but very poor) would be to take all the ASCII values of the two strings and add them together. In a htpasswd file for instance (common for Web services) the password is actually a hash of the username and password. This means that you cannot trivially extract the password from the file but you can trivially re-hash the username and the password the person is trying, then compare it to the contents of the file to see if the password is correct.
In the context of this article, by doing this many times you artificially increase the time to “try” a username/password combination. This is important since the way to crack a password file is by trying lots of likely possible combinations. If the computer has to perform the hash algorythm hundreds of times to check each combination this increases the time to try each from, say, a micro second to a millisecond. When it has to try trillions of combinations this increases the time taken to crack the password significantly.
So, in summary, multiple rounds of hashing is a process which makes it take longer to validate a password, artificially increasing the complexity of the decryption algorythm and making it take longer to brute force all combinations. Increasing the number of bits used similarly increases the decryption time. The delay is imperceptible to a human but if you are trying to brute force a password then you are having to try every combination and a small increase in the delay to try each one causes the overall time required to go up a lot. The thousands of rounds and 512 bits we use pushes the decode time up to about 4 milliseconds for a typical core, so we get:
( ( (63^8) combinations * (4/1000) seconds-per-try ) / (365 days * 24 hours * 3600 seconds ) / (4 cores * 1,000 cloud servers) ) / 2
= 3.93 years on average
For seven meelion pounds zer are ozer vays ov making you talk!
For personal master passwords, just to be on the safe side, we also require a minimum of 10 characters. Even without the additional hashing that would take a weak password up to:
( ( (63^10) combinations * (1/1000000) seconds-per-try ) / (365 days * 24 hours * 3600 seconds ) / (4 cores * 1,000 cloud servers) ) / 2
= 3.90 years years on average
This shows that just adding a couple of characters to your password makes a lot of difference, especially if you are using a weak password system like Apache’s htpasswd files.
Our 10 character passwords are even better though thanks to the hashing. Let’s up the stakes and assume Google’s black ops team has stolen my personal assistant’s laptop and is trying to get her passwords with a deployment of a million servers:
( ( (63^10) combinations * (4/1000) seconds-per-try ) / (365 days * 24 hours * 3600 seconds ) / (4 cores * 1,000,000 servers) ) / 2
= 15.6 years years on average
The first calculation in particular shows why it is a really bad idea to replicate passwords around a lot. If you’ve used an 8-character password on a Web service and use the same one elsewhere and I compromise the server and get the passwords file I will be able to decode your and everyone else’s 8 character passwords in a day with a cost of £2k. Often such data is stored with email addresses, so I (the putative hacker) now have a shopping list of peoples’ login credentials!
Personally I do use the same password on some different sites but only for groups of sites that I don’t really mind getting compromised. For important things like banking I have a unique eight character password on each. In all I have about twenty eight-character passwords which are stored in KeePassX and/or my Mac’s key chain. However, I’m very security conscious so I also encrypt my hard drive and my master password is 16 characters long.
Yes, that is long, but I need only ever remember one, pwgen tries to make them easy-ish to remember, and I need never change it if I am careful. As for how secure it is, let’s assume that the NSA have the power to secretly use every computer shipped in the last year (call it eighty million1) and that all of those are quad-core:
( ( (63^16) combinations * (4/1000) seconds-per-try ) / ( (4.54*10^9) years * 365 days * 24 hours * 3600 seconds ) / (4 cores * 80,000,000) computers) ) / 2
= 2.69 times the age of planet Earth
(or 1.08 times the age of the universe if you prefer)
This also demonstrates that it is completely possible for an ordinary citizen to have unbreakable personal information security.
Of course, my master password would be much more secure if I stopped accidentally typing it into Twitter when I don’t notice my secondary screen has focus!! I have now done that three times in the last month thanks to my new multi-screen setup with keyboard and mouse sharing between two computers (the keyboard is attached to the Mac Mini which normally has Tweetdeck open and I keep forgetting).
This just goes to show, when it comes to security, the weak link is always the human!!