Adobe Hack - checking if your data was leaked

[PierreVandevenne]

As you know the encrypted Adobe password file has been in the wild for some time.

This guy has gotten a copy and implemented a small checker that lets you know if your data can be found in the leaked file

https://lucb1e.com/credgrep/

I tested two e-mail addresses I would have been likely to use on Adobe's site over the years.

Here is the web result for the account that was compromised (slightly edited by myself not to expose it more than it already is)

Your search has been succesfully performed. The result:
Userid: 63XXX
Email: XXXXXXXXXXXXXXXXXXXXX
Encrypted password: HlBr76U+PIE=
Password hint:

And here is the mailed response for another account, which I apparently did not use on Adobe's site

---
Hello! You (or someone else?) did a search on your email address at lucb1e.com/credgrep and asked to be emailed when we had the search result. Here they are:

Fortunately, your email address was not found in the hacked Adobe file. Lucky you, mine was!

PS. your email address was stored only to send you this email. You will not be contacted again, and I will not sell your email address to anyone else. In fact, it will be deleted in 48 hours. If you did not ask me to send this email and you're somehow getting a lot of them (which would be weird), reply to this email and I'll look into it!
---

As far as I am concerned, it is interesting to note that I have NOT been warned by Adobe that my account was potentially compromised.

[tuthill]

Thank you for that.  I input the 3 emails I customarily use and one came back as compromised.  Interestingly Adobe made me change my password once again when I logged on to do that very thing (again).

[Slobodan Blagojevic]

A question for encryption experts: does the length of the encrypted password correspond with the length of the original (non-encripted) password?

[howardm]

A question for encryption experts: does the length of the encrypted password correspond with the length of the original (non-encripted) password?

In general, no, the length of the encryp. passwd is not indicative of the length of the original. However, the
'strength' of the original password is dependent on the original length and the universe of alphabet used which
is why it's always a *good* thing to use UPPER/lowercase, num5ers and punctuation!%$@

[mrenters]

A question for encryption experts: does the length of the encrypted password correspond with the length of the original (non-encripted) password?

No. The "encrypted" passwords are generally a cryptographic hash of the real password. The hash function used returns a certain constant number of bits that is then encoded as characters and stored. A hash function is a one way operation - it is easy to compute the hash from the password, but it is infeasible to compute the password from the hash.

When a user signs into a system, they provide their password which is then run through the hash function and compared to the stored hash. If they match, then the password provided and the stored password must have been the same.

Because the hash function is one way, it is infeasible for an attacker that has a list of hashed passwords to determine what the actual passwords are, so the method used is to generate a list of hashes from commonly used passwords and then compare those hashes with the stolen ones. For a given hash function the password "qwerty" will always generate the same hash so if you compute the hash for "qwerty" you can scan your stolen list and find all users who have used "qwerty" as their password.

Better programmed sites add a salt (extra text) to the password before hashing it. For example, you might add the username or email as a salt before hashing. In my "qwerty" example, I might hash "martinqwerty" instead. This ensures that although user martin and user michael might share "qwerty" as a password, the hashes will be different because of the extra username added before hashing.

Martin

[Christoph C. Feldhaim]

....
Because the hash function is one way, it is infeasible for an attacker that has a list of hashed passwords to determine what the actual passwords are, so the method used is to generate a list of hashes from commonly used passwords and then compare those hashes with the stolen ones. For a given hash function the password "qwerty" will always generate the same hash so if you compute the hash for "qwerty" you can scan your stolen list and find all users who have used "qwerty" as their password.
...

At least for the MD5 hash function which has been a standard for a long time there have been successful attempts to change a file in a way to produce the same hash value after manipulation than the original. In case of a password this would mean an attacker could create a password which returns the same MD5 hash than the original password if he has access to the MD5 hash of the original password. In any case it is advisable not only to create safe passwords, but also to change passwords on a regular scale.

[mrenters]

At least for the MD5 hash function which has been a standard for a long time there have been successful attempts to change a file in a way to produce the same hash value after manipulation than the original. In case of a password this would mean an attacker could create a password which returns the same MD5 hash than the original password if he has access to the MD5 hash of the original password. In any case it is advisable not only to create safe passwords, but also to change passwords on a regular scale.

While is it true that it is possible to have two files that hash to the same MD5 value, it isn't clear that this is possible for passwords given the 6-16 character limit and the limited character set allowed for passwords.

The amount of work finding hash collisions may also not be worth the effort when you consider that you're able to access many of the accounts because nearly 2 million of them used '12345678' as the password. (reference: http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/)

Martin

[PierreVandevenne]

No. The "encrypted" passwords are generally a cryptographic hash of the real password.

What's been said in response to Slobodan's question is generally correct and would actually be correct if Adobe had used a proper method (salted hashes, eventually with an intentionally slow hashing algorithm) but one of the salient points here is that apparently they used DES or 3DES in ECB, without even proper padding. So the answer is YES, in this case the length of the encrypted password is linked to the length of real passwords plus some mandatory alignment padding. Opens lots of avenues for cryptanalysis. Turns out the initial Adobe release was correct when it said "encrypted passwords". I thought they had used salted hashes or, at worst, unsalted hashes.

This being said, I would be surprised if an attacker that compromised the system enough to leave with flagship applications source code and a huge password trove, would not have had the opportunity to leave with the password.

One ironic twist could be that the attacker also thought he'd find password hashes and didn't think he had to look for keys... You never know. One thing is sure, if he has the key, he wouldn't leak it.

[Christoph C. Feldhaim]

While is it true that it is possible to have two files that hash to the same MD5 value, it isn't clear that this is possible for passwords given the 6-16 character limit and the limited character set allowed for passwords.

The amount of work finding hash collisions may also not be worth the effort when you consider that you're able to access many of the accounts because nearly 2 million of them used '12345678' as the password. (reference: http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/)

Martin

Yup - should be practically next to impossible - but only next to ....

[MarkH2]

Easy to crack the password: "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn1"

Cracking with 30 billion guesses per second with just $800 of hardware.



Some related articles of interest.

How the Bible and YouTube are fueling the next frontier of password cracking http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/2/

What Really Makes a Password Strong? http://iandunn.name/what-really-makes-a-password-strong/

Haystack Logo
... and how well hidden is YOUR needle? https://www.grc.com/haystack.htm

Why secret questions are your No. 1 security flaw http://www.cbsnews.com/8301-505143_162-57483289/why-secret-questions-are-your-no-1-security-flaw/

I use KeePass.

[Peter McLennan]

Interestingly, the site is no longer available.

[PierreVandevenne]

Other sites are popping up anyway, some of them using the checking process to advertise their solutions.

https://lastpass.com/adobe/

Maybe that non-profit guy got stopped by Adobe, maybe he had too much load/bandwidth when he was covered in the press. It's quite easy to get your hands on the full file anyway.

More than the mind blowingly bad security options taken by Adobe, what I am a bit pissed at is that I was able to make a purchase a couple of days before the hack was announced (and a few weeks after it was discovered) without any special notification by Adobe, and din't get any notification after the fact. But I actually don't remember if I changed my password, as I often use a rather strange password strategy.

Basically, what I often do for sites I don't plan to visit on a regular basis (unlike Amazon for example), is to type a random password I don't even plan to remember. When I need to log in again, for example for a purchase on Adobe's site which happens once every 1-2 years on average, I just use the lost password procedure to reset a new password, which I don't plan to remember either anyway.

(-) I need to reset the password each time, but I probably would have had to do it anyway in about 50% of the cases.
(-) I need at least one very stable e-mail address, or an address I have total control on but that has been the case for the last 20 years.

(+) I don't need to worry about an eventual leak impacting the things I use often for which I have more conventional longish passwords
(+) I don't need to worry about a leak impacting other sites I don't use often
(+) I don't need have to remember or write down anything

This being said, this remains a big issue, especially now that OS makers (Apple/MS) and essential cloud service offerings make it more difficult to avoid having multiple stable essential passwords.

From an IT security point of view, the fact that Windows 8.x and the latest OS X versions almost try to impose a local login with a cloud service password is especially worrying long term. You can spin in any way you like, this is a connection between a remotely stored password, transiting over the wire in a way that is supposedly secure today (or not, see MIM NSA and GCHQ attacks) and total control over your local machine.

[BernardLanguillier]

Basically, what I often do for sites I don't plan to visit on a regular basis (unlike Amazon for example), is to type a random password I don't even plan to remember. When I need to log in again, for example for a purchase on Adobe's site which happens once every 1-2 years on average, I just use the lost password procedure to reset a new password, which I don't plan to remember either anyway.

That makes a lot of sense.

Cheers,
Bernard

[PhotoEcosse]

Basically, what I often do for sites I don't plan to visit on a regular basis (unlike Amazon for example), is to type a random password I don't even plan to remember. When I need to log in again, for example for a purchase on Adobe's site which happens once every 1-2 years on average, I just use the lost password procedure to reset a new password, which I don't plan to remember either anyway.

Brilliant.

I will certainly adopt that strategy.

It also pays to change your mother's maiden name regularly. Just don't tell your Mum!