Weak Encryption Is Securing Adobe’s Password File.

The scoop at arstechnica.com is that Adobe’s attack from one month ago netted hackers a 9.3 gigabyte file full of passwords.  Approximately 130 million passwords and clues to the password are present in the file.  And while Adobe did take the time to protect it – encryption was used, although it’s nowhere as powerful as AlertBoot’s laptop disk encryption – the company behind Photoshop and other creative software is receiving flak (and deservedly so) for not following best practices.

Password Best Practices – Hashing

According to arstechnica.com, Adobe erred in many ways when it came to protecting the password file:

  • Encryption was used (which is reversible) as opposed to salted hashes.
  • The encryption that was used, Triple DES, is not really considered secure anymore.
  • ECB mode was used for the Triple DES.  Long story short, ECB reveals clues about the encrypted content, making that much easier to break.

Why are hashes, and not encryption, considered to be best practice when it comes to passwords?  Basically, because the former is irreversible.  The example that’s been used is that “ground hamburger can’t be converted back to steak”: that is, there is no way to figure out the original password based on the hashed password.  This is even if you know which algorithm (and hash salt) was used.

The story is different for encryption.  Under encryption, the original content can be recovered if you figure out the encryption key.  This is tantamount to obtaining steak from ground chuck, assuming you can find the meat grinder that was used (the analogy breaks down somewhat but that’s the gist).

Of course, if you’re trying to protect documents, hashes are useless because you want the ability to recover the original content.  Why protect a file before sending it via email if the recipient won’t be able to read it (since it’s irrecoverable)?

But passwords are a different matter.  To be honest, there’s no need for anyone to know the specifics of a password. All that’s required is that it matches what’s on file.  If you type a password and it matches the one on file, you’re in.  If they don’t match, you’re not.

So, you might encrypt the contents of a folder, but you’d want to use a hash to secure the password to that folder.

Why Hashing Over Encryption?

On the other hand, the fact that a string of characters will always end up as the same hash means that it, too, presents problems.  Let’s revisit our ground chuck example.

It was noted that under a hash, steak will always result in ground chuck, and that there’s no way to reverse it.  This analogy is a little wrong because it’s obvious that you’ll get ground beef from steak if you pass it through a grinder of some sort.  A truer analogy would be that the steak will eventually get you pureed tomatoes.  How?  Who knows?  But that’s what happens when you hash passwords: there’s no way to figure out the original password from the resulting hash.

And, you’ll always get tomato puree from steak.  That’s the point of a hash….and that’s its weakness, since you can reverse engineer it in this manner:  You have tomato puree.  You have no idea what it started out as.  How can you find out what that tomato used to be before it got hashed?  You start feeding the grinder (the hash algorithm) stuff.  At some point, you feed it steak and you get tomato puree.  Voila.  Now, whenever you see tomato puree, you know it started out as steak.

Now, take that and apply it to passwords and their hashes.  If a certain password will always end up hashed in the same manner, then a hacker feeds the algorithm a bunch of passwords to obtain the hash.  Perhaps he’ll create a list of passwords and their respective hashes (this is known as a rainbow table) since he knows they can come in handy later.

There are ways around this problem, like adding a “salt” to any passwords before hashing them.  However, frequency analysis of password lists, combined with prior knowledge of which passwords regularly show up in a given set, means there will always be ways to figure out the original password from a hash.

So why are hashes, and not encryption, considered best practice when it comes to protecting passwords?  Because with a hash, you have to “break” each individual password, whereas if you used encryption, all you have to do is figure out the one encryption key and 130 million passwords will be revealed.  (Technically, you could encrypt each of the 130 million passwords with a different encryption key, but no one would be willing to do that because managing 130 million encryption keys is hard work…so chances are you’ll be using the one key).

And yet, figuring out that one encryption key could very well be impossible.  It’s the reason why encryption is used to secure the day to day financial transactions on the web (accessing bank accounts, buying stuff from Amazon, buying and selling securities via your online brokerage account, etc.).

Related Articles and Sites:

Comments (0)

Let us know what you think