Home / Blogs

Password Leaks

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.

By Steven Bellovin, Professor of Computer Science at Columbia University

Bellovin is the co-author of Firewalls and Internet Security: Repelling the Wily Hacker, and holds several patents on cryptographic and network protocols. He has served on many National Research Council study committees, including those on information systems trustworthiness, the privacy implications of authentication technologies, and cybersecurity research needs.

Visit Page

Filed Under


I want to play devils advocate to Tom Cross  –  Jun 13, 2012 5:37 PM

I want to play devils advocate to one of the points you made in this post.

What is theoretically possible for the attacker is not always what is readily practical, and things that are easy to do tend to happen more frequently in the real world.

Once you’ve compromised a system with a password hash file, it is a relatively easy procedure to download that file and then log off. You do have a lot of password cracking work to do, but there are a whole lot of tools out there for doing this kind of cracking, and you can work on it in the comfort of your own home without the risk of being caught.

Certainly if the attacker breached a site’s server infrastructure, he could install a long term tap that would read out cleartext passwords, but this is a much more complicated thing to do. You’d have to figure out how the site’s authentication process worked and install tapping software. You’d run the risk of breaking the sites functionality while getting your tap to work. You’d probably want to set up a server on the Internet on another compromised host to collect the passwords from the tap. You could also store the cleartext passwords locally, but either way you’d have to access that collection point repeatedly in order to get your results back out, each time running the risk that law enforcement might be waiting for you and planning to trace your connection.

Of course it is possible to do all of this, but its much more work, and requires a more sophisticated and persistent attacker. I’ve never seen a toolkit for this operation floating around on the Internet. I am certainly aware of many many tools for cracking hash files. Although my personal knowledge of toolkits is certainly not a scientifically rigorous datapoint, this does lead me to suspect that hash file cracking is a much more common operation in practice.

Given that several large disclosures of consumer website password hash files has occurred over the past couple of years I think this merits inclusion as a principal threat to user credentials, particularly given that we know many of these passwords have been reused on other systems.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign


Sponsored byDNIB.com


Sponsored byVerisign