Townsend Security Data Privacy Blog

In the wake of the recent LinkedIn password breach where LinkedIn lost control of over six million passwords, the question of how Internet sites securely store log-in passwords has come into global focus. I recently sat down with Patrick Townsend, founder & CEO of Townsend Security to discuss security best practices for creating hash value passwords:

1. Use only an up-to-date hash method
Because computers have become stronger, faster, and more powerful over the past decade, some of the older hash methods should no longer be used. MD5 and SHA-1 are two outdated hash algorithms that are considered no longer secure. Unfortunately, LinkedIn was using SHA-1 and a poor implementation method, which is what most likely led to their data breach. The newer hash algorithms, SHA-256 and SHA-512 are up-to-date and considered much more secure.

2. Use a hash based on industry standards
The National Institute of Standards and Technology (NIST) publishes standards of hash algorithms. The SHA-2 family of hash algorithms (which includes SHA-256 and SHA-512) is published by NIST as a standard. The goal at NIST is to keep track of hash standards, test and review hashes on a regular basis, and know when it’s time to update them. As hash algorithms become weak and outdated, NIST will withdraw recommendation of those hashes and publish the most secure and up-to-date algorithms. Sites using hashes should always use the most up-to-date hash standards.

3. Use Salts
In hash algorithms, a salt is a critical piece of data that is particularly crucial in Internet applications. A salt strengthens the end result of one-way hashes. If you are hashing small amounts of data like a password or credit card number, using a salt is critical to prevent a “dictionary” or “brute-force” attack.

Ultimately, it is not enough for an Internet site to enforce the use of strong passwords. The problem with thinking that most people will choose strong passwords was revealed with the LinkedIn breach where we saw that too many people were using passwords like “linkedin” and “123456”. Even if a site forces a user to create a strong password by requiring certain length or characters, passwords can still be hacked attacked if they are not protected with a proper hashing method or encryption. These methods should always be employed using hashing best practices. Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about this breach and ways you can keep a similar breach from happening to your organization.

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

Danger looms large in Iran, as the flame virus has been unleashed. Experts say that this is far worse than Stuxnet, and that the world could be on the brink of a new kind of warfare. The emergence of cyber-weaponry over the last few years has alarmed the world with its capabilities and uncertainty. It definitely seems like this is the wave of the future in terms of international conflict and the training in espionage. Just 50 years ago, spies were being trained to tap phones and take incriminating photos. Now that computers virtually run the whole world, the focus, of course, is to invade private hard drives to intercept secure information or to make it inaccessible to the party that controls it.

According to a Kaspersky Lab, a security firm headquartered in Moscow, the Flame virus is capable of recording conversations and accessing microphones built into the computer it has infiltrated. It also can retain screenshots and record keystrokes. Just about any activity one does on the computer can be recited to those who let the flame virus loose in a play-by-play manner.

At the moment, it appears that computers outside the Middle East are safe, as it seems to be localized within the realm, particularly in Iran. But one of the reasons it can be so devastating is just how easy it is to intercept information that is password protected. Passwords hidden by asterisks are completely susceptible to being read by the Flame virus, and even if the computer is off, a nearby Bluetooth device can easily be the key to accessing an unplugged hard drive.

The United Nations International Telecommunications Union is on alert for the virus so people should be safe for the time being. But as more of these develop, it is important to make sure you are taking proper precautions to protect your data. When viruses are released, they swarm the prey they were designed to feed on. They can so easily catch people off guard, and it doesn’t pay to have to worry about what might happen. Proper safety precautions go a tremendous way in securing a business and piece of mind. The flame virus seems reasonable enough to control, but there could be real problems if something is developed called the hydrogen bomb virus.

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.

The United States Department of Health and Human Services (HHS) is cracking down on HIPAA violators. Now, more than ever, there is just about zero mercy shed on any practice, large or small, if they are discovered to have made an error in patient confidentiality. On April 17, the HHS made an example out of a physician’s office in Phoenix, Arizona. The practice has only five doctors, but despite being what some may call a small business, they must pay the hefty fine of $100,000 for violating HIPAA privacy and security rules. While this sanction may seem unreasonable for such a small practice, it is simply demonstrating the zero tolerance policy that HHS has regarding HIPAA violations.

A complaint was filed against the practice retroactive to discovering an online calendar that the public had access to. On this calendar were patients’ appointment schedules and even a list of scheduled surgeries. After an HHS investigation took place, it was discovered that employees of the firm were grossly misinformed when it came to knowing the rules and regulations of HIPAA. A second red flag was shown when investigating the amount of effort the company put forth on their policy protecting patient information.

While these two violations are most alarming, there were many other conduct errors found including a failure to obtain a legal business associate agreement in reference to scheduling and email services, and there was no report of risk analysis. All of these violations resulted in the aforementioned six-figure fine.

The message sent here is clear: Follow the bylaws of HIPAA, or suffer major financial consequences. Leon Rodriguez, director of the HHS Office of Civil Rights was quoted in saying  “This case is significant because it highlights a multiyear, continuing failure on the part of this provider to comply with the requirements of the Privacy and Security Rules.” He went on to discuss his desire for companies to comply with the changing rules of HIPAA no matter the size or prominence of the practice.

It is imperative to educate yourself and your staff about the current HIPAA rules.  For more information on HIPAA compliance, view our webinar “Protect PHI & Manage Risk – HIPAA/HITECH Compliance” and learn more about managing your risk of a data breach, achieving breach notification safe-harbor status, and encryption and key management best practices.

In today's interconnected world, your company's reputation can be won or lost on the strength of your data security. Almost every day, you can read news reports about data breaches that expose confidential customer information. Credit card numbers, banking information, even home addresses and telephone numbers have been exposed by unscrupulous hackers and inattentive employees. Social network and online news outlets quickly spread the word of any potential breaches, exposing your company to public scrutiny and ridicule. Data breaches also expose your business to legal liability and sanctions. Once the data is out, there is no putting the cat back into the bag. You will be forced to explain what precautions you've taken, and why they didn't work. If you fail to meet any federal, state, or industry standards for data security, you could find yourself in a very precarious position.

Data breaches come about in a variety of ways. Many highly publicized exposures are the result of direct efforts by hackers. These hackers can have a variety of motivations, from purely financial to personal ideology, but the end result for your company is the same. If they get in, and get useful information, your bottom line and reputation can suffer irreparable harm.

Another infamous, but no less harmful, form of data loss can be caused by employee negligence. Lost laptops, misplaced flash drives, and low-quality passwords can all lead to data loss. A common thief who steals a notebook computer from a car may find himself in possession of your most sensitive data. Even though these exposures can't be directly attributed to any failure on your part, your business will still be responsible for a breach notification.

To adequately protect your data from all conceivable threats, you need to be protecting it with encryption and key management, which goes farther than just access prevention. A dedicated hacker or inattentive employee can circumvent the most secure firewall and bypass the most stringent security protocols. The only way to make sure your data is truly secure is to make sure that, no matter where it's located, it's useless to unauthorized personnel.

It's almost impossible to ensure that your sensitive data remains where you put it. Whether intentional or accidental, there is always the possibility that sensitive data will be removed from your site. The best defense against harmful data breaches is a comprehensive security protocol that utilizes data. When your data is properly encrypted, compliance regulations state that you aren’t responsible for a breach notification – because there is no useable data!

Townsend Security provides NIST-certified AES encryption for all major enterprise platforms and a FIPS 140-2 certified encryption key management hardware security module (HSM) – technology that will help you avoid a breach notification. There is no better way to securely store data and minimize your exposure. 

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.

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.

I am on a new kick to share some security resources with you that I’ve found valuable over the years. I am not following any particular order or ranking people and resources by importance:  I’m just going to do this as the mood strikes me.

Let me introduce you to Chris Evans and his blog.

Chris works for Google, he’s a software and security geek, and is an independent sort. A lot of his work is technically deep, which is great for those of us who enjoy that sort of thing. But I also really like his world view.

Chris has a hacker’s mentality (in the good sense) and his values are lined up with making the world a better and safer place. He doesn’t avoid talking about his own mistakes, and believes that more information about security problems makes the world safer as it gives people the information they need to protect themselves, and it helps developers make their solutions better.  He also provides a lot of just plain good advice that anyone can use.

One example is a recent blog on web browser security. The blog combines some technical information, but it also gives you information about how to think about web browser security, and why some web browsers are better than others.

He also makes an interesting statement about browser security that I think has corollaries that apply to anyone writing software that needs to be safe. Chris says:

“The security of a given browser is dominated by how much effort it puts into other peoples' problems.”

For those of us who write business applications and security software, I would put it this way:

"In addition to everything else you do to make your solution more secure, you have to include other people’s problems in the scope of your thinking, including the unexpected ways they might use your solution."

Enjoy.

Patrick

An alarming number of security breaches have occurred in the last decade victimizing families of military personnel, who belong to TRICARE. Since the fall of 2009, over 400 breaches have occurred. At least 500 people have been directly affected and another 50,000 smaller scale breaches have been reported to the government. The community of Palo Alto, California was hit closest to home, when over 20,000 names of emergency room patients were available on an online public forum before the list was discovered by authorities. For several months, all these people were susceptible to a profusion of afflictions such as identity theft, credit card fraud or fraud against Medicare and Medicaid programs. Just one move can financially ruin a family.

One major cause of the breach was that security tapes were stolen from the car of a TRICARE employee, and these backup tapes had people’s private information on them. The big problem of course, was that after these tapes were stolen, the information was readily available to pirates. Any encryption didn’t exist, so the information was just there for the taking.  If the data on these tapes was encrypted, TRICARE wouldn’t have to worry about the tapes being stolen and you wouldn’t be hearing about this problem – HIPAA grants a breach notification safe harbor to organizations who are encrypting their sensitive data.

If you aren’t familiar with HIPAA (The Health Insurance Portability and Accountability Act), it was established in 1996 and its main focus is to protect the rights to health insurance for families when the wage earner was to change or lose a job. It’s second objective focuses on standards for electronic health care transactions. With HIPAA, there are legal regulations that the government has put in place to protect our Personal Health Information (PHI).  While there is no encryption requirement, it is strongly considered a best practice.

The largest concern when a story like this breaks is for the victims. The Federal Trade Commission (FTC) has published a few tips for individuals who are affected from the TRICARE breach:

• Don’t willingly give out personal information over the phone unless you know exactly whom you are dealing with.
• Increase the frequency at which you check over your medical records to make sure nothing looks out of the ordinary.
• Any fraudulent report you notice should be reported to the police immediately.

The TRICARE breach should be an example of why encryption should be mandatory for organizations that deal with PHI.  Not only does it protect the privacy of your customers, when a breach does happen, HIPAA grants you a breach notification safe harbor.

Learn more about encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Data breaches in the medical industry are occurring at a greater rate now than ever before. Emory Healthcare recently experienced a significant PHI (Private Health Information) breach and has announced that approximately 315,000 medical records have gone missing.

Included among those records are those of the chief executive officer of the hospital, who has tried to calm public outcry by noting that, to his knowledge, none of the personal information had been used in attempts at identity theft. But the loss is significant because it violates patient privacy rights and could have been prevented if Emory Healthcare was properly encrypting the data.

In total, 10 backup discs for the hospital system have been gone from their storage facilities since mid-February. Within each record was a wealth of information, including patient names, Social Security numbers, and surgical procedures and dates.

Emory has said that it had strong policies in place to protect the personal information of patients. It also attributed the cause of the theft to an honest mistake made by an employee.  However, HIPAA states that an organization is responsible for a breach notification regardless of whether the data was “hacked” or just lost.

As part of their remediation plan, Emory is providing free resources to help patients combat and prevent identity theft. While Emory has said it is revisiting its policies and procedures to better protect patient information, it's unclear if they are making systemic changes that could protect patients even if data is stolen in the future. Regardless of what security measures they take to better protect patient information, the only way Emory -- or any other medical facility -- can guarantee patient information is safe and avoid a breach notification will be to protect it with encryption and key management.

If you are not familiar, AES encryption (the standard for Data at Rest) is a form of data protection that uses an algorithm to transform information in a way that makes it unreadable by other entities. AES encryption that is certified by the National Institute of Standards and Technology (NIST) is used to attain the highest levels of security. Encryption can't be ignored as a security measure.

The second part of the encryption process is managing the encryption key. Only by knowing the encryption key can that information be unlocked and read. When data such as patient information is encrypted with proper key management, it is safe from being compromised by hackers or other entities that steal the information. Without the encryption key, the data is worthless.


With breaches in the healthcare industry up 32% in the last year, it is more important than ever to be encrypting PHI.  Data breaches have dollars lost directly tied to each record lost.  Download our white paper “Achieve Safe-Harbor Status from HIPAA/HITECH Breach Notification” to learn more about how your organization can protect PHI with encryption and key management.

Hundreds of thousands of Medicaid recipients are up in arms about a recent security breach that saw their personal information abducted by hackers. Originally it was reported that 181,000 had their information stolen including 25,000 who actually had their social security numbers taken as well. Currently the report has been updated to a staggering 900,000 and 280,000 respectively. Over a quarter million people on Medicaid had their social security numbers exposed, and many of these victims don’t have the means to hire private investigators or attorneys to right their personal situations. 

As many organizations that suffer a breach do, the Utah Department of Health is offering free credit monitoring services for one year to those who had their social security numbers compromised. Other than that, there isn’t much to be done for the breach victims.  Unfortunately, many are still concerned their identities could be stolen among other potential hardships.

To prevent security snafus such as this, the Utah Department of Health should have been protecting their sensitive data with encryption and key management.  Encryption would have rendered the breached data useless. The Utah Department of Technology holds millions of its citizen’s personal information and, unfortunately, didn’t take proper precautions to protect it. Alliance Key Manager, our encryption key management HSM, could have provided exactly what they would have needed to avoid a breach.  With on-board encryption, sensitive data can be sent to the HSM, encrypted, and then sent back to where the data needs to live. Additionally, Alliance Key Manager also meets regulatory requirements - a hurdle for many companies trying to pass an audit around encryption key management.

When you see a situation like this in Utah, its naive to think that hackers can’t access your information in your own home state. But just ask a Medicaid recipient from Utah, and it is clear that these dangers aren’t so far from home. Utah’s governor spoke on behalf of its citizens saying "Individuals provide sensitive personal information to the government in a relationship of trust. It is tragic that not only data was breached, but now individual trust is also compromised."

It’s a difficult situation, but as they try to mend the fences, it is important to audit your own encryption and key management processes to ensure that what happens in Utah stays in Utah.

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.