Tag Archives: security

Creating Safe, Easy to Remember Passwords

Posted by on June 18, 2011 Comments Off

The last few days I’ve spent time pondering the LulzSecurity breaches, Playstation network breaches and the seemingly endless number of other data and security compromises

This has prompted discussions with coworkers and friends about their personal security practices. Being in the IT field over the years I have found that most IT people are only slightly more secure than the general population. Usually the story is that they “rotate 3 or 4 passwords” or “use one password for sites I care about and another one for everything else.”

Both of these methods in my opinion are bad, primarily because a site you do not care about can become a liability later due to the long tentacles of Google and other search engines. People accessing your account might not always be looking for financial or personal data, they could just be out screwing around or attempting to damage your reputation perhaps by posting inflammatory posts to message boards, which may poison Google searches for your name or email address for years to come. You might not know about the compromise for years but Google would be attributing posts to your username the entire time.

Below I address two methods that you could use to create (relatively) secure passwords without having to memorize a ton of different information.

 

Option 1: Use a Password Database

If you want maximum security I would refer to you a password management tool, which will allow you to have a random password for every website you access.  You must keep the password database safe but keeping a single, well controlled database safe is easier than attempting to manage dozens, or if you are like me, hundreds of sites straight. With major tools you can also sync your passwords between your computer and phone so that you are never without your passwords. The major thing you need to assure is that your master password used to lock the database is secure. Applications such as KeePass, SplashID, LastPass and 1Password are examples of these types of tools.

 

Option 2: Create Reference Passwords that are Customized per Site

If you want an easier, less cumbersome method to create pretty solid passwords without password managers I’m going to propose a few ideas, which should result in significantly more secure passwords but without requiring password management tools. You don’t need to go through this entire gyration but the more you do, the less risk you are exposed to. Customize as you see fit to your paranoia level and needs.

Creating an Easy to Remember Set of Passwords:

  1. Pick your Words or Phrases. Pick 3-5 words or phrases you can easily remember. The words SHOULD NOT show up in a Google search, even misspelled. This means if you are going to make up words then make up new unique words no one has used before. For phrases you can use poetry, lyrics, book quotes, anything you would like. I would encourage you to stay away from quotes or lyrics that are extremely popular since you are not the only one that would have thought of them.
  2. Shorten words or phrases into something manageable. If it is a long enough phrase such as “I do not like green eggs and ham said Sam I am.” then shorten it to “IdnlgeahsSIa.” or some variant. There are two reasons for this; first, typing a massive phrase can take people awhile and is prone to typos. Second, many password systems still do not have the ability to handle passwords >16 or >20 characters. Our goal is simplicity without a management system. Note that I left the special character “.”. In password cracking special characters enhance security, although a few password systems will not take them.
  3. Verify the passwords are >8 and <20 Characters. Now you should have 3-5 solid, non-Googleable words or abbreviated phrases with >8 and <20 characters each.
  4. Make it Easy to Locate Which Password to Use. The next step is to figure out a trick to identify each website so that you can pick one of your passwords. You could use the first letter or second letter of the domain name to identify the password to use. E.g Letters A-L get one password, M-S get another, etc.
  5. Figure out a Unique Identifier for Each Website. Figure out something about the domain name or website that will give you something fairly unique. E.g. Logmein.com has 10 characters in the domain name, perhaps you use that. You could also directly steal something from the site, such as its name and use it in the password. E.g. Insert the initials “lmi” or “logmein” into your password.
  6. Place the Unique Identifier into your Password. Now, take your new unique number and apply it to your password, perhaps with the shift-key applied, which will make the characters special. In the case of the password I reference above: “IdnlgeahsSIa.”, if I used both methods identified in step five I would insert “10” with shift held down and “lmi” into my password. The result might be “IlmidnlgeahsSIa!). Note that I did not insert the shifted “10” or the lmi at the very beginning or end of the passwords to make it a little harder to predict for someone attempting to compromise my accounts. At this point most hackers are probably moving onto easier targets unless you have become the target, in which case they will probably try to find other ways to access your accounts. If they do keep trying to access your accounts using passwords there is a good chance you would receive notices that something was up before they gained access elsewhere.
  7. Create a cheat sheet to carry with you. Until you have committed your new password methods to memory carry a coded sheet of paper with you, perhaps in your wallet. Do not just write the entire process, just the cliff notes necessary to jog your memory. This way if you lose your wallet your passwords are still safe, all they will find is paper scribbled with unintelligible notes.

After trying a variation of this system if you think your password management method is still too complex mix it up and perhaps simplify the system. The key is to keep passwords long, avoid dictionary words, mix up the letters and numbers, if possible insert some special characters, and keep from using the exact same password on several websites.

Even if this type of strategy does not keep people out of all of your accounts by the time they figure out what sites overlap (should be very few) you will hopefully have received dozens of “Invalid login attempt detected” messages in your inbox, allowing you to take action.

Navigating and Understanding Vendor Security Claims (2 of 3)

Posted by on June 14, 2011 2 comments

This is the second in a series of articles on Navigating and Understanding Vendor Security Claims. You can check out Part 1 here.

 

When good Encryption Goes Bad or “What the hell happened to WEP?”

Many sites will banter around the term encryption like encryption is all that matters. Just because you are using good encryption does not mean your data is safe, the encryption must be implemented properly in order to keep your data secure.

The classic example of “Good technology, bad implementation” is a wireless security protocol called Wired Equivalent Privacy (WEP), which was introduced in 1999 and is still a feature of all mainstream WiFi network cards in your computers today. The core components within WEP were good but implemented in a poor manner, which left the wireless security on millions of computers broken. Within a few years of WEP being released someone had figured out how to break the encryption key within an hour. Vendors made many adaptations to the protocol to beef up its security with varying levels of success. WEP was replaced several years ago by WPA but to this day WEP is still the most compatible wireless encryption protocol so many people use it, especially in homes and environments with older devices.

These same issues relating to bad development decisions may arise in any security implementation. Going back to our online backup vendor example: What if the backup vendor cached your unencrypted data to a temporary directory on their server until they had free processing time to encrypt it? The attacker would never need to compromise your encryption for new data; they would just need to monitor the temporary directory for the cached data and copy the interesting information. In a severe instance perhaps the hacker automatically sends a copy of all data passing through that directory out to another server on the Internet. This scenario would be avoided if the customer were doing the encryption before the data was sent to the provider, although it still relies on the vendor developing their software in a secure manner and being wise about their service architecture.

The final example I will give on this topic since it has been in the headlines recently is Dropbox, which I have mentioned in previous posts. Their website states that they are encrypting customer data with AES. It was later revealed that all customer data is being encrypted using a single encryption key and that the Dropbox staff could decrypt the data if deemed necessary.  This might be fine for some people or organizations but for others it would be a completely unacceptable situation since a single encryption key being compromised could put all data within Dropbox at risk.

If you need a service but are uncomfortable trusting vendor security claims another thing you can do is double encrypt your data. In this situation you would encrypt the data on your servers, then encrypt it a second time before it is sent to your provider using their encryption method. By doing this even if your vendor’s network is completely compromised including your backup private keys the result of a hacker decrypting your data will be more encrypted data, for which they do not have the keys since you performed the first layer of encryption in-house. At that point unless it is a highly skilled, targeted attack against your organization the attacker is probably going to move onto an easier target.

The moral of this section is: Just because the buzzwords are there does not mean your data is safe. Dig deeper to find specific information as to how they assure that their security and encryption implementation is secure whether it be through an advanced quality assurance process, secure development and testing regime, external code and security audits and constant reviews, or any combination. The more they do the better.

 

Are there cases where encryption is a liability?

In my opinion, Yes. This will not be true for most people most of the time but it can be.

When you encrypt or digitally sign (a topic not covered in this article but closely related) your data using a well-constructed key and encryption or digital signature system you have done something in addition to securing your data. You have guaranteed that the data was yours.

Do you want all your data to be traceable back to you? Think about this for just a moment.

Imagine you are in court “So Mr. Weiner, you say you did not send that photo of male genitals to six female colleagues?” “No, I did not sir, my twitter account was hacked.” “Was the image yours?” “I do not know.” “After analyzing your office computer we have found a copy of the image and twitter data encrypted under an account that only you had access to. The forensics team determined that there is no evidence of data tampering or unauthorized access on that computer. Are you sure you did not send the photo?”

What just happened in this example? Assuming the court understands the basics of encryption and data security Mr. Weiner is damned because he sent the images from his encrypted data store containing both the image and the twitter cache showing the sent image. It becomes a bit like DNA evidence, there is a very large hole to dig yourself out of if you want to prove it wasn’t you. At this point I will point out that I am not a lawyer and am covering this topic just to get people thinking.

Being a computer guy I know people that digitally sign every email, which provides a guarantee that the email is original and was not tampered with in transit from the writer to your computer. This is another item I question; do I want every piece of email I send to have a digital signature guaranteeing that I sent that email? Are you planning on running for political office? If so do you want your “Guaranteed” email quoted out of context by your opponents?

Think about all those funny emails you have, the lewd jokes, the political rant you wrote after a few too many beers, and anything else you may have sent or stored in your encrypted account or data store. Do you want that data to be able to be tracked back to you with certainty?

If you are a corporate encryption user there is a good chance your company is practicing a technique called “key escrow”, which is where the corporation maintains a copy of the encryption keys so that they can access your data in specific situations, such as during a legal proceeding or to meet regulatory requirements. In these cases your company can always access your encrypted data if necessary. It also leaves open a potential attack vector for someone looking to gain access to your data. Rather than target your account they might choose to target the key escrow system within your organization, which might give them access to everyone’s encryption keys.

A privacy paranoid individual would argue that encryption is always good but that is only if the data is not found in the first place (there are techniques to hide your data while also encrypting it), you are willing to give up the keys to a proper authority, or you are doing something illegal for which the punishment is worse than the potential repercussions for denying the court access to your data. Which looks worse, having a hard drive containing illegal data that you can claim was an innocent mistake or showing up in court and refusing an order to provide your encryption keys, which implies that you knew you were violating the law and want to hide it.

If you are breaking the law and hoping to leverage encryption to protect your data your risk maybe more perception than what is contained within the data itself since the authorities already had some evidence in order to arrest you in the first place.

In real life, rather than the armchair quarterbacking that I offer above, I encrypt my notebook hard drives and encourage others with portable machines to do the same. This is not because there is anything illegal on my computers but because if my notebook is lost or stolen I don’t want to worry about what data was lost. Losing a computer would suck, losing a computer with all my important data on it would suck about a hundred times more.

 

What is Hacking?

Hacking itself is not bad, it is the use of something for a purpose other than was originally intended.

Some people have attempted to differentiate Hacking by calling “bad” hacking by a different name such as “cracking” but it has never caught on, it is Hacking, just a different type. You can be a good driver or a bad driver, either way you are still driving.

Most of us partake in some form of hacking every day, although not to the degree that people like the folks participating in Make Magazine or in the more extreme Lifehacker articles do. When you took that broom, sawed the tines down to two inches then used it as a rain gutter cleaner that was hacking at a basic level. You repurposed something in a way the manufacturer never intended.

A second part of understanding hacking is that there are two main types of technology hackers, recreational hackers and hackers with a financial or reputation goals.

For the Hackers with a financial or reputation goals you could become a security consultant, penetration tester (a professional hacker), steal identities or credit cards; it all serves the same purpose only some types of hacking do not result in jail time if caught.

Recreational hackers are folks like George Hotz, smart folks with time on their hands that are interested in tinkering, understanding how things work, and enabling them to do unintended things. Sometimes these folks end up doing stupid stuff, like defacing Bank of America’s website, which can land them in jail or make them the target of a lawsuit but at the end of the day it isn’t about money or fame, it’s a hobby or passion.

 

The Terms of Service Tightrope

All vendors storing your data online are going to have Terms of Service or Terms of Use that disclaim most or all of their responsibility in a security breach or data loss event. Some will provide reassurances or some basic guarantee but if you read the details you will probably find that their liability is only a token effort, not anything that will save your business.

With this said no vendor wants their security compromise or data-loss event to be front-page news so they do have some incentive to keep your data safe other than taking your money every month. For them a security breach will likely mean lawsuits, competitors eating them alive or in the case of regulated data the potential for fines.

If you are looking to outsource more than your non-essential applications, such as a health organization outsourcing their Electronic Health Record and Billing, which are critical to the organization and contain confidential data you will want to perform due diligence by scrubbing the terms of service for exceptions you require, put business associate agreements in place where necessary and analyze any contracts closely.

As a small business you won’t have much leverage with many vendors but if you are a medium or large business it is worth twisting arms a bit to see where you can realize some compromise. If the vendor cannot provide assurances you require you can keep hunting or take your own precautions to secure the data before it is sent to them. This might not be possible with services such as Electronic Health Records but if it is an online Disaster Recovery or Backup service you may be able to take action to add additional layers of security.

 

Physical Security

This is the Gates, Guns and Guards portion of keeping your data secure. If the datacenter housing your data is properly secured you avoid a real risk to data security. Downloading 200 Terabytes of data over the average Internet connection would take months. Stealing the servers out of an insecure building would only take a few hours, plus a Oceans 11-style planning event just for fun.

When evaluating online vendors something we often do not think about is where the data is and what keeps people from accessing the data if they walked into the facility where the equipment is located.

In my last blog post I mentioned finding out where the datacenters were so that you know whether the vendor is geographically diverse. In addition to being geographically diverse you will want to ask about how the facility is secured and who can gain access to the equipment.

There is a computer security mantra related to physical security. For this article I will quote a variant from a Microsoft TechNet article: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.

 

Social Engineering

Social Engineering is the act of manipulating or hacking a human-based system to gather the data you are looking for. Why go through five online systems attempting to answer questions to reset someone’s password when a well-placed, friendly call to customer service could do the same?

For a company storing or hosting my important data or systems I would expect that they have a system built to validate people’s identities, keep their facilities are secure, require multiple levels of approval to access and that they would not let a guy dressed as a telecommunications technician with no other credentials wander around the building unfettered and provide him keys to the wire closets.

This might not be something you can find out ahead of time but it is worth asking about. If you cannot get a straight answer as to whether they train their staff to look out for Social Engineering attacks you could test by calling their customer service number and see what information you can gather about your organization or whether they will reset your password without giving them your real credentials.

Another form of Social Engineering attack is the Phishing attack. A phishing attack is where a hacker sends out emails or other communications with a link or request for data while impersonating a legitimate tool or website. Normally this is to gather your usernames, passwords, personal data, or perhaps install malware onto your computer, from which they can gather data or launch attacks later. A variant of Phishing is called Spear Phishing and is targeted at a specific organization.

 

Other Factors

We have focused primarily on computers, encryption implementation and access to those systems. Just like your home, the front door lock is only one aspect to proper security. Other factors we will not be digging into during this article include items such as:

  • Proper network security infrastructure including firewalls, intrusion detection and prevention systems (IPS/IDS) and secure network development and architecture.
  • Host/Computer-based intrusion detection software, antivirus/anti-malware and other tools enabling vendors to monitor, act on, and protect against security events.
  • Network Monitoring infrastructure, enabling vendors to monitor the health of the network, set baselines and alert automatically if there are changes in expected activity. In a perfect world these systems would be tied closely to the Intrusion Detection and other traffic-monitoring systems. A great real-life example of this is the online password site LastPass saw a network data anomaly and immediately took steps to secure their data. Breaches are not a good thing but they are to be commended for having monitoring systems in place with someone watching them so that they noticed when traffic changed on the network and took proactive steps to secure user’s data. After a move like that my trust in the company went up rather than down, whether or not there was a breach.
  • Regular audits, secure development, and quality assurance processes with a focus on data security.

 

So I’ve done or verified everything above; is my data secure?

No one can guarantee that your data will be 100% safe. If an organization has enough money and is determined to gain access to your data there is a good chance they will, even if it means bribing your janitorial firm to photocopy your important data in middle of the night. What you need to do is determine what is reasonable.

Information Security is a compromise between ease of use and protecting user data. As has been said many times, the only secure computer is turned off, in a vault, with no network connectivity. At that point it becomes unusable so the system’s value is destroyed. Security teams are always attempting to strike this balance so that they protect the infrastructure while keeping the systems usable. If systems are not usable the users will find other ways to get the job done, which will almost always be more risky than making some compromises up front.

Security is a huge topic, protecting your data is an industry unto itself. Our goal here is to help you make good decisions and detect questionable statements without being a security expert.

>>>

If you made it this far, congratulations. Eat a brownie and blame me for destroying your diet. In the next article we will look at some specific examples of security claims and compromises.

Navigating and Understanding Vendor Security Claims (1 of 3)

Posted by on June 13, 2011 1 comment

Every time you make a decision to trust a vendor, whether it be a storage provider in the cloud, the company handling your taxes online or your favorite social network you put faith in them that they will live up to the security claims provided via their website. Is your online backup vendor really keeping your data secure? When you click “Share my data with only friends” on Facebook what assures that this is true?

Due to the expansiveness of this topic I’m starting with two posts describing data security concepts you should understand if you are looking to evaluate vendor claims. The third blog post will be a hit list with examples of language to look for on vendor sites, how to decipher it, and identify valuable security statements vs. buzzwords and hype, which permeate the industry.

 

Data Security and Encryption Concepts:

In this first section we talk about security and encryption concepts. This post is about defining security terms and understanding important technical components such as what encryption is, the types of encryption, and the differences between encryption keys and password hashes. Don’t worry, there is no associated test.

 

Understanding the difference between Features and Vulnerabilities

A Feature is placed on purpose. The username and password used to log into your favorite site, known as your authentication method, is a feature they have implemented to differentiate and secure user accounts. The “Share data only with friends” button on Facebook is intentional and under normal circumstances will only allow your friends to see your data; this would also be a feature. A programmer built this feature into the software and it is behaving as expected.

Vulnerabilities are unintentional, they are usually introduced when someone is writing a piece of computer code and does not perform the proper checks on that code. By attempting to manipulate the program in unexpected ways someone might find the vulnerability, which allows them to gain access to other data, crash the system or load their own programs onto the system. There are other types of vulnerabilities that can happen at other levels in computers, including at the hardware level but software vulnerabilities are the most common.

As an example of a vulnerability, if a programmer wrote code for a search box on a website and only expected people to search using letters, not numbers or symbols but didn’t write the code to check that only text is entered in the box they may have unintentionally introduced a vulnerability. Later someone might come along and by attempting to insert non-letter characters in the search box learns that they can have the website show them other people’s private data. This newly discovered “capability” would be a vulnerability.

 

Encryption

At a basic level encryption is using math to scramble (encrypt) data so that unless you have the proper key you cannot unscramble (decrypt) the data later.  You can expect that fifty years from now that the data will be accessible due to increases in computing power but over time the confidentiality and value of data is reduced so from an effective standpoint it can be labeled secure.

The primary encryption algorithm used when I started implementing systems was DES, which was used for 20+ years before a machine was built that could crack the encryption in less than a week for a reasonable amount of money. DES is still in use today in some systems that have not migrated to newer systems such as AES, which is now about 12 years old and the current standard endorsed by the U.S. government for Top Secret data. With that said the hunt for the next standard is always underway.

 

Single Key Encryption and Public Key Encryption

The two methods of encryption you should know about are called Single Key (symmetric) encryption and Public Key (asymmetric) encryption. Both types of encryption are referenced by other names depending on whom you are talking to.

It is also important to know that they are often used together since each one serves certain purposes more effectively than others or is more efficient. As an example it is generally recognized that Public Key encryption is far more processing intensive to utilize so you might use Public Key encryption to setup and validate a secure channel between entities, then switch to symmetric key encryption once you are sending data.

Single Key Encryption:

Single key encryption has only one key used for both encryption and decryption of the data. This method comes in most value when the data is only going to be accessed by one group or individual with 100% trust between the parties or a method to share the key between parties that is secure.

An example of single key encryption is if you were to have a document on your computer that you encrypted using a password. You are the only one that knows the password and it can be used to encrypt and decrypt the document. If the password is lost, which in this case is also acting as an encryption key, the document will be unreadable.

Public Key Encryption:

In Public Key Encryption there are two keys that are mathematically linked. When someone encrypts data using the Public Key the only person who can decrypt the data is the person with the Private Key. Public Key cryptography is also used to generate and apply digital signatures to files or documents, which is beyond the scope of this blog post.

An example of Public Key Encryption is being able to send an email that is secured in a way where only the recipient could decipher it. By having the recipient’s Public Key you can encrypt the email before sending it. When they receive the email they will decrypt it using their Private Key, which only they have. This same scenario works in reverse if they want to send an email back to you; they would use your Public Key to encrypt the email, send it to you, then you would use your Private Key to decrypt it. In this situation, even if someone eavesdrops the email they are left with unintelligible data since they don’t have the Private Key.

In your web browsing every day you use a combination of these types of encryption. Anytime you browse to a secure website, marked by a URL with “https” in the beginning, you are using both Public Key and Single Key encryption compliments of TLS/SSL.

 

The Key

The Encryption Key used to encrypt and decrypt data can be anything.  Usually it is a long series of random characters, which is used by the encryption algorithm to process the data. The outputs from the encryption process are blobs of scrambled data called ciphertext, which is your data, only encrypted. Think of the key as a really long, secure password.

If you have chosen your key wisely and the encryption algorithm is solid, assuming no one steals your key and data, your secrets will be safe for many years to come.

An important rule when generating a key is that it should be large and random. If the encryption algorithm is secure but the key is non-random or too short someone can use a type of attack called a brute-force attack, where they try every combination of potential keys to access the data. This is also true for passwords, which we will discuss below.

It is worth noting that all encryption keys and passwords can be brute-forced if given enough computing power and time. If, with modern computers it will take 200 years to access a piece of data it is effectively secure. It is not that data cannot be accessed; it is that the data cannot be accessed in any practical timeframe.

Good encryption for the average person is a combination of a strong algorithm AND a large, random key.  If you are lacking one of these your data will not be secure.

For this reason it is important to know what encryption system people are using to secure your data. Any time I see the word “Proprietary” with no additional details I become concerned. Thinking that a single organization has built an encryption algorithm stronger than the publically accepted gold standard, which as of this writing is AES, is highly unlikely. There are other systems that companies might choose to use such as Twofish but they should be willing to reveal what method they are using and you should be able to find information on the encryption they are using through a search engine.

 

Keys vs. Passwords

Passwords and encryption keys are very similar in concept; they are unique pieces of data that provide assurance that you are the only one accessing a system or a piece of data.

The difference between a password and encryption key is defined by what the computer does with it. Above we discussed what an encryption key is used for; to secure your data against use even if the data itself is compromised. Without the key the data is useless.

A password in its standard form is used to authenticate your identity and authorize access to certain data on a system. It is not used to encrypt or otherwise obscure your data so that it is unreadable.

As an example of simple password use we will use Facebook. When you provide a password to Facebook it allows you to access your profile and data. In this case your password is used to validate your identity and grant access to different pages and profiles on the Facebook website. If someone hacked into Facebook and was able to download your profile data that is exactly what they would have – your completely readable profile. It was not encrypted so the data can be read easily.

I will not over-muddle the use of passwords and encryption keys but these concepts overlap. Sometimes your password will also be used as an encryption key or be tied to an encryption system so that once you login you also gain access to your encryption keys. This type of system is often used in corporate environments where you cannot trust users to secure their own keys against being stolen or lost. In this situation when someone logs into the network they are also provided access to their encryption keys.

 

Who holds the keys to the Kingdom?

When using online services there is a risk in where the keys are stored. Are you holding the keys, is the vendor holding the keys or do both of you have copies? For this example we will assume that we are using single key encryption and you are going to use an online backup service.

Vendor Maintained Encryption Keys:

Most consumer-oriented services hold the encryption keys for you. Why would they do this? They understand that for a home user keeping their encryption keys in a safe location is a major issue so they setup infrastructure to house the keys.

In this case you will be forced to trust that the vendor is storing your keys and your data securely. If they are not there is potential of all of your data being compromised. A positive aspect of this is when your father’s computer fails you can recover his data even if he does not have his encryption keys. If the encryption keys were stored on the computer and he did not have backups (isn’t that what he is paying the vendor for?) his data becomes useless when the hard drive crashes and takes the keys with it.

A paranoid security expert ignoring ease-of-use or practicality would tell you that this type of service should never be used. Taking it from a more practical standpoint if the consumer of the service cannot be counted on to maintain encryption keys it is best to identify a vendor to provide the service or qualified technical help to assure he is securing his keys. I would not typically recommend this type of service for any business except for a tiny business without any technical staff, confidential data, or trade secrets and in that case it would come with a bucketful of disclaimers.

Customer Maintained Encryption Keys:

Backup vendors oriented toward businesses will often rely on the customer to store and maintain the encryption keys. This puts ownership onto the customer to have infrastructure and systems in place to manage and distribute keys in a secure manner but removes the potential for a vendor-side security compromise to reveal unencrypted data.

In this situation the vendor never has visibility into the unencrypted data. Before the data is uploaded to the vendor servers the data is encrypted, making it meaningless to a compromiser as long as the backup vendor’s encryption system is solid.

This places complete ownership of the keys onto the customer, which usually includes generating a proper length, random key then storing them in such a way as to assure that even if the customer’s servers melt-down there are copies of the keys available elsewhere. In situations like this the customer needs to make an appropriate number of copies of the keys then distribute them to safe locations where they can be recalled if need. If the keys are lost, so is the data since the vendor cannot decrypt it.

Other than staying away from Cloud-based or Hosted vendors this is the most secure method to handle your encryption keys but it places ownership onto you, the customer to keep the keys safe. If they are lost, your backups are worthless.

 

What is Hash other than a drug?

When your passwords are stored on most websites and servers they are hashed, which is different from encryption since the algorithm that generates hashes does not have the capability to turn the hash back into a password. It is a one-way function only.

If you hear in the news that an organization had a hundred million passwords compromised and they state that unless your password is simple or short it should be safe, that means they have hashed your password before it was stored.

At a basic level a hash is a fixed-length unique value that is returned when you feed a certain input into a hash algorithm. When I use a Hash Generator and feed “bob” into it I receive back “bf8bea686c94bce1a58631cf5a3e9cf9ebabb31e16e353f4caa97f052bb629ff2b945aaa8f8caaf5 1fdec2c7f874420e45617f6abcbf9407f08ef939c1aa1e11” as the Whirlpool hash. This number is for our purposes unique to the word “bob”.  If two inputs generate the same hash it is called a “collision” and from a mathematical perspective is extremely rare with modern hash algorithms.

When using hashes you expect someone to know what input it takes to derive the proper hash value, which is why it works well for items like passwords where you are confirming someone knows some piece of data, not trying to recover it. This is also why most websites cannot tell you your old password; they are only storing a hash of your password, not the password itself.

 

Putting Salt in the Hash

This is not an article on passwords alone but there is another term you will hear thrown around when talking about passwords. That term is “Salt”. When hashing data, Salting is the process of placing an additional bit of data into the hash process to assure the result is unique.

Think of it as a method to make your password stronger. By doing this you thwart certain types of attacks, specifically Rainbow Table attacks, where there is already a massive dictionary of pre-computed hash values available that a hacker can compare to customer’s (loose definition) hash database, which will tell them the passwords used. If a Salt is included when the password is hashed the dictionary is worthless unless it is a very large dictionary since the resultant hashes will be different from the dictionary. E.g If my password was “bob” and my Salt was “bigbadpasswordstuff” I would pass “bobbigbadpasswordstuff” through the hash, which would generate a different hash than just “bob” itself. A Rainbow Table is likely to contain “bob” but probably is not going to contain “bobbigbadpasswordstuff”.

Salt values are of maximum value if they are not revealed since it will strengthen the password but even in the case where a salt is discovered they still hinder Rainbow Table attacks since the entire table would need to be recomputed with the salt to identify the passwords easily. It won’t stop an attacker but may slow them down.

>>>

And if you survived this far, thanks for coming along. Next time on security concepts of the not-so-rich and not-so-famous we have:

When good Encryption Goes Bad or “What the hell happened to WEP?”

Are there cases where encryption is a liability?

What is Hacking?

The Terms of Service Tightrope

Physical Security

and

Social Engineering

Continue on to Part 2


Benefits of the Sony Online Security Breach (or: What you should take away from the Sony debacle)

Posted by on June 1, 2011 Comments Off

Many have looked at the negatives of the Sony Online breach – the cost to their reputation, the number of consumers that have departed for the Xbox or other online games, the cost financially of a multi-week outage, and the public scrutiny that is sure to follow as the government decides Sony is a good group to drag across the coals in hearings and make campaign promises on.

To the consumer quite a bit of personal data has been lost. Just about everything you would need to forge someone’s identification was lost except for your social security number (or whatever your country uses as a unique ID for each citizen). Everything else you would need to steal someone’s identity could be found through family tree websites and public records databases.

What are the benefits of such a horrendous situation?

The benefit is that a large number of people (100+ million accounts total), especially younger ones with an online future, are receiving a relatively low risk opportunity to learn good security practices, which they will carry with them for many years to come. A great example is my friend Logan setup a password manager on his computer voluntarily only a few weeks after the Sony news broke. He clearly saw the risks and acted even though he is a Xbox gamer.

Specific lessons individuals should take away from the Sony compromise:

  1. Assume your data might be compromised. If you cannot trust a company like Sony to have world-class security whom do you think you can trust? The answer should be “No one” because that is correct. Even if a corporation spends a massive amount on security if there is a targeted attack against them by top tier hackers with cash backing there is a decent probability they will recover valuable data. Not even considering hackers, what about corporate data being stolen by regular employees? You don’t need to be paranoid, just reasonable in your expectation of security.
  2. Never use the same password on multiple websites. You don’t need a 500 character password, just something unpredictable and practical for each website, perhaps a phrase or something else not based on a dictionary word. If you want some examples of bad passwords check out the Gawker compromise top 250 passwords list. There are several articles on the web regarding how to create or track and secure your passwords so I won’t cover that here.
  3. Do not use payment methods tied directly to your bank account. Put a buffer between account compromise and your bank account; use Credit Cards, PayPal or anything else that will not automatically withdrawal from your cash supply. Sony states they had the credit card database encrypted. What about all those other websites that have your credit card data? You clicked the “Do not save my info” button so you are safe, right? Maybe. Credit cards and pre-paid accounts provide significant benefits that debit cards do not, with the biggest one being that if a credit card receives fraudulent charges no money has disappeared out of your bank account.
  4. Don’t give away more data to a single entity than you are willing to have stolen. We are all culprits of leaking too much data onto the web now that social networking has taken over. I personally believe that most privacy is a myth and you need to accept there will be a certain amount of information floating around the Internet about you; with that said you don’t need to make yourself a target unnecessarily or make that data easy to find. If a company doesn’t need to know certain information don’t give it to them.
  5. Consider using misinformation where appropriate. This is a little less intuitive than the other items but something to consider is creating an alternate identity that is utilized for any websites that you do not anticipate requiring accurate personal data. In this situation you give a website the wrong real name, birthdate, address, phone number (google voice to the rescue) and use an email address that is only used for low value websites (plenty of free email addresses available from Hotmail, Gmail or other sites). Sony doesn’t need to know your real birthdate, just one that makes you over 18. Give as little data as necessary and if you want to be paranoid – give different information to different websites. In the worst case lets say ten sites you visit are all compromised in a year – now the underground web is filled with a hodgepodge of worthless information sprinkled with a few real tidbits about you, probably not a bad place to be. The only complexity with this tactic is you need a reliable, secure method to manage private data such as a password manager such as Keepass, SplashID, Password Safe or one of the several others since losing your fake information might result in permanent loss of access to your accounts.