Password best practice and PasswordsCon13
I am shortly going to depart Las Vegas after 2 days and a slightly niche but incredibly important conference about passwords. Password Con only appeared on my radar relatively recently and since I was already heading from the UK to Canada, it was possible to travel a little further (in reality, twice as far!) and attend the small conference - conveniently timed to occur pre-DEFCON so that people would not have to make a special journey.
There were probably about 40-50 attendees but some of these are world-famous in the fields of password cracking. Some worked for businesses, others were self-employed/contractors, some appeared more academic and others, well they didn't seem to have much official capacity!
There were some very interesting talks about the very foundations of password theory - is there such a thing as a measure of a good password? Do corporate password policies really work? as well as more practical talks such as how to get the best out of choosing your "guesses" when using a cracker like hashcat.
To take a step back, if you are unfamiliar with passwords, ignoring the few sites that store the passwords in plain text (idiots), most sites perform a one-way function a.k.a. cryptographic hash or simply hash. The idea of this is that the password is no-longer readable and more importantly, you cannot feasibly compute what the original password is just from the hash. It's a bit like the number 670592745 which is easy to calculate from two factors but very hard to factorize back to what these two numbers are (they are 12345 and 54321). The arithmetic involved in these cryptographic hashes are similar in most cases, just MUCH, MUCH larger numbers. This is all great, in theory, but since the hash functions are necessarily public (so that people can check, test and implement them), rather than computing the password from the has, I can compute billions of hashes of known passwords and see if any of them match a password hash. When I say billions, some of these cracking machines can literally try billions of guesses per second.
Remember that most of the time, these machines are not trying to crack a single password specifically as much as many passwords from a big list. If I can crack 90% of a list of 100,000 hashed passwords then I can still use those to good effect (or bad effect). For this reason, even if my password is good, if most people's passwords are bad, then the damage is still done (but hopefully not to me).
Anyway, one of the things that became very obvious from the conference was that people 1) do not choose good passwords 2) Many sites do not adequately require and educate users on strong passwords 3) Even if a user is required to produce a strong password, it is almost always in one of a few standard patterns such as Uppercase, 7 x Lowercase and a number like Pineapple1976. The problem with these is that password crackers know these patterns, so they do not try to crack passwords starting at 0 and going up to ZZZZZZZZZZZ but select common patterns, which massively reduce the number of guesses required to find a lot of passwords. Just using something like Ulllllllnnnn can find 20% of most people's passwords in a few seconds!
So what's going on? It is clear that most sites are just doing their own thing because there is no-one really considered to be the authority on good passwords. Some sites will require that you do perhaps 3 out of 4 things things (upper case, numbers, symbols, lower case), others will require 1 or 2 of each type of "special characters". Some sites, shockingly allow the user to create 1 digit passwords! Although much of this is well meaning, many attempts to enforce policy result in users choosing bad passwords. If you have to change the password every 90 days, what do you think most people use as their password? xxxsummer, xxxautumn, xxxwinter etc. What happens if you require a capital and a number? Again Ulllllllnnnn. We actually find the same on PIN numbers that are very commonly 4 of the same digit or use the numbers 0-2!
Without a real understanding of how attackers hack passwords (which most people don't seem to have), you are trying to reinforce the front door while the attackers come into the back.
There were a couple of solutions. One had the idea that every leaked password became part of a blacklist on the basis that if the passwords were leaked, they would appear on an attacker's word list somewhere, which kind of makes sense but I can imagine would be very user-unfriendly. Another speaker stressed the importance of user education, even on the page where they have to choose a password - again, most of the top 10000 web sites don't do this. A colour-coded strength meter is better than a blunt policy, but again, what constitutes a good policy?
Password length, in general, is proportional to the strength of the password but if the password is still a dictionary word and a number (for instance), it is not a lot stronger than a shorter password since this is basic attack more. Using capitals and symbols is, again, better in a sense but if you swap your "a" for an @ sign in your password - they already know this and this is another attack vector. Passphrases can really help because they add length to a password but note that phrases from books are already known and can be easy to crack for this reason, as well as inserting something between words like a hyphen is fairly standard behaviour.
Remember that for the most part, the attacker will not usually want your password, just a number of passwords, so if you can make yours hard enough to crack, the attacker might give up. If you are a company or web site trying to create policy, you want everyone's password to be secure. So the following are bad things - if you can detect them, you could refuse them at account creation time - but remember that giving too much hassle to the user could lose you business:
There were probably about 40-50 attendees but some of these are world-famous in the fields of password cracking. Some worked for businesses, others were self-employed/contractors, some appeared more academic and others, well they didn't seem to have much official capacity!
There were some very interesting talks about the very foundations of password theory - is there such a thing as a measure of a good password? Do corporate password policies really work? as well as more practical talks such as how to get the best out of choosing your "guesses" when using a cracker like hashcat.
To take a step back, if you are unfamiliar with passwords, ignoring the few sites that store the passwords in plain text (idiots), most sites perform a one-way function a.k.a. cryptographic hash or simply hash. The idea of this is that the password is no-longer readable and more importantly, you cannot feasibly compute what the original password is just from the hash. It's a bit like the number 670592745 which is easy to calculate from two factors but very hard to factorize back to what these two numbers are (they are 12345 and 54321). The arithmetic involved in these cryptographic hashes are similar in most cases, just MUCH, MUCH larger numbers. This is all great, in theory, but since the hash functions are necessarily public (so that people can check, test and implement them), rather than computing the password from the has, I can compute billions of hashes of known passwords and see if any of them match a password hash. When I say billions, some of these cracking machines can literally try billions of guesses per second.
Remember that most of the time, these machines are not trying to crack a single password specifically as much as many passwords from a big list. If I can crack 90% of a list of 100,000 hashed passwords then I can still use those to good effect (or bad effect). For this reason, even if my password is good, if most people's passwords are bad, then the damage is still done (but hopefully not to me).
Anyway, one of the things that became very obvious from the conference was that people 1) do not choose good passwords 2) Many sites do not adequately require and educate users on strong passwords 3) Even if a user is required to produce a strong password, it is almost always in one of a few standard patterns such as Uppercase, 7 x Lowercase and a number like Pineapple1976. The problem with these is that password crackers know these patterns, so they do not try to crack passwords starting at 0 and going up to ZZZZZZZZZZZ but select common patterns, which massively reduce the number of guesses required to find a lot of passwords. Just using something like Ulllllllnnnn can find 20% of most people's passwords in a few seconds!
So what's going on? It is clear that most sites are just doing their own thing because there is no-one really considered to be the authority on good passwords. Some sites will require that you do perhaps 3 out of 4 things things (upper case, numbers, symbols, lower case), others will require 1 or 2 of each type of "special characters". Some sites, shockingly allow the user to create 1 digit passwords! Although much of this is well meaning, many attempts to enforce policy result in users choosing bad passwords. If you have to change the password every 90 days, what do you think most people use as their password? xxxsummer, xxxautumn, xxxwinter etc. What happens if you require a capital and a number? Again Ulllllllnnnn. We actually find the same on PIN numbers that are very commonly 4 of the same digit or use the numbers 0-2!
Without a real understanding of how attackers hack passwords (which most people don't seem to have), you are trying to reinforce the front door while the attackers come into the back.
There were a couple of solutions. One had the idea that every leaked password became part of a blacklist on the basis that if the passwords were leaked, they would appear on an attacker's word list somewhere, which kind of makes sense but I can imagine would be very user-unfriendly. Another speaker stressed the importance of user education, even on the page where they have to choose a password - again, most of the top 10000 web sites don't do this. A colour-coded strength meter is better than a blunt policy, but again, what constitutes a good policy?
Password length, in general, is proportional to the strength of the password but if the password is still a dictionary word and a number (for instance), it is not a lot stronger than a shorter password since this is basic attack more. Using capitals and symbols is, again, better in a sense but if you swap your "a" for an @ sign in your password - they already know this and this is another attack vector. Passphrases can really help because they add length to a password but note that phrases from books are already known and can be easy to crack for this reason, as well as inserting something between words like a hyphen is fairly standard behaviour.
Remember that for the most part, the attacker will not usually want your password, just a number of passwords, so if you can make yours hard enough to crack, the attacker might give up. If you are a company or web site trying to create policy, you want everyone's password to be secure. So the following are bad things - if you can detect them, you could refuse them at account creation time - but remember that giving too much hassle to the user could lose you business:
- short passwords - quick to brute force. Recommend at least 9 characters.
- all lower case - quick to brute force
- common patterns - Ulllllllnnnn, Ullllllln etc.
- Contain a single word that has been altered somehow to make it look less "standard" even when this word is slightly unusual/a place name etc.
- passwords that have appeared in the leaked lists - they will be in an attackers dictionary
- Leet speak - Using @ for a, 8 for b etc - these are already well known and will be used in brute-forcing attempts
- Passphrases from published works (including Bible book/chapter/verse), again much is already available to help crack these
- Passwords that contain social media searchable terms like names, parents, city where you live etc. One list for instance, contains all the first and last names of people from Facebook!
- Passwords that contain terms related to your business that can be easily derived from websites, LinkedIn profiles etc. This is more important for corporate passwords.
- Passwords used on multiple sites! Unless you share passwords only for weak/unimportant web sites, it only takes one crack to expose many of your accounts to hacking.
- Passwords that use keyboard patterns such as 1234, qwert, asdf etc.
- Long - but only if they do not break the above rules
- Random/Pseudo Random - These would only be crackable by a long-running brute force attack which is rarely carried out due to time constraints. If these are hard to remember (which they are) then use a password manager where possible.
- Passphrases that are unusual or guaranteed not to be found in any literature, such as, "My dog Ate a wonderful frisbee and had to visit the airport". Of course, the site has to allow long passwords and some, for bad reasons, do not.
- Typos - deliberately spelling things wrongly can sometimes help but various attack vectors attempt to mangle words so this is of limited help by itself - depending on the word.
- Using the first letters of a weird an unusual phrase - adding up to at least 10 characters or more preferably which makes, effectively, a random password that is easier to remember. For instance, the example in the passphrase in 3) could instead be entered as MdAawfahtvta.
- None standard patterns. For example, instead of Password123Password123, you could instead use pass8993WOrdp1a1s2s3w4o5r6d6
- Never, never, never use a database admin account to connect from your web application to the database. Don't even do this during development, you create the chance to deploy it this way accidentally.
- Always, always, always sanitise input from the user. Every input text field should have some form of validation, such as alphanumeric, max length etc. Work on what is allowed, not what isn't.
- Do your homework, do you know what characters an email can contain? Do you have a correct regular expression to validate this? Do you know if you are using a simple regular expression which might not correctly handle edge cases?
- Use a more modern hash algorithm or something like bcrypt or scrypt which are purposefully slow. These do not prevent attackers cracking passwords but can slow them down noticeably.
- NEVER create your own hash functions or variations on existing functions. At best, you will add no additional security, at worst, you will either make it much weaker or allow the attacker to optimise their attack while the defender incurs a lot of CPU/Memory overhead.
- Just because you use a framework like PHP, Ruby or .Net does not mean that their functions are necessarily good or appropriate. PHP have only just included password hashing functions in the framework, the previous options were either weak or complicated.
- If possible, access your database using stored procedures and a user account that only has execute privilege. This way, even a cracked website can do little harm.
- Try not to re-invent things that already exist. If you write your own password policy, for instance, you could miss something important or make a simple coding error that would make it ineffective.
- If your site is important, pay someone to test/verify it/pen test it independently. Don't expect everything for cheap or free.
- Have an easy way to report security failures and respond to them quickly and effectively, your reputation is important and even major failures can be survived if your response is appropriate.
- Make sure you have the means to reset passwords/contact users etc so that a breach can be notified quickly.