Last week, we reported that, as a sophomore at Harvard, Facebook founder and CEO Mark Zuckerberg used Facebook members’ login information to break into their private email accounts and read their emails.
A lot of people were appalled by this. Some said it was indicative of a flawed moral character. Some said it might rise to the level of a felony. Others yawned and said, whatever, Mark was a college sophomore.
Missing in the discussion, meanwhile, was an analysis of Mark’s hacking technique and a nod to how clever it was.
As we reported, Mark described breaking into the private email accounts of two Harvard Crimson editors using the following technique:
- He scanned Facebook (then called TheFacebook.com) for members who described themselves as belonging to the Crimson.
- He then checked a Facebook system log for failed login attempts by these members (logins that were rejected for some reason, such as an incorrect password)
- He figured that the reason certain logins had failed might be that the members had accidentally entered the password or login IDs to other online accounts, such as their email accounts
- He tried to log in to the Crimson editors’ email accounts using the passwords and login IDs that had failed on Facebook
- He succeeded with two accounts–and read a bunch of the Crimson editors’ emails
When we heard about this technique, we immediately wondered: Why didn’t Mark just try the real Facebook login information? In other words, why didn’t he just assume that the Crimson editors would have used the same login IDs and passwords on their email accounts that they used on Facebook. Why did he need to use the failed logins?
We put these questions to Business Insider tech gurus Ian White and Andrew Fleming. Both said that, depending on how Mark built the original Facebook code, he might not have had access to the actual passwords, only the failed login info. They also said he might have tried the real login info first, and when it failed, moved on to the failed logins.
Good security systems, Ian White explained, don’t actually store passwords (because if they store passwords, someone with access to the database might be able to read and steal them). Instead, good security systems store a “hash” of the password, which is a string of gibberish created by running an algorithm on the password.
“Hashes” are useful because they are one-way: The algorithm can produce the hash from the password, but it can’t produce the password from the hash. Thus, even if someone with access to the database knows the hashing algorithm, he or she can’t produce the password from the information stored in the database.
For example, Ian explains, running a popular algorithm called md5() on “Henry Blodget” produces the following hash:
Running the same algorithm on the only slightly different “Henry Blodget2,” meanwhile, produces a very different hash:
Running the same hash on those strings, meanwhile, produces more gibberish.
When you log into a system that uses hashes, the system runs the algorithm on the password you enter and then compares the hash to the hash stored in the database. If the hashes match, voila, you’re in.
With a well-protected system, in other words, no one at the company can tell you your password, because it’s not stored in the system. The only thing stored in the system is the hash, and you can’t reverse-engineer the password from the hash. Such systems, therefore, can merely let you CHANGE your password–they can’t tell you what the password is.
Now, systems with poor security don’t work this way. Some systems store passwords using “plaintext,” which Ian says would give the system administrator full access to all the login and password information for the system.
So this begs the question, why did Mark use the failed login info to break into the Crimson editors’ accounts? Was it because the real login info was only stored as hashes?
Ian says this seems unlikely.
Having read the description of how Mark used failed login data, Ian said Mark probably used plaintext password storage when building the security system–because Mark did not seem too concerned with security and plaintext would make it easier for Mark to access password information. He also said it was surprising that Mark’s system would be designed to store failed passwords as plaintext but real passwords as hashes.
More likely, Ian says, Mark stored all the login info–failed and real–as plaintext and then first tried to break into the Crimson editors’ email accounts using the real Facebook login info. When this didn’t work, he then moved on to the failed logins and tried those. And in the latter case, he got lucky.
In any event, very cool stuff.