An attempt to make the case for "hacking back"

Justin's recent post, "The illegality of striking back against hackers," presents a number of interesting issues with regard to organizations hacking in retaliation against those who hack them first. It is only fair that such an act should be allowed in light of the current state of our legal system. But as Justin correctly states, allowing retaliation is not a clear-cut issue and should not be considered lightly.

Hacking cases are complex. Beyond the cases where hackers go to the Internet to boast about their actions, it can be very difficult for law enforcement and prosecutors to track down the perpetrators. Facing a lack of resources, cybercrime investigators tend to focus their attention on issues such as child pornography. Hacking cases and the identity (or other) thefts that follow present great hurdles for millions of Americans each year.

Of course, there is a remedy for consumers - file a lawsuit. After LinkedIn's recent security breach, many quickly jumped at the chance to file. LinkedIn committed a grave error, and attention needed to be brought to the issue so they'll fix the problem and other companies will be warned as well. No amount of investment in security, however, will make a system perfect and neither will it make a company immune from lawsuits and damage to their reputation when breaches occur.

Likewise, there is also a solution for the hacking victim - file a lawsuit. The CFAA allows a civil suit to be brought for certain damages, but it carries with it a multitude of problems. Often, the hacker could only be found by an investigation that would, in turn, violate the CFAA (see Justin's point number 2). They may be located in another country. They may not have any money, and even if they do, there may be no legal process for getting to it. For these reasons (and many others), companies like LinkedIn are often required to take the beating from the press and users, spend a lot of money beefing up security, and keep their fingers crossed.

Until law enforcement and prosecutors make these cases more of a priority, American organizations (and therefore, consumers) will be left without a true means of protecting themselves. But suppose we modified the CFAA to allow a self defense-type approach. In some ways, being hacked is like being punched in the face. If you retaliate in either situation, it's possible that others will come in defense of the attacker (imagine a bar fight where all of your friends are already outside, and you're now facing five guys twice your size). Similarly, if you were in a crowd and weren't sure who the punch came from, you can't just start hitting everyone to get back at the true puncher. However, if you can find them and timely respond, you may be able to defend yourself from further harm.

There are a few ways in which such a modification would be helpful:

1. Investigation - Allowing victims to hack back would allow them to collect the information that would be essential to any civil or criminal case - information like the IP address of the hacker.
2. Security Improvement - Patching security issues is much easier if you know how the infiltration happened. Further, knowing what resources hackers are using would allow technology security teams to better plug the holes in their networks. Perhaps the statute could require mandatory reporting so that the government could collect data in an effort to study developing patterns in the hacking world.
3. "Cathartic Chest Pounding" (Justin's words) - Billion dollar corporations have at least one thing that common hackers don't - a billion dollars. Not every business has the ability to dedicate essentially unlimited resources to protecting themselves, but these do. Hacking back may result in more attacks at first, but the right successes might turn hackers away. (The problem here, of course, is that if large companies make themselves essentially hack-proof, the market for unauthorized data will result in attacks on small business that have no such resources.)

Obviously, there's no easy solution to this problem, but rest assured - the CFAA is not likely to hinder everyone. Now we have the waiting game to see how prosecutors, Congress, and corporations will respond.

Read More

LinkedIn's negligence in failing to adequately secure user passwords

As most of you are aware, LinkedIn's site has apparently been hacked, and 6.5 million passwords of users were exposed (if you weren't aware, change your password); the likely attacker operated out of Russia. Take all I say with a grain of salt, as LinkedIn has recently tweeted "[o]ur team continues to investigate, but at this time, we're still unable to confirm that any security breach has occurred. Stay tuned here." But, I doubt that this is a false alarm, and for the uninitiated, let me translate that tweet in honest technology speak - "We've realized a breach occurred, we are panicking in a board room and attempting to spin this in the least damaging light possible."

In this day and age it is unsurprising that a large site has been owned by hackers; I think most would agree that this has become commonplace. But, it appears that corporations are failing to evolve based on the failures of their compromised brethren. While LinkedIn should be applauded (quietly) for their use of SHA-1 hashes to store passwords, they should then immediately be criticized for failing to also salt the passwords, or use a more cryptographically strong algorithm such as SHA-256, or SHA-512.

A quick explanation will make their negligence clear. Let us assume that the chance of disclosure of passwords is merely a function of exposure to the internet, multiplied by the traffic of (aka attacks on) the company, divided by the security measures in place to prevent data disclosure. The equation can be noted as EXP * TR / SEC = DISC(%). That equation is of course not scientific, but it helps to explain the current atmosphere of the internet. The variables EXP and TR are hard to control by any company that is out on the internet, and in fact, most companies interested in making a profit want those values to increase. The key to business viability, trust of the consumer (industry respect), and meeting the responsibility placed on you as a data steward is the company's SEC value. I would also argue that the more vital the service you are offering on the internet is, the more responsibility and obligation you have to increase your SEC value.

By using unsalted SHA-1 hashes, LinkedIn essentially conceded that the value of DISC would be enormous, and it did so by negligently failing to salt those passwords. I say negligently because it is commonly understood in the industry that use of a salt makes cracking password significantly harder. Take for example the NIST Enterprise Password Management Guide, which states:

The use of salts also makes cracking more difficult—for example, using 48-bit salting values effectively appends a 48-bit password hash to the original password hash, assuming that the attacker does not have access to the salting values and that the salting values are well-chosen. So a salted password might have the same effective length, and therefore be roughly as time-consuming to crack, as an unsalted password  that is several characters longer. Also, salts typically use the full range of possible values, unlike passwords that have limited character sets, so salts can strengthen the effective password complexity. Policies for password expiration, length, and complexity should take into account the use of salts.

The use of salts defeats, or at least slows down the use of "rainbow tables," which are tables of already calculated hashes of passwords. So, if I know that your site uses SHA-1 hashing, I take a wordlist of X number of words, and hash all of those into a database. Then, when a Russian hacker discloses all of your passwords, I merely correlate the values disclosed with the values in my table to discover passwords. I may not get all of the passwords, because the dictionary file originally used normally does not have every word or possible combination of letters, numbers, and symbols used by individuals, but I am guaranteed to get a large portion because users typically have bad passwords (or shall I say weak/predictable passwords).

The use of salting defeats rainbow tables because the hope is that the potential "cracker" of the passwords is clueless on the salt used to hash the passwords by the particular site, so a traditional rainbow table is useless. Thus the hacker would need to create a rainbow table for every possible iteration of the salt - an extremely time consuming task, and wholly not worth it. In all of these password cracking scenarios, there is a race condition going on. Specifically, that the number of entrants to the race decreases exponentially as the complexity and difficulty of the passwords that could be cracked increases (the value of SEC increases). As an internet company you need not outrun the bear behind you that is attempting to expose your security weaknesses, you merely need to be running faster than the others around you.

It is no argument for LinkedIn to assert that they could not have feasibly implemented a salt on their SHA-1 hashes, nor is it an argument for them to assert that others are using SHA-1 hashes. It is widely known that SHA-1 has been significantly weakened, and SHA-2 (256, 512) algorithms are better alternatives - the federal government urged federal agencies to stop using SHA-1 in March, 2006, and a competition has been running since 2007 to come up with SHA-3.

We must assume that password hashes are going to be disclosed because of the plethora of weaknesses in software currently implemented worldwide. What we shouldn't assume is that the stewards of our data are failing to exercise due diligence in protecting our information. The driver of an increase in the value of SEC is the real world accountability for preventable security failures.

Update: As expected, LinkedIn has confirmed the breach.

Read More