The technical press is full of reports about the leak of a hashed password file from LinkedIn. Worse yet, we hear, the hashes weren’t salted. The situation is probably both better and worse than it would appear; in any event, it’s more complicated.

Let’s look at the issue of “salting” first. Salting a password file is a technique that dates back to a classic 1979 paper by Morris and Thompson. Without going into the technical details, it generally helps to protect a large, compromised hashed password file against guessing attacks. It’s often less help against a targeted attack, one where the bad guy wants your password. Furthermore, there are situations where conventional salting simply isn’t possible, notably in authentication protocols where both sides need to know a shared secret—typically, either the password itself or a hashed version of it—and there’s no way for one side to send a userid and the other to reply with the salt before authentication. Neither seems to be the case here, but beware of blanket statements that “passwords should always be salted”.

A second common theme in the uproar is “pick strong passwords”. A strong password isn’t a bad idea per se; however, it’s not humanly possible to pick dozens (at least) strong passwords and never write them down anywhere. More importantly, it is very far from clear that password-guessing attacks are the real problem, as compared with keystroke loggers, phishing sites, and server compromise. Fiorencio et al. argue very convincingly that these other threats are far more important today. In fact, in this particular incident server compromise is a very real worry. Was a server compromised, and hence able to transmit all plaintext passwords as they were entered? That depends on both the LinkedIn architecture and the extent of the compromise. LinkedIn assuredly knows the former, though outsiders don’t; the latter may be a lot harder for anyone to ascertain. I can imagine many possible architectures and failure modes; some would imply risk of plaintext capture, while others would not. I can even come up with architectures where the password file could have been compromised without the username list being exposed. It would be unconventional to do things that way, but it would work.

Speaking about common designs and threat models, though, the odds are high that user names were compromised, too, and that accounts with weak passwords are therefore at risk from a guessing attack. We do not know if there was a deeper compromise that would expose strong passwords; if that happened, the accounts that are at most risk are those that have been active—one to which you’ve logged in—“recently”, i.e., since the penetration. Less active accounts are at risk only from guessing. LinkedIn says they’ve reset a lot of passwords, but password reset and recovery schemes tend to be very weak. That implies you should go through that process very soon, and change your password from whatever it is they’ve set it to.

There’s another ironic point here. Once you log in to a web site, it typically notes that fact in a cookie which will serve as the authenticator for future visits to that site. Using cookies in that way has often been criticized as opening people up to all sorts of attacks, including cross-site scripting and session hijacking. But if you do have a valid login cookie and hence don’t have to reenter your password, you’re safer when visiting a compromised site.

There’s one more point: if you reuse passwords across different sites (and most people do, given the impossibility of following conventional advice), you’re at risk on very many other sites. In fact, password reuse is a far bigger problem than weak passwords.