LRSWIW: A password scheme you can live with and is (probably) pretty secure

If you follow tech trends at all, you know passwords are under threat of becoming useless. Most commonly used passwords have been published on the internet to be used as “rainbow tables” and “dictionaries” for “brute force attacks”. These are basically long lists (some in the 10’s of millions) of passwords stolen from various websites around the world. Without being too technical, they are used to match passwords stolen from a newly compromised website against known password lists. We’re told use long passwords with random characters and never re-use a password on different websites. I don’t know about you but I probably have accounts set up at 50 or more websites. Long, random and unique passwords of 50+ sites? I’m getting too old for that. There are software “password vaults” that can help with this but I think I have come up with a pretty good scheme for decent security, that won’t be too difficult to use. Before I get to that a little background to help you understand what I’m proposing.

Cracking passwords is not what you think

For the most part, when people think about cracking passwords, they think of some hacker furiously typing some code to try and get access to a system while the clock ticks down to zero. (for an hilarious example click here and start typing random text http://hackertyper.net/) In reality, most password cracking is done “offline”. This means the bad guy gets access to a website or other corporate database, saves it to their system and runs password cracking programs at their leisure. No ticking clock, at least not if they’ve covered their tracks while getting the new database (or if they are in another country).

Getting a little technical, it’s important to know how passwords  are stored when you sign up with a website. You can skip to the bottom at any time if you just want to see the password scheme but I encourage you to read this to understand why it’s important.

Stored as plain text.

Very simply what you enter into the password field is saved to the database as text. When you go to log in next time, the website simply compares the text you enter with the text stored in the database. However, even if you enter the World’s Most Secure Password ™ , it will be there for all to see if the database is stolen. This is very bad but some websites still do it and you won’t ever know until your bank calls you.

 Stored as a One Way Hash

Hashing a password is a common way of securing passwords in a database. When you submit a password on a website, the software takes that text and turns it into a string of numbers and letters.

For example “password” becomes 5F4DCC3B5AA765D61D8327DEB882CF99

This string is then saved to the database. The thing about one way hashes at they can’t be “unencrypted”.  How then does the system know that when you enter “password” to log in next time, you really mean “5F4DCC3B5AA765D61D8327DEB882CF99”. It’s simple. While one way hashes are un-decryptable, they are always the same for as specific input text. The one way hash for “password” will -always- be “5F4DCC3B5AA765D61D8327DEB882CF99” The login software takes the text you input, hashes it again, and compares the new hashed value against the one stored in the database and lets you in if it matches.

input “password” + hash = “5F4DCC3B5AA765D61D8327DEB882CF99”  if  database hash = “5F4DCC3B5AA765D61D8327DEB882CF99” then allow login

The problem with simple one way hashes is exactly this property. No matter what website you log into the hash for “password” will always be the same. So will the hash value of the World’s Most Secure Password ™ (which is 1C84018561A5838CB47C776E07B0B0E0 in case you were wondering). What crackers have done is taken dictionaries, word lists and most damaging, stolen plain text password databases and created a giant hash list

• password = 5F4DCC3B5AA765D61D8327DEB882CF99
• qwerty = D8578EDF8458CE06FBC5BB76A58C5CA4
• LetMeIn = BC9D9CB353C87531F61D6F21D5CC072E
• World’s Most Secure Password ™ = 1C84018561A5838CB47C776E07B0B0E0

Now when they get a new hashed database they simply run a comparison against these known hashes.

email                                     password

buddy@example.com       D8578EDF8458CE06FBC5BB76A58C5CA4

Guess what? We now know Buddy’s password. Did Buddy use the same one for his bank? Oops!

Now maybe Buddy is smarter than using “qwerty” as a password. He’s been told to use a mix of letters, numbers and special characters. He also know that if your password is less than 8 characters, it will take a modern password cracking system less than 5 minutes to discover it – no matter how random it is.  So his password is:

Dadof3g8kids = A4334A757F1438814BD6B8AB89DE1B5E

While this looks pretty secure, there are 2 problems. First, if anyone else has used this password (and it’s actually a pretty common combination) on a compromised plain text database, then he’s immediately lost. The second is a little bit more technically involved and a few years ago wouldn’t have been feasible. However, with the immense computing power available now, these types of passwords are no longer secure. Basically you dump the password into a very fast computer (or clusters of computers like Amazon Web Services) and try every possible combination of numbers and letters. Because “dad”, “of” and “kids”  are very common words, they exist in dictionary tables and these are tried first, making the time it takes to discover the hash much shorter. New systems can check -billions- of hashes per second.

Stored as a One Way Hash with Salt

“Salting” a hash improves security because it adds a degree of randomness to the hash. When the hash is first created an additional hash sequence of random text is added.

password = “password” = 5F4DCC3B5AA765D61D8327DEB882CF99

salt = “some text” = 552E21CD4CD9918678E3C1A0DF491BC3

hash of salt + hash = C53F71D82F81AED989D4FCA89E2959B4

So now instead of storing password 5F4DCC3B5AA765D61D8327DEB882CF99 we store C53F71D82F81AED989D4FCA89E2959B4 which helps defeat the simple comparison lookup we saw earlier. However crackers are smart and they have several techniques to figure out what the Salt is. This is pretty simple if the website uses the same salt for every hashed password. It’s also possible (although more difficult) if the salt is short or not random.

For my websites I use Hash(GenerateSecretKey(“AES”), “SHA-512”) This generates a salt that looks like

BD7AD5F852AA8B41BB6FC2CFD671AC1157F7F8447FEF4115BE53CE7B5F403E1201444DFFE54E35D2214B4647E994819B7818DA9AFB7150B26DA35CB306E7A30E

When we combine the Hashed password with the hashed Salt and hash the result. we get a resulting hash that is reasonably secure.

Long, Random and Unique – How do you manage it?

Ok, so here is my scheme. It’s simply not feasible to remember 50+ long, random & unique passwords and yet as we have seen, it’s so important. What I’ve been doing for a while now is what I call the

LRSWIW (Long Random String with website identification word)

Make up a random string of characters like

A7b546!pk*Bt

Memorize it! At 12 random characters it will already be difficult to crack (at least on sites using proper hashing techniques). If you want to be more secure create a longer one.

Then when you create a password on a website, use that string and add some type of reminder text (WIW) to the password that is specific to that website and do that for every website. IF the site allows you, separate the string from the WIW with a space as this makes things even more secure.

A7b546!pk*Bt myBank = 7927D4FE45FE29C56DE2BDFA50870DEB

A7b546!pk*Bt myEmail = 45F2EA292F3AB21E54C6453E2BD14C82

A7b546!pk*Bt FaceBook = C07EC75E2F284E582D29A054DB8EB81D

A7b546!pk*Bt Twitter = 53F2D8ADFF4791E4B8E0D86FE31E1B85

As you can see each hash is different so if the Facebook password is compromised, Facebook’s hashed password tables are compromised none of the others will be (probably).

What we’ve created is a long, random string with special characters for every website we sign in on and yet once we have memorized the random string, all we really need to remember is which WIW we used for the site. And since we are using the random string many times a day or week, it’s easy to remember after the first few days so you can really make it quite long.

I find this solution to be really simple and I believe it to be pretty strong. I’d love to hear what any crypto-geeks out there have to say.

A couple of closing notes.

• Any website that offers to “send you your password” is NOT secure. The ONLY option should be to Reset your password. Let them know that what they are doing is wrong.
• Any website that limits you to X number of characters or only X,Y and Z characters, or no spaces is risking your security. Let them know that what they are doing is wrong.
• As noted above, no matter how strong your password is, it’s all for naught if the website has poor security practices. This is why unique passwords are so important at limiting the damage and preventing a single password compromise from affecting the rest of your online life.

I think we’re approaching the “end of the password” as we know it as the bad guys have more access to incredibly sophisticated technology. The LRSWIW scheme is making the best of a worsening situation but it’s better than nothing and is simple to use.

I hope you find it helpful. Let me know in the comments!

See an update to this HERE