This past week has had a flurry of com­puter secu­rity sto­ries. Among them are yesterday’s announce­ment by Kasper­sky that the recently-​​noticed Flame mal­ware has defin­i­tive con­nec­tions to Stuxnet. Closely related is a set of sto­ries regard­ing leaks from the Obama admin­is­tra­tion regard­ing Amer­i­can cyber­at­tacks on other coun­tries. And, in the midst of this, we dis­cov­ered that LinkedIn had weak pass­word secu­rity.

Let’s take a tour through these sto­ries. There’s much to see.

The Flame and Obama sto­ries are pretty tightly linked, so we can look at them together. Both Flame and Stuxnet appear to have tar­geted Iran, though they are suf­fi­ciently generic that they could be used any­where, and on anyone.

The good news about them is that they were writ­ten well enough to be highly unlikely to cause col­lat­eral dam­age. In that regard, they illus­trate the poten­tial for cyber­war­fare to be con­ducted in a very clean, tar­geted fash­ion. It has a sim­i­lar appear­ance to the increased use of smart bombs begin­ning in the 1990s, but with a much lower cost of implementation.

There’s bad news as well, though. We’re now embark­ing on a new form of war­fare, and it’s one at which the United States has a decided dis­ad­van­tage. For exam­ple, we could hit Afghanistan with all of the cyber­war tools at our dis­posal, even aim­ing at the civil­ian pop­u­la­tion, and almost nobody would notice the dif­fer­ence. Were they to do the same to us, our econ­omy would be brought down imme­di­ately, and with broad, long-​​lasting reper­cus­sions. The level of asym­me­try goes down a bit as the oppo­nent shifts to, say, Rus­sia or China…but it doesn’t go down all that much. Were each of us to do the worst to each other, the US would end up worse off.

This is an impor­tant con­sid­er­a­tion, because it’s very dif­fer­ent from the nuclear stale­mate between the United States and the Soviet Union. That stale­mate worked because the con­se­quences of a nuclear war were too hor­ri­ble to both sides for either to seri­ously con­sider it. And that led to a num­ber of safe­guards that were designed to min­i­mize the chances of one side wrongly con­clud­ing that the other had ini­ti­ated a preëmp­tive strike.

In the case of a cyber­war, the asym­me­try is suf­fi­ciently great that it’s hard to imag­ine a sce­nario where there is suf­fi­cient dis­in­cen­tive for a first strike from some­where out­side the US. Con­versely, there is sub­stan­tial dis­in­cen­tive for a first strike from the US against a nation with cyberweaponry.

Sev­eral mem­bers of Con­gress have com­plained that the leaks of cyber­se­cu­rity pro­gram infor­ma­tion from some­where in the Obama admin­is­tra­tion has made the United States more vul­ner­a­ble to attack. As some­one who has been involved in cyber­se­cu­rity for a num­ber of years, I can assure you that this is patently false. Why? Because those who would engage in such attacks have long been aware of the leaked details. If they’re savvy enough about cyber­se­cu­rity to under­take such attacks, they’re well aware of far more than has been leaked. These may be some of the worst-​​kept secrets in cyber­se­cu­rity over the past decade. Yes, these pro­grams have been under­way since well before Obama threw his hat in the ring to run for President.

On a more local level, LinkedIn’s secu­rity breach hor­ri­fied me for one rea­son in par­tic­u­lar. The breach was made pos­si­ble by a truly ama­teur­ish secu­rity vul­ner­a­bil­ity. While it’s not exactly at a kinder­garten level, it’s cer­tainly a lower-​​elementary level. To under­stand what they did, you first need to under­stand how pass­word val­i­da­tion has evolved over the past few decades.

In the early days, a server would store user­names and pass­words as sim­ple text in a data­base. A user would log in, pro­vide the user­name and pass­word, and the server would per­form a sim­ple com­pare to see if they matched. Nat­u­rally, this meant that gain­ing access to that data­base would gain the keys to the king­dom, allow­ing you to become any­one and do any­thing they were per­mit­ted to do.

Two tech­niques were devel­oped to counter this sort of attack. One obvi­ous one was to encrypt the data­base. This meant that an attacker would need the decryp­tion key for the data­base, which the server always had to have avail­able. This model proved to be weaker than mak­ing use of hashing.

Hash­ing is a one-​​way math­e­mat­i­cal oper­a­tion per­formed on data. The idea behind it is that you can tell if Doc­u­ment A and Doc­u­ment B are the same, with­out look­ing at the con­tents of either one, by run­ning them both through the same hash algo­rithm. If the doc­u­ments are the same, they’ll both pro­duce the same hash result. The great thing about hashes is that one can­not recon­struct the doc­u­ment with the hash, even with the knowl­edge of which algo­rithm was used to gen­er­ate the hash (hence being a one-​​way operation).

Thus, servers began to store hashes of pass­words, rather than the pass­words them­selves. When the user first cre­ates the pass­word, the hash of the pass­word is stored in the data­base. Since the hash is one-​​way, an attacker get­ting access to the data­base would pre­vent gen­er­a­tion of the pass­word from the hash. But when the legit­i­mate user of the server enters the cor­rect pass­word, the pass­word is hashed, com­pared to the stored hash in the data­base, and val­i­dated at that point.

This is the method LinkedIn used for stor­ing pass­words. So what was the problem?

The prob­lem is a com­bi­na­tion of increased com­put­ing power and the use of stan­dard hash­ing algo­rithms. If we can assume that every­one is using the same few hash func­tions (an accu­rate assump­tion), then an attacker could build a data­base con­tain­ing all pos­si­ble hashes of all pos­si­ble com­bi­na­tions of char­ac­ters. Why not? Disk capac­ity is mighty cheap these days, and an attacker could build that data­base once and use it on dozens of dif­fer­ent servers. Such a data­base of hashes is called a “rain­bow table”. An attacker with the server’s pass­word data­base merely needs to look up the hash in the rain­bow table, and instantly gets the asso­ci­ated password.

Plenty of salt in this hash

Com­bat­ting rain­bow tables is not dif­fi­cult. The server merely needs to “salt” the hash­ing algo­rithm. This is a ran­dom value that can be cre­ated once for a par­tic­u­lar server, or, bet­ter yet, once for each user; the value is then hashed with the pass­word when stor­ing it in the data­base. By doing this, an attacker would have to have cre­ated a rain­bow table for every pos­si­ble salt, which elim­i­nates the value of cre­at­ing such a rain­bow table in the first place. This illus­trates why hash is much bet­ter with a lit­tle salt.

I’m over­sim­pli­fy­ing the vul­ner­a­bil­ity and solu­tion a bit, but the next level is merely more sophis­ti­cated, and doesn’t really add any­thing to the dis­cus­sion. If you’re inter­ested, a few of the related arti­cles below go into more detail.

The most basic of secu­rity reviews would have uncov­ered the lack of salt­ing LinkedIn’s pass­word hashes (I know, because it’s one of the first things I look for when I con­duct a secu­rity review). For this rea­son, one can deduce that the pass­word leak is the tip of a very large ice­berg of secu­rity issues at LinkedIn — and eHar­mony, and Last​.fm, who also had sim­i­lar types of breaches. And that is cause for great con­cern, given the amount of per­sonal infor­ma­tion in these com­pa­nies’ pos­ses­sion. Unfor­tu­nately, the United States applies no lia­bil­ity to such breaches, and thus far few peo­ple have been run­ning for the exits when they occur.

Of course, those pass­words are use­ful for get­ting into people’s LinkedIn accounts. But most peo­ple use the same pass­word on many dif­fer­ent sites, includ­ing, say, their GMail accounts and their banks’ web­sites. And that’s where the real value of the pass­words lies. Your LinkedIn user­name and pass­word can be sold to oth­ers, who will try that com­bi­na­tion in dozens of loca­tions in very short order.

If you’d like to see if your pass­word was among those posted to a web­site in Rus­sia, you can check here. And, if you’re curi­ous if par­tic­u­lar com­pro­mised pass­words were used by any­one, you can try those out, too. Yes, “pass­word” was among the com­pro­mised pass­words. So were sev­eral com­mon exple­tives. Try it out for your­self. Share with us some of your favorites.

Obvi­ously, if you haven’t already, it’s a good time for you to change your pass­words on these ser­vices, if you use them, and make sure you’re using dif­fer­ent pass­words at each ser­vice you fre­quent. One way you can do this safely, while still mak­ing it pos­si­ble to remem­ber all of the dif­fer­ent pass­words, is to have a con­sis­tent pass­word “core” that you use every­where, but change a par­tic­u­lar part of it based on the spe­cific server (such as sprin­kling the first three let­ters of the domain name in the password).

We’re all vul­ner­a­ble in so many ways, par­tic­u­larly in the devel­oped west­ern nations. We can at least take respon­si­bil­ity for our own secu­rity where pos­si­ble. In the woods, you don’t have to out­run the bear; you merely have to out­run your neigh­bors, who become bear food. On the Inter­net, you don’t have to be per­fectly secure, either; you merely have to be more secure than your neigh­bors, who become hacker food. Go forth and be safer.

Related arti­cles