Whether it is an invisible ink note to a girl in middle school, coded messages to the guys in high school, or secret plans for taking down the government in college, secrecy has been important for thousands of years.
Julius Caesar used a shift cipher to encrypt military messages; Mary, Queen of Scots, was executed after her letter was intercepted and decrypted; and England’s Bletchley Park took on Germany’s World War II Enigma machine with the fate of the free world at stake. In each of these cases the encryption algorithm was eventually broken.
But what about passwords? Is there a way to keep them from being cracked? Password security is especially important when someone gets access to 150,000,000 of your accounts. Oops.
The first few sections below should be comprehensible by any reader, but it will get a little more technical as it goes on. But before you preemptively flee, there are some interesting tidbits throughout that will hold even the biggest technophobe’s attention (or at least feed their fears).
Password Security Basics
For those of you who are going to take off as soon as this gets slightly technical, please keep these password tips in mind:
1) Don’t include any of the following in your password:
“password” (or other version such as “p@ssw0rd”)
“123”
“asdf”
“qwerty”
site name + numbers
single words (even if they are long)
your username
2) Don’t reuse passwords across sites, because if the weakest site’s security is hacked, then all of your accounts may be insecure.
3) Use passwords of at least 10 characters, preferably longer. Random passwords managed through a password manager such as LastPass or Dashlane are the best option.
4) Include non-alphanumeric characters in your password, such as punctuation.
5) If you have the option to set a password hint, don’t. These values may be readable in the database, thus giving valuable information to a cracker as to how to break your password. (Or just put “32 random characters” to scare off any potential attacker.)
6) Whenever you click that “Send me my password” link and you get your original password in your inbox, be scared; your password isn’t as secure as it could be.
Security Lingo
But before you can talk about securing a password, you need to understand the lingo. Plaintext is the original, readable text that you want to secure, while ciphertext is the encoded version of this. To encrypt, or encode, something is to apply an algorithm, or cipher, that converts the plaintext into an unreadable format that is only understandable after decryption. This differs from a hash, which is a one-way function that is nearly impossible to invert. A brute force attack is an attempt to gain access to a system (or to decrypt a value) by trying every possible combination of values. The nice guys that try to figure out how things work are hackers, while crackers are the nasty guys trying to circumvent security and buy new computers with your credit card information.
Plaintext Passwords are Awesome (if you are on the side of evil)
In the past, password security in many systems wasn’t deemed vital. Or at least that is what I thought, as one of the early content management systems I worked with had plaintext passwords saved in the database. At the time our team shared common passwords, so if I forgot a password I could easily look it up in the database. But this was bad. Very bad.
One problem with having a plaintext password is that a system may have a much longer lifespan than anticipated, so over the years many people will have access to the database. This means that whenever someone needs to know what user accounts exist, they instantly see every password, whether they want to know them or not. So, even if I didn’t want to know that Jason’s password was “britneyspears123,” I would now know it. Knowing the current password also creates an issue because it gives me a sense of what future passwords may look like. When Jason’s interest changes to Katy Perry in the future, what are the odds that his new password is now “katyperry123?” Or even worse, what if this password is used for another account, such as a bank account? Integrity is vital for software engineers, but you never know when a wolf sneaks into the midst.
So, are you still encrypting that?
So, if we don’t want plaintext passwords, that means we want to encrypt the password. Right? Not exactly.
While strong ciphers exist today, such as Triple DES or AES, they are only strong for the time being. When DES was published in 1977, it was very secure, but by 1999 it was broken in 22 hours with a brute force attack. Today’s secure is tomorrow’s vulnerable.
Another important thing to note is that if a system or website can decrypt a password, then a malicious intruder also could gain access to this algorithm. In one fell swoop they would have every password, no matter how complicated.
Beyond keeping your password out of the hands of those nasty crackers, there is really no need to make it decryptable. Your password is private, and if you use it for multiple accounts (not recommended) then access to one means access to all accounts. And there is a pretty good chance that you have a Gmail, Yahoo, Facebook or Twitter account. Why make a password available when you can just as easily authenticate by comparing a hashed password to the saved version?
Hashing Your Password (and I don’t mean #password)
Hashing is here to save the day! Unlike encryption, knowing the algorithm and key doesn’t give you the keys to the kingdom. But hashing needs a few other elements first. Common hashes such as MD5 (1992) and SHA-1 (1995) are now considered insecure; MD5 was considered broken by 2008, while SHA-1 is not considered secure enough for continued use. So the first step is to select a secure hash function.
With a hash selected, we now need to prevent “123456” from equaling “123456.” What I mean is that we need to prevent users with the same password from having the same hash value. If we have 10,000 accounts and 500 of them have the same hash value, then there is a good chance that we can find it on the list of the top 25 passwords of 2013. To prevent this we add salt to each hash. Each record has a unique salt value that is combined with the password so that the hash value of “qwerty” for record 134 is different than “qwerty” for record 135. When salting the values, use an HMAC implementation, such as HMAC-SHA256, to better hash the values. This overcomes some of the weaknesses in the source hash, and results in less collisions (multiple values resulting in the same hash value).
Are we safe yet? Nope. Brute force attacks are still a problem. Given that relatively cheap modern hash cracking systems can hash billions of values per second, you can see that short passwords would be discovered very quickly. However, for a 12-character password, there are over 3,000 billion billion combinations using just letters and numbers. So really at this point we are trying to protect people from themselves, without forcing them to use a password manager.
Password
Length
Possible Combinations
(letters & numbers)
Time to Crack
1 Hash Iteration
Time to Crack
10,000 Hash Iterations
6
56.8 billion
0.3 seconds
0.8 hours
7
3,500 billion
18 seconds
2.1 days
8
218,000 billion
19 minutes
127 days
9
13.5 million billion
0.8 days
22 years
10
839 million billion
49 days
1,330 years
11
52 billion billion
8.5 years
83,000 years
12
3,226 billion billion
500 years
5 million years
The above table shows the average time to decrypt a password using a brute force attack (100 billion hashes/second)
To help protect users with shorter passwords, we want to slow down the rate at which crackers can test values. To do this we don’t hash a value one time, but thousands of times. Remember, we can do this very, very fast, so it doesn’t effect the end user when they are logging in. In the table above you can see that this change makes passwords of 8, 9 or 10 characters much less practical to break. Also, when iteratively hashing a value, use PBKDF2 rather than just recursively calling the HMAC hash. PBKDF2 is built to better mix the results of a hash into itself for even more security. (The number of iterations will need to be saved in the database, along with the hash and salt, so that the iteration can be increased in the future as computing speeds increase.)
Closing (or, “Allow me to Introduce you to my Interval”)
In summary: hash, don’t encrypt, make it salty, use a HMAC hash, and iterate using PBKDF2. Another thing to think about is enforcing intervals between login attempts. If you have a public login service, don’t give naughty people the ability to start trying any password they want. Force a 1+ second interval after each failed attempt, and every 10 failed attempts or so lock them out for a longer period.
Now get hashing!
The post Securing that P@ssw0rd appeared first on Andculture.