
Adobe confirms stolen passwords were encrypted, not hashed - monsterix
http://www.csoonline.com/article/742570/adobe-confirms-stolen-passwords-were-encrypted-not-hashed
======
neya
I don't know about the passwords, but my card was successfully stolen[1] and a
malicious transaction was initiated from another country. I know this was
because of Adobe for sure because I (co-incidentally) used a brand new, fresh,
unique e-mail address just for Adobe, and that email was released recently in
the dump that the hackers provided.

Luckily the malicious transaction was declined by my bank and they blocked the
card for me and they told me that someone had compromised my card details and
issued me with a replacement card free of charge.

I only keep posting this in every thread[1][2] about Adobe because I genuinely
want other Adobe customers to understand the gravity of the situation and
disable their compromised credit card and get it replaced by a new one as soon
as possible.

[1][https://news.ycombinator.com/item?id=6668013](https://news.ycombinator.com/item?id=6668013)
[2][https://news.ycombinator.com/item?id=6632385](https://news.ycombinator.com/item?id=6632385)

~~~
jordanthoms
So you know for sure your email was stolen in the attack, but how do you know
the credit card was?

~~~
neya
It was only the night before the hack had I bought an Upgrade to the CS6
suite. In all probability, mine would have been listed out in the recent few
transactions on Adobe's database, maybe?

There is only one other service I am using this card with - A stock photo site
and they haven't announced any security issues, yet. Plus, I always am
required to enter my card details on their site each time I buy something, in
all likelihood, they aren't probably storing the card on their servers, which
leads us to the culprit, Adobe.

Also, I am very security conscious in general. I am no security expert, but I
always use Linux/Mac to make transactions, with Firewalls, stuff like that.

------
jordanthoms
To play devil's advocate here, isn't this actually more secure than something
like MD5 or SHA1 without stretch factors or multiple invocations, assuming
that the key was not also stolen?

My reasoning is, that in order for an attacker to get the passwords out of
this dump, they have to break the 3DES encryption. Brute forcing the key is,
as I understand it, still very difficult, and without it they can't get any of
the passwords. If someone did find the key however, they'd have instant access
to all of the passwords no matter how complex.

On the other hand, if the passwords had been protected using an unsuitable
hash algorithm, the highly efficient GPU-based crackers would be able to find
millions of people's passwords very quickly, using the sophisticated
dictionaries and mangling techniques that are around now. Even quite complex
passwords can often be found in this way, since the GPU crackers have got so
fast they can try billions of combinations - e.g. even things like
"!)@(#*$&%^Test123" can be cracked. [1] [2]. Although, extremely long and
complex passwords should be safe.

Obviously, I'm not advocating we all switch to 3DES for our password storage,
and the huge risk here is that the key was also stolen - but I'm wondering if
my reasoning is actually right here, and that people without extremely strong
passwords are better off with this leak than if it'd been MD5.

[1] - [http://arstechnica.com/security/2013/05/how-crackers-make-
mi...](http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-
out-of-your-passwords/)

[2] - [http://arstechnica.com/security/2013/10/how-the-bible-and-
yo...](http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-
fueling-the-next-frontier-of-password-cracking/)

~~~
ReidZB
You're right --- had they used something other than ECB mode. For example, if
they used CBC mode with a proper IV, _assuming the key is not stolen or
compromised_ , the passwords would be quite secure.

The issue becomes verifying the passwords, then: supposing you have a CBC mode
oracle, like a HSM, how can you verify two passwords are the same? (This is
probably the reason they chose ECB mode in the first place.) In fact, if you
allow the user to test if two ciphertexts represent the same plaintext --- and
nothing else --- you still break the very definition of secure encryption,
namely that a secure encryption scheme should have, as one popular definition,
indistinguishable ciphertexts (usually under a chosen-plaintext attack).

So you have to develop some new way to measure security for the scheme, or
perhaps somehow measure the damage that an equality oracle can inflict upon an
IND-CPA secure scheme. The notion of indistinguishable ciphertexts roughly
reflects the inability of an attacker to reliably learn _any_ function of the
plaintext from the ciphertext. Throwing that idea out the window seems unwise,
since it's such an elegant idea. So, anyway, you're off in uncharted waters,
not a good place to be if you're securing users' passwords.

All of that is relatively complex, though, so just let me know if I need to
elaborate on some idea more. (I am never sure how in-depth to go in these
posts.)

~~~
yeukhon
> The issue becomes verifying the passwords, then: supposing you have a CBC
> mode oracle, like a HSM, how can you verify two passwords are the same?
> (This is probably the reason they chose ECB mode in the first place.)

Why is that? What's wrong with verifying a password in CBC mode with different
IV?

~~~
ReidZB
I am assuming that the DB server cannot decrypt. If the DB server has
decryption permissions, and it is compromised, then there's little need in
encrypting the passwords anyway as an attacker will simply decrypt them by
hand. (They may not get all of them before being detected, but they'd still
get some or most --- and they might look for high-value targets!)

Unlike ECB mode, you can't just encrypt the same password again and check to
see if the ciphertexts are the same --- the IVs will be different
(hopefully!). So, can you somehow check two ciphertexts with different IVs to
see if they represent the same plaintext? Nope, probably not: if you could,
then the scheme would no longer have indistinguishable encryptions under a
chosen-plaintext attack [1]. Briefly, this ability to test if two ciphertexts
represent the same plaintext would allow the adversary in the IND-CPA game to
simply encrypt both of the plaintexts and test them against the challenge
ciphertext. (See the [1] reference for more info on this.)

In fact, this is exactly the property you _don 't_ want. You don't want to be
able to determine if two users have the same password. If the DB server were
able to test ciphertext equality, then it could pairwise-test each pair of
users (or again only hunt for high-value targets).

If you were really adamant on encrypting passwords, I'd also suggest that we'd
need to pad the password out to the max password length to prevent the
revelation of password length. But of course, I _very_ strongly suggest
against password encryption. Still: that's another thing to consider in this
_hypothetical_ scenario.

[1]
[http://en.wikipedia.org/wiki/Ciphertext_indistinguishability](http://en.wikipedia.org/wiki/Ciphertext_indistinguishability)

~~~
antocv
Why go through all that when you could use the username or email together with
the password to encrypt it with 3DES ECB mode? Those would be unique and users
who have same passwords would still have different ciphertexts.

~~~
ReidZB
Sorry for my late response.

3DES has a block size of 64 bits, or 8 bytes. Unlike a hash function where the
whole input affects the whole output (the strong avalanche criterion and
whatnot), in ECB mode encryption, data is only changed on 8-byte block
boundaries.

So, for example, suppose the user's username was 8 characters, their email was
16 characters, and their password was some more characters. Then if you use

    
    
      3DES-ECB(uname || email || passwd)
    

where || denotes concatenation, then uname and email will take up 3 blocks and
the password will be the rest... this is essentially the same scenario as the
Adobe leak, except that the attacker now has to worry about how the password
falls across the block boundaries. In this contrived scenario, the password
starts a new block of its own, so the addition of the uname/email adds no
security here.

Since the uname/email lengths are public, you still might be able to cross-
reference sections of identical passwords with other users, depending on how
the blocks line up. In any case, this scheme still doesn't offer the
unconditional security level you'd like.

I'd recommend the Matasano crypto challenge [1]. It covers some material
similar to this pretty early on, so you get your feet wet here.

[1] [http://www.matasano.com/articles/crypto-
challenges/](http://www.matasano.com/articles/crypto-challenges/)

~~~
antocv
Wow thanks that was interesting, hadnt thought of that.

------
001sky
_Adobe says that they 've followed best practices for password storage and
protection for more than a year now..._

13 generations of photoshop

...and they're just getting around to this after CS6?

~~~
nwh
I wouldn't call Photoshop an achievement, it's a hodgepodge of old libraries
and bugs at the best of times.

Adobe refused to patch a vulnerability in CS5 at one point, telling people to
purchase and upgrade to CS6 (US$199) if they wanted to not be vulnerable to
malicious code execution. In response to the uproar they eventually backported
the patch.

[0]:
[http://www.macworld.com/article/1166779/adobe_will_issue_fre...](http://www.macworld.com/article/1166779/adobe_will_issue_free_security_patches_for_high_profile_creative_suite_apps.html)

~~~
smtddr
If Photoshop, basically industry standard in image-editing software, isn't an
achievement... then _nothing_ qualifies as an achievement. And this is coming
from someone who prefers GIMP on linux. I would love to produce something even
a quarter as popular & usable as Photoshop.

~~~
nwh
It's not. Have a look at what it's users have to put up with on a daily basis.

[http://bad-adobe.tumblr.com](http://bad-adobe.tumblr.com)

~~~
lttlrck
So you are saying any software cannot be an achievement if it has bugs and UX
issues? Or does it have to have a tumblr?

~~~
nwh
No. I'm saying that a program that costs a massive monthly fee and is pretty
much impossible to avoid in this industry is should not be this constantly
bad.

------
moloch
The leaked passwords were different lengths, of course they weren't hashed.

~~~
CamperBob2
(Sorry for the accidental downvote -- #%?!!@% tiny arrows, right next to each
other)

~~~
antocv
Its okay, I upvoted it back for you.

------
tptacek
_the top options being bcrypt, scrypt, PBKDF2, or SHA-2_

Thanks, CSO Magazine!

~~~
nitrogen
Why is SHA-2 in the list? [Looks like cperciva beat me to it, 0 minutes ago]

Something I've always wondered about SHA and MD5, though: if you feed the
output of a hash function into its input enough times, will you eventually
reach the original value? Will you have traversed the entire output space of
the hash, or will there be multiple closed loops, or perhaps even multiple
starting points converging on a single terminal loop?

~~~
tedunangst
There has to be at least one loop (or fixed point that maps to itself).
There's only a finite set of outputs, and the input space of strings as long
as a hash is at least that large (in theory, some output hashes may not be
possible to generate). Ideally you'd have very large, long loops, which
implies few collisions.

~~~
darkmighty
At least one loop, but it could be the trivial one (ideally?): take the
trivial case where the hash is simply a unit cyclic shift of the first N-bits
-- there's just the full loop.

------
gopalv
Xkcd said it best, this is going to make the best cross-word puzzle ever with
the password hints and hashes :)

[https://xkcd.com/1286/](https://xkcd.com/1286/)

"Weather vane sword" and "sexy earlobes" indeed.

------
pasbesoin
As a small aside about Adobe security practices, I needed customer support
from them the other year (its own horror story). As part of this, customer
support insisted on setting up an Adobe account, although I'd purchased the
product through a third party vendor and not directly from Adobe (as it turns
out, thank goodness!).

When looking up that account information, I saw the note I made as to the
original password they gave that account that they set up: "123456". I had
changed it away from that; I suspect a significant number of their users might
not have.

Glad that account contained only a name and ZIP code / town.

AND the serial number. If someone consumed a spare slot on the serial number,
I shudder to think of how many hours on the phone with Adobe support it might
take to get that slot freed up.

------
discardorama
Adobe, once again. The gift that keeps on giving. After inflicting Flash on
the Internet for 15 years, now this. Has any other company caused as much
grief on the Internet as Adobe?

~~~
tedunangst
Adobe has only owned Flash for the past 8 years. The first (and I'd say, most
relevant) 9 years of infliction were caused by an independent Macromedia.

------
ssafejava
So, if Adobe engineers eventually realized that they needed to upgrade their
password security, and they had access to the passwords in their DB (they used
3DES, and they had the key) - why did they not immediately decrypt and hash
all passwords?

~~~
jordanthoms
It sounds like they did do that, and this system was the old database which
was no longer in use, but they didn't shut it down.

~~~
acqq
See neya's comment here, who believes his credit card was taken from there amd
he claims to have recently purchase something.

My theory is Adobe didn't use SHA2 even recently, it's probably something that
they only started to develop.

And SHA2 is still wrong, BTW. See other comments here.

------
fleitz
3DES in ECB mode... great job guys. Really really well done.

------
mayneack
Anyone got a link to where one might check for the presence of their own email
in this list?

~~~
dorian-graph
[http://adobe.cynic.al/](http://adobe.cynic.al/)

~~~
sb23
Is it ironic that to check if my email is vulnerable i'm typing it in to a
website that i'm not sure whether to trust?

~~~
neltnerb
My thought exactly... I did not choose to do so =P

------
borplk
Nowadays that everyone has lots of accounts and there are so many good
password managers around I don't know why losing passwords is so important.

I couldn't care less if Adobe stored my password in plaintext. It's unique to
that service and used absolutely nowhere else and I don't even have to
remember it.

------
kevinxucs
What's worse, see [http://xkcd.com/1286/](http://xkcd.com/1286/)

They use a technique similar to ECB, which results in completely linear cipher
text blocks.

~~~
yeukhon
The xkcd references comic 792 and I totally agree that at any given time there
is a website people going to sign up and they will never realize the author of
the website stores everything in plaintext so he could get your username and
password. This is why we need to push identity services like Persona.

------
xxchan
Remind me, what year is this again?

------
mikkelewis
All my passwords are different and this still pisses me off.

~~~
nwh
You're going to be getting a lot of spam in the near future, the list of
emails isn't exactly a secret anymore.

------
nightcracker
"Adobe says that they've followed best practices for password storage and
protection for more than a year now, as their authentication systems were
upgraded to use SHA-256, with salt, to protect customer passwords."

Absolute bullshit! SHA-256 with salt is totally inadequate for password
storage, they should use a PBKDF like scrypt.

~~~
viraptor
Depends on the number of rounds used. It can be brought up to a reasonable
time complexity this way and is definitely not inadequate. Worse than some
alternatives? Sure. But it still gives reasonable protection.

~~~
brohee
If they said SHA-256 with salt, excuse us to think it is just that, with no
iteration. If it's iterated SHA-256 it becomes a lot closer to PBKDF and one
wonder why they would not use it.

Given Adobe history wrt security, let us assume the worst.

~~~
viraptor
That is the standard in the password libraries really. passlib uses thousands
of rounds of sha-256, so does glibc, etc.

Unless they implemented the whole thing from scratch, they wouldn't be using a
single run of sha-256. It's not impossible, but I'd say at this point it's
unlikely they're doing something silly - it would be a job terminating mistake
for whoever implemented the new system after the last fiasco.

------
DavidJohnson
I've heard from several people/companies in InfoSec have copies of the
database and are actively analyzing it. Shouldn't be too hard to find if you
wish to check yourself against the compromised list.

------
piratebroadcast
Someone explain the difference to me like I'm 5 please? (Not trolling btw)

------
jgreen10
Plain hashing and encryption are equally silly, especially without salt. Use
bcrypt.

------
nudetayne
Anytime I register anywhere, I do the following:

1\. Use a new or willing-to-be-spammed email address. 2\. Use a new phrase-
based password.

I write all of this information down on pieces of paper that I keep at my
desk. I have a lot of scribbled up paper at this point.

~~~
bigiain
How long have you been doing that? There's an email address of mine in that
list that is much more likely to have been given to Macromedia back in the
late '90s or very early 2000s - I was working at a different company in '02
and am quite unlikely to have given the older email address out after then…

~~~
nudetayne
Since about 2004 I think? Anything before that, I think it was an AOL email
address. If they can access it, they can have it.

