Townsend Security Data Privacy Blog

Over the past couple years we have seen many instances of online companies experiencing major data breaches due to poor or non-existent password hashing techniques. Organizations such as eHarmony, LinkedIn, LivingSocial, Last.fm, have collectively had millions of user passwords stolen. Despite widespread publicity around these breaches, and many reporters  calling out the mistakes these companies have made around their hashing techniques, these types of breaches are only becoming more common.

Fortunately, for companies who want to prevent a data breach of their users’ passwords and and other personal information, and keep their names out of the headlines, it is fairly easy to do hashing right. 

Four things you should do to get password hashing right:

1. Choose a good quality hash algorithm. Do NOT use MD5 or SHA-1. These are known to be weak and you should just never use them. Use one of the SHA-2 family of hashes such as SHA-256 or SHA-512. Yes, I know about the theoretical weaknesses of the SHA-2 family and that we will soon have a replacement for SHA-2. But use the best you can for now.
2. Always use Salt with your hashes. A Salt is some extra data that you add to your password (or any other field that you are hashing) to avoid a rainbow table or brute force attack on the hashed value. Adding Salt can make cracking a hashed value much more difficult.
3. Use a strong Salt value. Using a few characters such as a GUID or short hex string won’t really give you that much additional protection. I would recommend adding a minimum of 128-bits of cryptographically strong Salt to the password you are hashing. We use a 256-bit value in our applications. Using an encryption key might be an excellent choice for your Salt value if it is provably cryptographically strong.
4. Protect your Salt. Leaving the Salt value lying around in a user file or in the clear is a really bad idea. An attacker who has easy access to the Salt value can efficiently attack the hashed value. You must protect the Salt value as you would an encryption key by using an external key management hardware security module (HSM).

If you take these four steps you will have a much more secure and defensible strategy for hashed passwords, will take you a long way down the road to better security of users’ sensitive information.

Patrick

We hear it all the time: a business was hacked, a database compromised, accounts ransacked, notification and liability, password cracked, blah blah blah. “How can this happen?” “Why didn’t they create a stronger password?” Well before you get too indignant, how well are you protecting your own data?

Is your password sufficient to stop the minions of organized crime, bored fifteen year olds killing time, or other ne’er do-wells intent on accessing your data?

It is difficult to remember different passwords, which is why 60-65% of people use the same password or similar passwords.  This translates into it being more convenient to use your cat's name plus the month number and something about the website itself, then just change it every month.  And that would look like this:

Amazon: (Puddy06Amaz) then (Puddy07Amaz) then (Puddy08Amaz)
Comcast (Puddy09Com) then (Puddy10Com) then (Puddy11Com)

And before you blame the cat for having an insufficiently difficult name, just think how silly it would be standing outside and calling “Here BH-jk!nhb#$@$n_8.”

So you can see it's just a matter of time before they get to your bank. How do they figure out the pattern? Look at your Facebook page, your Twitter, How often do you post about your favorite sports team, your pets, your kids, your hobbies? After they look at that, it's just a matter of time before they figure you out, and they have all the patience in the world.

You might slow the attackers down by using a passphrase instead of a password. Use a phrase from your favorite book, movie, or song. (1 phrase will rule them all!!) (I ain't never birthed no babies b4) (8 Days a Week)

Alternatively, have a password pattern for general accounts and a very different pattern for more sensitive accounts. Preferably one that you don’t plaster all over Facebook!

Then of course there are the other attacks, such as dictionary, malware, phishing and brute-force.

One way to help protect yourself is to get a password vault. With these you only have to remember one password or passphrase to unlock the vault and have access to your passwords. 

Once you set it up, these vaults will randomly generate unique passwords for each website or account making it easier for you to reset passwords on a regular basis (a good practice to get into) and you don't have to make them up or remember them!

I'm not saying that businesses don't have responsibility in this; they need to get on board as well. How many sites do you go to where the passwords are restricted and:

• Has to be between 6 and 10 characters long
• Has to start with a letter
• Has to have at least 1 number
• No spaces or symbols

Really? That limits you so much and, again, just a matter of time with the right computer program to figure that one out.

And then you forget your password anyway, so you call them.  Customer service tries to be as helpful as they can be: "Well, your password is a word and number." And when you still don't quite get it: "It's a place you might like to vacation and it starts with H" and by feigning forgetfulness, injected with humor, chatting up the Help Desk, you can get it narrowed down even more.

For the most part, people like you and me understand we are taking a risk, but we are still not willing to give up convenience.

How do you respond when your bank or other account calls you? Sometimes they ask for your zip code, date of birth, or address maybe to confirm they are indeed speaking with the owner of the account. But how do you know with whom YOU are speaking? You could call them back but that's inconvenient. Simon Davies of Privacy International suggests putting a nonsense word in the special instructions field on your account. Then when they call you, you ask them to read you that word. If they indeed are the bank, they have that word and can confirm it.

Technology is moving away from passwords and towards those things easier for us to remember and recognize on a personal level. We've seen pictures, for example, used with a pattern swipe, or face recognition. Right now that is still tied to a password or PIN and those are used as back up - so still hackable. But it's a move in the right direction.

Fingerprint recognition is accepted as highly secure and practically impossible to fool.  But a Japanese cryptographer got past such a device by using Gummi Bears.

Kevin Mitnick, a famous hacker turned good guy, got around a voice authentication by using a program that fakes his phone number on caller ID. He then made sure that each number was represented, and, calling the CEO of the company he was testing with, asked the CEO if he had the "new" phone number and would he read it off to confirm it displayed properly. Now he had the CEO's voice with every number and broke in.

As data thieves get smarter and your one-size-fits-all password becomes less secure, it is important to routinely change your passwords and not use the same password on multiple sites. Being in the security industry, we see plenty of preventable data losses. While there isn't much you can do to prevent the next big breach, you can at least make it hard for data thieves to take your lost information and use it to access your other accounts.

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CEO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.

Anyone active in the IBM i community knows Patrick Botz from his time as the Lead Security Architect for the IBM i group in Rochester, Minnesota. Patrick worked for years promoting security best practices, and worked diligently to solve one of the more perplexing and complex issues for large accounts – Single Sign On (SSO). Everyone with a large number of users has felt the pain of managing lots of user accounts and passwords across a lot of different types of systems. For any organization with more than a few users, managing user accounts and passwords has traditionally been an expensive proposition.

But it is one that you can now tackle very effectively.

Because of a lot of work that Patrick did during his stint at IBM, IBM i customers now have the technology they need for Single Sign On (SSO). Yes, you have the technology you need, you just didn’t know it.

Patrick is now in private life providing services to customers who want to reduce their help desk costs for managing user accounts and passwords. You can actually get to an SSO solution without purchasing additional software, and Patrick can help you achieve this. His company, Botz and Associates, has an affordable, packaged services solution called SSO stat! that will get you up and running with SSO very quickly. And this is not a drive-by engagement. He focuses on knowledge transfer during the engagement so that you can make it on your own, and he provides a support offering in case you want to have his expertise on demand.

Password management continues to be a challenge for all organizations. Poor management leads to insecure passwords and inconsistent policies – and these lead to more data breaches. We can do better. And Patrick Botz can help you get there.

By the way, Patrick worked for years at IBM, but before that he was a UNIX kind of guy. Today his expertise spans UNIX, Linux, Windows, Mac, and IBM servers. We all have multiple technologies in our organizations and he can help you stitch them all together.

We just did a podcast together with Patrick on Single Sign On (SSO) that I am sure you will find interesting and I encourage you to listen to it now.

Disclaimer: Neither I nor Townsend Security has a financial relationship to Botz and Associates. We’ve hoisted a beer together, and I’ve seen his work at mutual clients. He’s someone I think you should get to know.

Patrick

The loss of passwords by LinkedIn, eHarmony, and Last.FM should be a wakeup call for CIOs, security auditors, and IT security professionals everywhere. Let’s take a look at what probably happened, what you can do, and why you need to look beyond passwords on your own systems.

One-way hashes are used in many places in your applications for data protection, data verification, and integrity checking. It is one of those fundamental building blocks of security. There are standards for hash algorithms and conscientious security professionals will be sure that a system uses industry standard hash methods such as those recommended by the National Institute of Standards and Technology (NIST). The Secure Hash Algorithm (SHA) is one of those standards and is readily available in a variety of open source and commercial applications (we have one). It is a common practice to save passwords as hashes rather than saving the password in the clear or encrypted. (You could, of course, protect passwords with encryption and good key management, but that is a discussion for another day).

LinkedIn was using SHA-1 for their password hash. So what went wrong?

First, SHA-1 is no longer recommended for use in security systems. It has been replaced by a new family of stronger and more secure SHA methods with names like SHA-256, SHA-512, and so forth. These newer hash methods provide better protection from the type of attack that LinkedIn experienced. We use SHA-256 or strong methods in all of our applications. So using an older, weaker algorithm that is no longer recommended was the first problem.

Second, it is considered a security best practice to use a Salt value with any data that you are protecting with a hash method. What is Salt? In the context of hashes a Salt value is just some additional data that you add to the sensitive data you want to protect (a password in this case) to make it harder for an attacker to use a brute force attack to recover information. LinkedIn was not using a Salt value with passwords, and more simple passwords were easily recovered. (More on Salt in a moment). The attackers easily recovered LinkedIn passwords.

LinkedIn has apparently taken some steps to better protect their passwords. Is it enough? Let’s look at what should be done. This will help you look at your own Web and IT systems and understand where you have weaknesses.

These are all common recommendations from the security community:

Recommendation 1 – Use industry standard, strong hash methods

You should be using SHA-256 or SHA-512 for this type of data protection.  Do not use weaker versions of the SHA hash method, and do not use older methods like MD5. Do not be swayed by arguments that hash methods consume too much CPU power – just ask LinkedIn if that is their concern right now!

Recommendation 2 – Use NIST certified hash software libraries

If you use a hash method to protect sensitive data, you should use a NIST-certified software library. Why? Because it is terribly easy to make mistakes in the software implementation of a SHA hash method.  NIST certification is not a guarantee, but in my mind it is a minimum requirement that you should expect. I find it curious that most people would not consider buying a used car without a CARFAX report, but completely ignore NIST certification when deploying hash software to protect sensitive data. A lot more is at stake, and you don’t even have to pay to verify certification!

Recommendation 3 – Always use Salt with your hash

Always use a Salt value when creating a hash of sensitive data. This is particularly important if the sensitive data is short like a password, social security number, or credit card. A Salt value can make it much more difficult to attack the hashed value and recover the original data.

Recommendation 4 – Use a strong Salt value

Never use a weak Salt value when creating a hash. For example, don’t use a birth date, name, or other information that might be easy to guess, or discover from other sources (attackers are great data aggregators!). I recommend using a random number generated by a cryptographically secure software library or HSM. It should be at least 4 bytes in length, and preferably 8 bytes or longer.

Recommendation 5 – Protect the Salt value

Protect the Salt value as you would any sensitive cryptographic material. Never store the Salt in the clear on the same system with the sensitive data.  For the Salt value, consider using a strong encryption key stored on a key management system that is itself NIST certified to the FIPS 140-2 standard.

Are your systems at risk?

You are probably using hash methods in many places in your own applications. Here are some thoughts on where you can start looking to uncover potential problems with hash implementations:

• Passwords (obviously)
• Encryption key management
• System logs
• Tokenization solutions
• VPNs
• Web and web service applications
• Messaging and IPC mechanisms

Hopefully this will give you some ideas on what questions to ask, what to look for, and where to look for possible problems on your own systems. You don’t want to be the next LinkedIn, eHarmony, or Last.FM. They are not having fun right now! 

Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about my take on this breach and ways you can keep this from happening to your organization.

Patrick

The security breach involving Global Payments, a US credit card processing company is still in complete disarray months after the breach took place. A little over a month ago, it was reported that a maximum of a staggering 10 million credit card numbers could have been apprehended during a five week period starting in late January. Global Payments reluctantly admitted to being the victims countering with a figure of 1.5 million credit card numbers stolen. While there isn’t any reason why any company should have this happen to them, it is a growing trend to claim a bit of ignorance on the matter, or at least try to redistribute the blame.

When these breaches happen, many business owners and executives are blindsided by the blow. Of course they have security software, and in most cases, if they have it, the word “breach” shouldn’t have any place inside the walls of these businesses. But, as we’ve seen, credit card numbers and other personal information that should be safe, sometimes isn’t. Having strong passwords is the first step an organization should be doing to keep unauthorized individuals from accessing sensitive information.

Make sure that any passwords that you choose to enter are not what as known as “default passwords.” It seems logical enough, but a default password is one of most common flaws in a security system that leads to a breach. Hackers have databases full of default passwords, and those can be typed in at a rapid pace. Some of these include the obvious “1-2-3-4-5” or “a-s-d-f.” Any sequence of characters that in some universe make sense in a logical order should be completely abandoned. Also, birthdays or dates that can be easily discovered should be the last passwords that are selected. It is far better to come up with something so outrageous, and take the extra time to completely type it out then to use simple passwords that are already on databases. Also, use different passwords for different accounts. That way, if one is discovered, the rest are still secure.

Your credit card company should be monitoring all activity on your accounts, so that if anything suspicious is going on, you will be notified about it instantly. You don’t want to be on this list of companies that have allowed breaches, so make sure to be smart about your passwords. If you ever had a tree house and the bully next door successfully guessed “peanut butter” as the password, you would have to, begrudgingly, let him in. But, he probably wouldn’t guess “138927491AsmaraEritrea53211” so taking the smart choice would pay off.

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.