Stolen Adobe Passwords Were Encrypted, Not Hashed

rjmarvin writes "The hits keep coming in the massive Adobe breach. It turns out the millions of passwords stolen in the hack reported last month that compromised over 38 million users and source code of many Adobe products were protected using outdated encryption security instead of the best practice of hashing. Adobe admitted the hack targeted a backup system that had not been updated, leaving the hacked passwords more vulnerable to brute-force cracking."

Comments

Am I imagining it?

[cpicon92]

Why is it that every single time some big entity's password database is breached, it turns out that they're not following best practices for password storage? Maybe I just don't remember the times when it hasn't been this way...

Re:Am I imagining it?

[CastrTroy]

Well, it would matter somewhat, because if they weren't aware of a breach, then some hacker could be using your account without your knowledge. Of course, if you are using best practices for password selection, then at least all your accounts on all the other sites you visit are safe.

Re:Am I imagining it?

[the_B0fh]

Are you blaming the users now? In any normal distribution of users, there will be some with good password policies, and some who don't have good password policies.

However, the company is entrusted with the password, and need to maintain good stewardship of it.

This is not good stewardship no matter how much you are trying to shift the blame to the users.

Re:Am I imagining it?

[khasim]

It wouldn't matter if users just followed best practices for password selection.

In this case, which would be easier?

1. Getting 38 million people to follow best practices?

2. Getting Adobe to follow best practices?

It's a question of scalability.

Re:Am I imagining it?

[AmiMoJo]

Why do they always lie about it as well, even once found out? They say the backup was using an older and less secure system, but if the primary copy was hashed there would be no way to reverse it and then encrypt the original password anyway. Therefore we know that the primary password storage is always encrypted, and just as weak.

Re:Am I imagining it?

[vadim_t]

Hashing doesn't help that much with a database this large.

Simply check the 38 million for "password", "secret", and the username. Guaranteed to have an enormous amount of successful hits that way.

I wouldn't be surprised if a million were trivially breakable in this manner, in just a few minutes if not less. If you can make $1 from each, that's a nice chunk of cash you just got.

Re:Am I imagining it?

[gnasher719]

It wouldn't matter if users just followed best practices for password selection.

It still matters. First, badly chosen passwords are made _obvious_ to hackers; when two or three or a dozen people choose the same password that's a high probability that the password was bad in the first place. And second, losing 30 million passwords makes brute force worthwhile. If you have an algorithm that would crack one password in 30 years on average, it will find passwords in a set of 30 million at a rate of one every minute.

Re:Am I imagining it?

[Anonymous Coward]

Well, there's your problem. Everybody knows Adobe doesn't scale well.

Re:Am I imagining it?

[B1ackDragon]

I'm guessing selection bias - entities with the security knowledge to use proper authentication techniques probably are also better at keeping their internal databases out of malicious hands. (Or, more negatively, the contraposition of that statement.) On a related note, this breach has caused me to update all of my own passwords, and my current pet peeve are entities that have an upper limit to password length within the current range of rainbow-table attacks (and what are the chances those guys are properly salting?)

Re:Am I imagining it?

[SuricouRaven]

Because if Adobe had no way of decrypting the passwords, they wouldn't be able to provide them to the NSA.

Re:Am I imagining it?

[wisnoskij]

Because when a company follows best security practices it does not have its data breached in the first place.

Re: Am I imagining it?

[Omniver]

It wouldn't matter. Strong passwords help prevent dictionary attacks against password hashes. In this case, it appears the passwords were encrypted, not hashed. So instead of cracking the users' passwords, the attacker need only attack the encryption key and they would get all the users' passwords regardless of how strong they were.

Re:Am I imagining it?

[TheNastyInThePasty]

Hashing + Salting = Problem Solved.

Re:Am I imagining it?

[Charliemopps]

Security team says such and such isn't secure.
Management says "Oh no! We have to do something"
Security provides a quote for the upgrade project.
Management asks "Um... what? Really? That's our entire 2013 development budget! What kind of fines are we looking at if there's a breach?"
Security: "Well... None..."
Management "So why is it you're in my office?"

Re:Am I imagining it?

[Pope]

Are you blaming the users now? In any normal distribution of users, there will be some with good password policies, and some who don't have good password policies.

However, the company is entrusted with the password, and need to maintain good stewardship of it.

This is not good stewardship no matter how much you are trying to shift the blame to the users.

People were putting their actual passwords in the "Password Hint" field. I can certainly blame a user for doing that, as well as the developers for allowing it.

Re:Am I imagining it?

[Charliemopps]

I believe what they are saying is that they did upgrade to hashes, but they had an old Dev environment from before the upgrade and that's what they hacked. I'd say that's pretty typical of big IT shops. Bunches of old Dev environments that go back years because people are afraid to erase them "just in case" Most companies have the false impression that the only part of their data that's at risk is the publicly facing stuff. They never think of "What if they get inside?"

Re:Am I imagining it?

[vadim_t]

Nope, not solved. All it means is that the 100000 morons using "password" as the password won't have the same hash. So the attackers won't be able to find out which accounts share the same password and focus on those, and won't be able to use a pre-computed dictionary.

It is however trivial to hash "password" 38 million times for each salt, on modern hardware probably in seconds.

The salting does provide an improvement, but when you have 38 million accounts, breaking even 1% already gives you a huge amount of successes. Salting doesn't do much against checking the list against the 100 best known passwords. 3800 million is a small number for a GPU accelerated password cracker.

Re:Am I imagining it?

[GuldKalle]

Not really. You could still test all users against the top 100 passwords in a reasonable amount of time. After that, test if their mail accounts have the same password.
It won't get you all user passwords, but the low hanging fruit / naive / non-tech-savvy users are probably a better target anyway

Re:Am I imagining it?

[Mirar]

Turns out best _user_ practice is not to get a product that forces you to register an email/password tupel...?

I'm sure Adobe then is more interested in getting customers.

But then again, maybe not.

Re:Am I imagining it?

[davester666]

you had me at "Everybody knows Adobe doesn't"

Re:Am I imagining it?

[ron_ivi]

Simply check the 38 million for "password", "secret", and the username

If I have a password on file at Adobe (and I think I do), it's probably "password". And that's not a bad thing.

My email there is probably some variation of dontSpamMe@spam.la (that was such a wonderful service while it lasted); or some throwaway like adobespam@[my-own-domain].com.

And there's no way I ever gave them a credit card (or real name, etc).

TL/DR: password=password doesn't neccessarily imply insecure

Re:Am I imagining it?

[gstoddart]

Why is it that every single time some big entity's password database is breached, it turns out that they're not following best practices for password storage?

Honest answer? 'Good enough' costs far less than 'really secure', and companies aren't really interested in doing any real security -- just something which looks secure-ish.

Worst case, they'll get a small fine which is less than the cost of making the changes would have been.

There's simply no incentive (because there are no real punishments) for a company to take data security seriously. So they do a half-assed job of it, and leave it there.

You can bet that, at some point, someone said "this is terribly insecure", and got told by management to STFU.

And unless Adobe gets a really stiff penalty for this, nothing at all will change.

Re:Am I imagining it?

[Russ1642]

There shouldn't be a Password Hint field.

Re:Am I imagining it?

[QuasiSteve]

It's funny because bicubic

Re:Am I imagining it?

[Palinchron]

For one thing, for many applications you NEED the plaintext passwords. You can't do cram-md5 authentication without it, for example.

Re:Am I imagining it?

[timeOday]

Because it really doesn't matter much. You will never find one victim of this Adobe hack who would rather have been in a fender bender.

Re:Am I imagining it?

[tepples]

it turns out that they're not following best practices for password storage

Because sometimes, these systems have to interoperate with other systems that don't follow best practices. For example, if system A has to interact with system B on the user's behalf without the user's interaction, system A has to store some sort of token to authenticate to system B.

Re:Am I imagining it?

[Pope]

Not for YOU. But it sure helps decrypt everyone else's password once you can analyze a know good value. Which is exactly what happened with Adobe's database.

Re:Am I imagining it?

[Anonymous Coward]

I think it's fair to put some blame on the users. Sure it's not their fault that this breach occurred, but if they followed best practices this would have no effects on all their other accounts. Instead, I think we all know that the majority of the username/password combinations obtained will work with numerous other sites and services. Don't reuse passwords and it will never matter if a site gets owned like this.
 
People need to realize that any system they can't personally audit is not secure. Do not risk compromising other accounts by trusting the same password to multiple places. If you do, that password is only as secure as the least secure of those sites.

Re:Am I imagining it?

[LordLimecat]

Encrypting a password doesnt have to be an issue, if you use the password hash + username as the key for encrypting the password. There could be reasons to do it that way, and AFAICT it would be functionally identical to hashing with salt-- in either case a weak password would fall to brute-force, in either case you need to crack the passwords one at a time (due to the "salt").

The benefit of doing so is for instance if you wanted to encrypt user data with a key without giving said key to the vendor (adobe): they would use your password as the data encryption key, and encrypt the password itself with the password hash. You never need to transmit your password plaintext, and noone could decrypt your password without knowing it. It also allows you to change your logon password without having to re-encrypt all of your data.

AFAIK what matters isnt "encryption vs hashing", its "are they salting, and are they using per-user keys".

Re:Am I imagining it?

[Algae_94]

Those 38 million people take the heat off me. I don't reuse passwords. A compromise like this will get them my password to an obviously insecure site. That password will not work for anything else. On the other hand they have 38 million other passwords to use. My information will quickly be found to be of little value and they'll move on.

It's like the idea that if a bear starts chasing you and another person. You don't have to outrun the bear, just the other person.

And to be extra paranoid, I have a credit card that allows me to create temporary CC numbers that are only valid at one location for a certain dollar amount. This way Credit Card information can't be reused anywhere else either.

Re:Am I imagining it?

[Algae_94]

You might not know all the best practices then. That strong passphrase should not be used anywhere else. That way it is useless to anyone that cracks it.

Re:Am I imagining it?

[Kongming]

I agree. I could do without "security questions", as well. Some sites allow you to reset your password using just the security questions, which is ridiculously insecure if credulously answered, given how easily available some of the information is. I used to put long strings of garbage as the answers, knowing that I would never lose my password. I can't do that anymore, because a lot of companies seem to have decided that it is a good idea to require answers to the security questions to do relatively routine things like log in from a different IP address. Now it is essentially one more password that I have to keep for each such site, which if you are choosing strong, unique passwords, is pretty much a waste of time.

Re:Am I imagining it?

[Algae_94]

... and my current pet peeve are entities that have an upper limit to password length within the current range of rainbow-table attacks

Do people still use rainbow tables. I was under the impression that they become prohibitively large after a certain length. I've not seen too many sites that don't let you go to at least 10 characters. That should get you out of the realm of rainbow tables.

Re:Am I imagining it?

[blueg3]

There's another major difference, for large password-database leaks. Salted hashes can't be computed for all leaked passwords at the same time, they need to be computed once per salt. That means that cracking the whole password database at once is, computationally, just as hard as cracking each password individually. With unsalted hashes, cracking the whole password database is as hard as cracking a single password. With this password database, that's a difficulty difference of a factor of 30 million, which is pretty substantial.

Re:Am I imagining it?

[garyebickford]

Relax, it's always been this way. IMHO it's because in the real world almost nobody - no company, and no person - follows best practices of today. At best they're running two or three years behind as the information soaks in through the semipermeable membrane of information flow through the folks who actually read up on this stuff daily, through their awareness, through mentions in group and company meetings every three months or so, into the IT management's headspace, into the implementation plan that is always full of more projects than the group has time to implement, and finally (likely when some big news item hits that makes it mandatory) IT accepts the need to upgrade. Then, since there are several dozen or hundreds of servers and each one despite best efforts is slightly different than any others, and they're all running different applications, the upgrades have to be tested on each configuration prior to rollout. So, two or three years.

Migrating systems to new versions imposes not only effort but risk on the company. And it's a rare company that isn't running some service or application that they bought in 1942, that only runs on a particular obsolete brand and version and can't be replaced without a major impact on operations.

At one time an IBM rep told me that the majority of his customers in the small city where I lived were running an OS version that had been EOL'd eight years earlier. This was an "if it ain't broke don't fix it" strategy - why buy new hardware and software if the old one works fine? That was before networking made security updates such a big deal - few systems even had timesharing, much less networking.

Re:Am I imagining it?

[Kongming]

Personally, I would never allow sensitive user data to be used in a Dev environment in the first place. You shouldn't need to, and it creates an additional potential target for attackers.

Re:Am I imagining it?

[Kongming]

While it is true that some security issues are outside of your awareness and control, following best practices makes it less likely for a single point of failure to provide attackers with access to sensitive data.

Re:Am I imagining it?

[Belial6]

And to be extra paranoid, I have a credit card that allows me to create temporary CC numbers that are only valid at one location for a certain dollar amount. This way Credit Card information can't be reused anywhere else either.

I have been surprised that this has not become the norm. What CC company are you using that has this feature?

Re:Am I imagining it?

[mlts]

What I would like is some standardized way for recovering an account, but something decentralized, so one site doesn't hold the keys to everyone's city.

Maybe some option of signing a nonce with one's private key, using a OTP keyfob, or reading a text message, or perhaps a combination of the above might be good.

I've wondered about an "oh shit" recovery key. This would be a USB dongle that only receives power from the USB port, since it would not need a battery. It would be similar to the old SecurID "calculator" keyfobs, except very basic. Hit one button to enter in the device's private key for that site. Hit another button, type the website's challenge on the keypad, type the device's response into the web browser, and the account is re-activated. Maybe even allow for multiples of these.

That way, if someone forgot everything, all they would need is that physical key which never comes online.

Of course, physical security becomes a major issue, but I wonder if that might be a good way to do things for non-tech savvy people, since the concept of a "master key" is understandable... use it when needed, keep it locked up otherwise.

I could be wrong though, and a break-in would not just mean physical stuff taken, but free access to an account. Of course, the recovery device can have a PIN on it, but then what happens if that is forgotten... perhaps an escrow service?

Re:Am I imagining it?

[Darinbob]

I suspect a lot of people setting these sites up don't even know what the best practices are. Or they don't know in the initial deployment and once that's done no force on earth will allow management to toss it out for a redesign.

A company next door to us once had all their user passwords in a plain text file, for 32 million users. The tech people advised the CEO that it needed changing but nothing was done. It was not considered important. So the inevitable leak happened and the business shrunk tremendously, though they did recover somewhat.

Re:Am I imagining it?

[Darinbob]

Solution is to dump cram-md5. There are versions that don't require the plaintext passwords, but even in that case it leaves in place inherent weaknesses.

Re:Am I imagining it?

[Algae_94]

A Bank of America card I have has the feature. I have no relationship with BoA other than the card, and I only have it because they bought out the bank I originally had the card with. The temporary CC # feature is enough for me to keep the card around.

Re:Am I imagining it?

[Darinbob]

I was utterly amazed once when my Mac and Windows password from a few month previously was emailed to me in plain text from a third party site that was handling our company's online training. Just so much of that was ... wrong. Plain text mailing of a password that was once in use and may still be in use is idiotic. Plus the fact that somehow these passwords are in plain text on the corporate network somewhere, probably in the bowels of active directory. Plus that someone in IT decides that it's ok to send off all the current Mac/Windows passwords to a third party. (at least the vital linux servers are too important to be handled by the IT dept)

Re:Am I imagining it?

[TechyImmigrant]

>Hashing + Salting = Problem Solved.
Not against brute force password attacks.
The lack of salt give benefit to the attacker when there are many passwords (which there are in this case). But the attacker can still take the salt and hash output and brute force the password space for any individual entry in the database.

Hashing + Salting + a symmetric secret = Problem Solved.

Re:Am I imagining it?

[HiThere]

Sorry to disagree, but I feel there SHOULD be a password hint field. I also, however, feel that it should be encrypted. And that it shouldn't be allowed to contain the password.

Re:Am I imagining it?

[geekoid]

If you know it contains the password, then that ALSO means it's not being encrypted properly.

Re:Am I imagining it?

[geekoid]

Don't underestimated the bears ability to get pissed at you no mater who else is around.

Re:Am I imagining it?

[tepples]

Plain text mailing of a password that was once in use and may still be in use is idiotic.

I agree that e-mailing a password is poor practice. But how is e-mailing a 10-digit code for a self-service password reset any better? The adversary can intercept that just as easily.

Plus the fact that somehow these passwords are in plain text on the corporate network somewhere

As of Windows 8, the Windows password is used not only for authentication of the user to the computer but also for authentication of the computer to the Microsoft account server for background updates. Therefore, the computer has to store some token for later, either unencrypted or reversibly encrypted with some key.

Re:Am I imagining it?

[Anonymous Coward]

Nothing solves those issues. "Solutions" like PBKDF and family have obsolescence baked into them.

Password salting is the best, last solution. The only step which is provably and functionally more secure is to not use passwords, period.

FWIW, "two-factor" is not the next best solution. You can derive 90% of the benefit of two-factor by using a hardware-based one-factor method. A simple, battery-free HOTP device (like the Yubikey) is infinitely better than passwords, and tremendously easier to implement.

In fact, most companies implementing "two-factor" aren't actually implementing it as it used to be defined, simply because it's too costly. Anything using a cellphone-based system is not "two-factor" as originally understood. A password sent by SMS is not "something you have". Technically, it's something anybody hacked into the SMS routing system has, too.

"Two-factor" has sadly become a buzz-word that's been twisted by sales and marketing pitches. All that matters is that simply moving away from passwords, whatever the system, is usually better.

Re:Am I imagining it?

[lgw]

I have a far better "best practice": I choose a memorable password, and I hold the business responsible if the business gets hacked.

Re:Am I imagining it?

[lgw]

Right, because the hackers would never ever think to create an account with a weak password ahead of time. The blame here falls on the attackers, and on Adobe. None at all on the users.

Re:Am I imagining it?

[TangoMargarine]

over SSL _in clear text

So you're saying its insecure because it's not secure until you secure and send it? Wha...?

Re:Am I imagining it?

[PhunkySchtuff]

This is a huge part of the problem. Just about all security researchers (white or black hat) will have an account with Adobe - even if it's using a throwaway email address. They know what the email address is, they know what their password is, so can begin to mount a known-plaintext attack against the data in the database.

Unless Adobe are using a different encryption key for every password in the database (unlikely as if they were this careful, they'd not encrypt them and instead hash and salt them) then discovering the key for one password will reveal the rest.

Re:Am I imagining it?

[PhunkySchtuff]

Sorry to disagree, but I feel there SHOULD be a password hint field. I also, however, feel that it should be encrypted. And that it shouldn't be allowed to contain the password.

And how should it be decrypted?

Re:Am I imagining it?

[gumpish]

scrypt aims to defeat highly parallel cracking systems.

The scrypt function is specifically designed to hinder such attempts by raising the resource demands of the algorithm. Specifically, the algorithm is designed to use a large amount of memory compared to other password-based KDFs, making the size and the cost of a hardware implementation much more expensive, and therefore limiting the amount of parallelism an attacker can use (for a given amount of financial resources).

As an aside, the people with "password" and "123456" as their passwords clearly weren't taking security seriously and should expect to be the first ones compromised.

Re:Am I imagining it?

[fatphil]

Do you walk across the road as soon as the light shows green, and then hold the car driver responsible if you get hit?

Personally, I think the safest bet is to assume the worst from the other party. Or at least to not expect any more smarts than you're willing to invest yourself.

Re:Am I imagining it?

[lgw]

I have little at risk if anyone but financial institutions gets this stuff wrong. Taking the time to contest a fraudulent CC charge is really the risk. Financial institutions worry me less as they get proper auditing, and I use a separate password for those, but that's about it.

Or at least to not expect any more smarts than you're willing to invest yourself.

That's a terrible life strategy. You can't be an expert in much, and depending on experts in everything else (but holding them accountable if they screw up) is appropriate.

Re:Am I imagining it?

[lgw]

Still, if Adobe actually encrypted all these with AES and a strong key, no one should be able to find the key. However, I suspect the worst of Adobe.

Re:Am I imagining it?

[SQLGuru]

Not true.....otherwise hashing wouldn't work.

Password is hashed. Hint is hashed. If the hashes match, it isn't a valid hint. You can still store the hint in an encrypted (reversible) state, but compare the hash against the password.

Re:Am I imagining it?

[WuphonsReach]

Salting with a random 16+ bit value that is unique per user is still (and will always be) a required step in password storage. Just because it doesn't help you against GPU accelerated attackers does not mean that it still doesn't have value.

It prevents the use of rainbow table attacks and it prevents the case where breaking one password exposes other accounts that were using the same password.

The issue of people picking passwords that exist in the top 100 lists is a whole different issue. Mostly due to password forms not requiring at least a moderate amount of complexity combined with not enforcing a minimum length. These days, if you're not forcing users to pick at least 10 character passwords and allowing entry of up to 100+ then you are doing it wrong. I'd even say you should force them to include at least one letter of the other case plus at least one number and/or symbol. Then check their password against a top-10000 database before allowing it.

The GPU acceleration issue can be tackled by switching to a hash that takes longer to calculate, then bumping up the cycle count by 1000 or 10k. And make sure that your password storage allows you to change that cycle count down the road.

Re:Am I imagining it?

[WuphonsReach]

I agree that e-mailing a password is poor practice. But how is e-mailing a 10-digit code for a self-service password reset any better? The adversary can intercept that just as easily.

The better systems treat that 10-digit code as a time-limited authentication token. So if you don't use it within say 24h, it expires and can't be used to reset the password.

If you send the new password to the user, it gets stored in their email folders and will be available down the road for an attacker to use when they stumble across it.

Re:Am I imagining it?

[Sabriel]

In your scenario, management screwed up when they asked the IT security team for legal advice ("what fines are we looking at"), and IT security screwed up when they didn't respond with some variation of "let's ask the company lawyer".

Re:Am I imagining it?

[zippthorne]

Citibank also has this, but the web interface hasn't worked on my Mac for over a year.

Re:Am I imagining it?

[righteousness]

You're right, the users are to blame for not protecting themselves. Likewise, many rape victims should also shoulder the responsibility for not protecting themselves from sexual predators. They should have protected themselves by not wearing sexy clothing, not going out with strangers and refraining from drinking alcohol.

Re:Am I imagining it?

[TheLink]

Yeah use short passwords for most sites when the account doesn't really matter. Why waste time with long passwords if the sites are going to get hacked anyway and in many cases the plaintext password retrieved? ;)

Re:Am I imagining it?

[sjames]

Live user logins on a dev box?

Re:Am I imagining it?

[the_B0fh]

Google's authenticator seems to work well for this. Of course, now you'd have to trust google.

Re:Am I imagining it?

[LordWabbit2]

Tell me about it.
Did some contract work for a major food retailer a couple years ago, none of their passwords were hashed or even encrypted. Plain text, in the db. Right next to it was their password hint. It's bloody frightening how many people put their password as their hint.

Re:Am I imagining it?

[vidnet]

I believe that users should have some responsibility in not divulging their passwords to third parties, yes.

Users gave away their gmail and facebook credentials to Adobe, without Adobe even requesting them. What kind of stewardship is that from the user?

Do you honestly believe it's fair for both users and services that any breach or malevolent admin in any service the user ever visits will compromise the entirety of the user's online identity on all services?

We should not be allowing and especially not encouraging this. Browser level, two-factor oauth everywhere.

Re:Am I imagining it?

[HiThere]

That's true, but if they want to go out of their way to be insecure, it's not my fault.

Re:Am I imagining it?

[HiThere]

That's really something that depends on the data being protected. If it's nothing important, then just use something easy, that's easy to decode. If it's more important, well, you go all the way up to storing the key in a bank vault, and then you pass the baton to the user, and make decrypting it their problem. In Adobe's case they should have used a secure encryption, with a user specific key, and stored the keys off-line. So that technical support could retrieve them with the permission of their supervisor, on a sign for authorization basis. (I.e., as described, this hint should not have been available to the user on-line.) And the actual password should have been also retrievable, but with greater difficulty. These are users who WILL lose their passwords, and who WILL expect Adobe to "just make it work!", so the passwords *do* need to be retrievable. Or able to be regenerated, which means that you need to have some other means to identify the user.

FWIW, to me this is an argument in favor of FOSS, where such passwords are only needed by those who want to change the source tree, and where there's little financial gain by breaking in. But expecting Adobe to take that viewpoint is ... unreasonable. So you need to manage the requirement responsibly.

Re:Am I imagining it?

[Bengie]

scrypt helps fight against GPUs by using large(adjustable by paramters into hundreds of KB) pseduo-randomly generated arrays of bytes, then pseduo-randomly jumping around the array. This does two things: 1) Higher memory usage 2) Random memory access

GPUs have a lot of memory, but they have very little cache. A modern GPU has about 96KB of cache shared across 100+ execution units, and has been getting worse over time.

It also has adjustable parameters for rounds to increase the number of OPs required, which helps against regular CPUs.

Re:Am I imagining it?

[Meski]

Maybe not following best practices is what makes them low-hanging fruit? The ones that do (follow) aren't getting targeted. So much, anyway.

Re:Am I imagining it?

[shokk]

So the users can have crappy passwords all they want until they’re warned of a breach? Garbage.
That’s like saying its ok to run around in the street until you get hit by a car.
Best practices are there because you should always use them.

For those who registered.

[Anonymous Coward]

Today is a good day to be a pirate.

Obligatory

[stewsters]

http://xkcd.com/1286/

Re:Obligatory

[CaseCrash]

Alright, I'll give you that one.

Updates?

[RalphMichaelDeLeon]

Like me, their "System/Network Admins" must ignore Adobe's requests for "Important Updates"

Encrypting passwords is "outdated?"

[JLennox]

I don't think that was ever considered an acceptable practice...

Re:Encrypting passwords is "outdated?"

[TheCarp]

This is exactly what I was about to post. I started learning Unix systems in the mid 90s, while the web was still new. Back then, whether to use shadow passwords was still a question asked at install time. Not, should passwords be hashed, that was already long since the standard, but should the hashes be protected.

So at least as far as web services go, encryption vs hashing was NEVER the right or state of the art choice at the time.

Re:Encrypting passwords is "outdated?"

[TheCarp]

No we simply were not talking about that. How would that possibly be relevant to discussions of web services which, unless there is some secret history that goes beyond 1992, (are we counting gopher as "the web" now?) then I stand by my statement: So at least as far as web services go, encryption vs hashing was NEVER the right or state of the art choice at the time.

Re:Encrypting passwords is "outdated?"

[LordLimecat]

Whats wrong with encrypting passwords? Are you just objecting to the specific case where no salt (technically nonce) is used and a single encryption key is used for all accounts?

What if they stored it as such--
SHA1(Username) :: AES(password, sha1(password+username))

Id be interested to see why thats fundamentally weaker than hashing; it certainly can be more useful (such as when you want to use the password as a key for other data without ever having to pass it over the wire).

Re:Encrypting passwords is "outdated?"

[marcosdumay]

That's a hasing algorithm, not encryption. The difference is:

Hash -> data -> value, where everything is deterministic
Encryption -> key -> data -> coded_data, where exist decryption -> key -> coded_data -> data

Your algorithm has the first signature, not the second. I don't know if it is secure, it is certainly not fit for passwords, but it is a hash.

Re:Encrypting passwords is "outdated?"

[Agent ME]

Your password encryption method leaks the length of the password.

Re:Encrypting passwords is "outdated?"

[Darinbob]

The thing is, so many of these new people put in charge do not have experience to learn from history. Many of them know nothing about Unix but instead have a certificate in ActiveDirectory. Probably the same people who in school thought that math was too hard and that they'd never need it on the job. So lack of experience, plus lack of education, means that their job is basically pasting together different APIs to create an application.

It's true that this creates lots of job security for people with brains but it also means there is so much insecurity out there that people really should be more paranoid than they are.

Re:Encrypting passwords is "outdated?"

[Rockoon]

The internet was around long before 1992 "the web" and "gopher", and network security was a serious issue then.

Hell, CERT Advisories were started in 1988. These advisories did not predate the internet, instead they were a response to growing security problems on the internet. In the 1980's most universities in the country were hooked up to the internet, and by the 1990's it was becoming a global standard pushing out the main competitors telenet and tymnet.

This CERT advisory is from 1989 and is a patch for the Berkeley passwd.c.

You appear to be an over-confident nub that doesnt even know the history.

Re:Encrypting passwords is "outdated?"

[LordLimecat]

If you use AES-256, your output size will be 32 bytes. As long as your password is shorter than that, you will be fine, and even if not the most the attacker will know is whether your password length is more or less than 32 bytes.

Not much of a leak.

Re:Encrypting passwords is "outdated?"

[LordLimecat]

SHA is hashing, AES is encryption.
If you submit the hashed username, the server can look up what the encrypted password is. If you supply the hashed username + password, the server will be able to decrypt that password.

Re-check what I wrote.

Re:Encrypting passwords is "outdated?"

[marcosdumay]

If you need the password to decrypt the password, you have a hashing algorithm.

It's an interesting idea, and could be adapted to be no less secure than standard hashed passwords, but it will only add any security if either you have a lot of users (as in 2^64 many users), or you don't need to know who your users are.

Re:Encrypting passwords is "outdated?"

[TheCarp]

> The internet was around long before 1992 "the web" and "gopher", and network security was a
> serious issue then.

Duh of course it was, it was based on the older "Series of tubes" technology pioneered by Al Gore.

However, unless I missed it, this break-in happened recently, and through systems serving up web services. As such, I didn't think we needed to review the technological advancements starting from the tubes.

I mean if your house was built 10 years ago, yes knob and tube wiring would be outdated, but, more than that, even 10 years ago it was 70 years out of code. The history of electrical wiring isn't relevant, because the house wasn't built back at some period of history where it was relevant. There is no point in time where both the house existed AND that was the appropriate technology.

Re:Encrypting passwords is "outdated?"

[Rockoon]

uh, what?

Now you appear to be an over-confident nub that knows that he doesnt know the history, but wants to pretend that he does anyways.

Dear Adobe

[Picass0]

Online security (or lack thereof) is one of the reasons it's a bad move to turn your Adobe Creative Suite into a cloud based subscription service.

3DES

[Anonymous Coward]

Adobe used 3DES. I've RTFA, so you don't have to.

Now if you don't know, 3DES is reasonably safe. It is a block cypher. So unless they also stored the key to the data, the password is reasonably safe. Of course, identical passwords with straight 3DES will be encrypted to same result, but I'm certain no one uses the same password for one website as anywhere else, right??

Re:3DES

[noh8rz10]

I call "12345"! Nobody else can use it. it's the password for my luggage, so it's especially convenient for me.

Re:3DES

[queazocotal]

To expand on this - if the key doesn't leak, then Alice's password is 'safe' even if she reuses it on other sites only if nobody else in the Adobe dump has used her password, and that username is identifiable on other dumps of released passwords.

So, if Alice and Bob's passwords are identical, Bob's password has been recovered from elsewhere, you now know what Alice's password is, and password reuse becomes risky.

While poor practice as if the encryption key can be recovered _everyones_ password is now released - for 3DES as I understand it - if a long key has been used, there is no practical attack against it.

So, yes, if you have another list of passwords, you can go and say 'Bob used password 1223 on these two other releases, if he's used 1223 for Adobe - here are all the other people who've used that same password' - but you can't recover passwords not shared by other people who have not had their passwords leaked already.

Massive computation buys you nothing here, unless you can crack the key, which for a long random key is impractical.

In this case, 3DES may have leaked less data that is important.

Re:3DES

[OneAhead]

Close. '123456' tops Adobe password list.
Also, I know this doesn't need a reference, but just for those who like a good nostalgic laugh.

Re:3DES

[noh8rz10]

thanks for the good laugh. it's been a while since i've actually seen the movie. it's available to rent from amazon online for $3. maybe i'll splurge a bit (i mean, "work offsite")

Re:3DES

[kesuki]

when i read http://xkcd.com/1286/ apparently password hints were exposed in the clear. not cool not cool...

Re:3DES

[LordLimecat]

While poor practice as if the encryption key can be recovered _everyones_ password is now released

That ONLY follows if they are using the same key for everyone. That does not have to be the case.

Re:3DES

[queazocotal]

True - I assumed this was implied by the released results of some people saying 'password X has y frequency'.
I am guilty of not checking those results, and had assumed that these were simply using several peoples shared passwords from other dumps, which encrypt to the same result and can be easily picked out as common crypted values.
If this was a per-user password key - a salt in effect - this would not occur.

Re:3DES

[pjt33]

DES is broken without brute force (although it's also brute-forceable). It's more resistant to differential cryptanalysis than if the S-boxes had been random, but differential cryptanalysis is still better than brute force against it, and so is linear cryptanalysis.

Re:3DES

[Darinbob]

I laughed earlier today because people someone asked for a password for a critical system and was told in my earshot "12345" (as a joke, it wasn't the real password). Then one minute later back on my desk I saw this story on the BBC listing "123456" as the most common password on Adobe.

But I also noticed that "654321" came in number 20. I never would have guessed that one.

Re:3DES

[ras]

The entire article is rubbish. It's little more that a viral ad for CSO, at Adobe's expense.

Yes, they used 3DES. 3DES has a number of nice attributes. It's strong, and it's slow. And if the password is kept safe, it's equivalent to a hash - but an unknown one. Being unknown renders it immune to brute force attacks. Being immune to brute force attacks makes it as good as bcrypt, scrypt and PBKDF2, but without the speed penalty those incur.

The one weakness is that password leaking. I gather it hasn't, so far. Which means that the passwords are safer than an alternative they recommend - salted with SHA-2. In fact, if they were salted with a single round of SHA-2 most of the passwords would be brute forced by now.

Which means while Adobe has done a good job of keeping those passwords safe (well aside from the leak), the security advice offered by CSO in the article is just plain wrong. Which makes the /. writeup of the article wrong. It should say "In trying to teach Adobe to suck eggs, CSO proves they know nothing about password security."

Re:3DES

[rduke15]

mod parent up. Indeed, without the keys, this list is useless. I have 2 accounts in this list, and I know the password. That doesn't help me at all in decrypting the other passwords. As far as I know, there is no easy know-plaintext attack on 3DES.

Re:3DES

[fatphil]

> Massive computation buys you nothing here

No computation at all tells you which passwords are <=8 characters and which are >8 characters. So you can immediately know which targets are better dictionary brute force victims. I would guess that 9 character passwords could be rather obvious too, as there are only likely to be 40 or so 2nd blocks (most will be lower case alpha or a digit). So far fewer 10+-character passwords are likely to have identical 2nd blocks, and the 9-character ones should stand out.

It's not passwords, but it's information. As xkcd says, it's the world's biggest crossword puzzle.

Re:3DES

[fatphil]

password hints generally are not cool, unless you have to do some pretty rigorous proof of identity first. Just clicking "help", and getting something which reduces the entropy of the password to a dozen bits means that the password only has a dozen bits of entropy, no matter how long or complex it was.

Password hint: "xkcd"
Bang! Almost certainly, 0 bits of entropy remain to be found.

Re:3DES

[queazocotal]

3DES - however - not DES.
Are there any sensible (physically realisable) attacks that let you go from known plaintext to recover the key, if 3DES and a maximum length key has been used?

Re:3DES

[pjt33]

I should have quoted the part I was replying to:

DES was only broken by exhaustive search.

Re:It's too late

[Anonymous Coward]

And nothing you do or say will change the fact you misspelled "situation".

Et tu, Adobe?

[CCarrot]

Adobe admitted the hack targeted a backup system that had not been updated, leaving the hacked passwords more vulnerable to brute-force cracking.

Apparently even Adobe has trouble keeping up with updates and patches...what's the matter, get tired of the update server's nagging every couple of weeks?

I'm sure there's some irony to be found in this situation somewhere...

Re:Et tu, Adobe?

[Pope]

Eh, it's their own fault for writing their encryption in Flash!

Phishing going on too

[perpenso]

It wouldn't matter if users just followed best practices for password selection.

True, but that is only part of the story. There is also the email address used with Adobe. Users also need to exercise caution with links and attachments.

Last week I started to receive phishing emails on the unique email address that I had used with Adobe.

Re:Phishing going on too

[sl4shd0rk]

Users also need to exercise caution

There will never be a phrase in computing history which has never been more heavily disregarded.

Re:Phishing going on too

[Kongming]

It doesn't help that a lot of sites use policies that make it harder to practice good password habits. Examples:

• Unnecessary limits on password length or allowed characters. These make passwords weaker and serve no purpose that I am aware of. They also make it harder to use consistent conventions between services.
• "Security Questions" that would be easy for others to know if answered honestly.
• "Password Hints". I don't think I even need to explain why these are a bad idea.
• Requiring users to change their passwords regularly. Such rules often result in users picking weak passwords or taping them to their monitor or keyboard, and so in my opinion, reduce rather than increase security.

To be fair...

[hey!]

Storing only hashed, salted passwords has only been common practice since 1970s Unix.

Where are they listed?

[Okian Warrior]

Why is it that every single time some big entity's password database is breached, it turns out that they're not following best practices for password storage? Maybe I just don't remember the times when it hasn't been this way...

I've lost my copy of "The Big Book of Best Practices" and would like to purchase a new copy.

It's not on Amazon or eBay - would you sell me your copy?

(Or alternately, point me to the content for chapter 6: "Best Practices for Security in IT".)

Re:Where are they listed?

[JLennox]

https://www.owasp.org/index.php/Main_Page

encryption instead of hashing

[Skapare]

When was encryption instead of hashing ever best or right practice? Did someone at Adobe just not understand and everyone else at Adobe accepted that?

Very breakable

[shellster_dude]

The passwords are very breakable as they used the same IV's and keys for every password. Thus any two same plain texts have the same cipher text. A little, simple statistical analysis will get you the keystream and allow you to get all the plain text passwords.

Re:Very breakable

[Anonymous Coward]

Please share with us, this, little, simple stistical analysis method.

Re:Very breakable

[TechyImmigrant]

>They used ECB, hence no keystream.

Facepalm.

Re:Very breakable

[squiggleslash]

Well, we know 'e' is the most frequently used letter in the English language, now, what's the most frequent character in the password list...

[Hey, it beats a double-ROT13 joke]

Jobs was right, Adobe is pathetic

[swschrad]

gaping holes in the software for black hats, with all the security of a row of shoeboxes on a busy street for their business secrets. there are no grownups there.

You Mean Using Post It Notes

[theshowmecanuck]

People who use "best practices for passwords" have passwords that are so brutally hard to remember for a human being that they end up having to 'save' it on a Post-It note stuck to the side of their monitor or "hidden" under a pile of papers that others can look at. Or relegate the 'remembering' of their passwords to another piece of software like a system wallet/keychain, which is just offloading responsibility to another system that itself is an unknown quantity with respect to being well written. But even if a user uses a wallet/keychain, that doesn't remove the Post-It note vector if they need to use the password on more than one piece of hardware. It or a text file on a thumb drive are the common ways to transfer these kinds of passwords between devices.

The reality of how the average person uses a computer often does not reflect the theories that many so called computer security experts have. That is because the latter forget that they are not in the center of the human standard normal curve. Most people don't think like programmers or so called security experts. Better to make the system secure than rely on people to follow so called password best practices. If it isn't easy for the average user, they won't use it.

Re:You Mean Using Post It Notes

[Anonymous Coward]

Correct Horse Battery Staple

That wasn't so hard.

http://xkcd.com/936/

Re:You Mean Using Post It Notes

[oobayly]

I have a single password (8 mixed case alphanumeric characters) that I use as the base password. I then use a very simple algorithm (if you can call it that) that adds [certain] letters from the website's domain to the beginning and end of the base password. That way I have a different password for every site, but only have to remember a single password.

I've suggested it to quite a few people, and most of those people say they now use a method like that. Of course, it always comes with a warning not to use something like "password" as your base password - UK reg numbers aren't bad.

I also use KeePass for saving our company's passwords (as well as a printed copy in the safe), but that's more in case I get run over by a bus.

Re:You Mean Using Post It Notes

[tinkerton]

nice.

Re:You Mean Using Post It Notes

[theshowmecanuck]

I say again:

The reality of how the average person uses a computer often does not reflect the theories that many so called computer security experts have. That is because the latter forget that they are not in the center of the human standard normal curve. Most people don't think like programmers or so called security experts. Better to make the system secure than rely on people to follow so called password best practices. If it isn't easy for the average user, they won't use it.

And they will never use words like algorithm. They won't even think that way. So the average user won't do that. Period. Full stop. Better to make the security of the system being used secure and count less on the users.

I have tricks to try and make decent passwords too, but normal users will not do that. People need to stop trying to make them and instead make idiot proof programs... as much as is possible.

Re:You Mean Using Post It Notes

[defcon-11]

So what if it's written down? No one in close proximity to my computer is trying to hack me. I'm not scared of my family or co-workers getting my credentials. I'm afraid of a remote attacker compromising the server where the credentials are stored.

Re:You Mean Using Post It Notes

[oobayly]

They won't even think that way. So the average user won't do that. Period. Full stop.

Well, in my experience, *normal* users do use them (nurses, managers and sales staff included), because if it's explained to them in a sensible manner then they will understand it. I don't use the word algorithm with them, I just used it here as I *hoped* that the average /. user had a clue.

I suppose it comes down to the ability to explain what you want users to do. As my thermodynamics tutor once said - "if you can't explain it, you don't understand it". Sorry, but your inability to teach password security to *normal* users is a reflection upon yourself, not the user.

Re:You Mean Using Post It Notes

[Anonymous Coward]

I used to do a manual unique password generating technique also. But this has multiple problems:

1. You can't change your password at a given site (e.g. if their password database is hacked).
2. Your algorithm is reduced to a "lowest common denominator" level of strength, since (e.g.) many sites don't allow "special characters", only letters and digits, and have arbitrary restrictions on how long a password can be.
3. If someone discovers more than one of your passwords, they will probably easily deduce your manual algorithm.

It means it USED to be "encrypted", a year ago

[raymorris]

According to Adobe, until a year ago, they were doing it wrong, using the wrong encryption in the wrong way.
The bad guys got a year-old backup, so it was encrypted using the old (wrong) method.

Since the old backup is done wrong, that tells us only that the primary USED TO be done wrong, which is exactly what Adobe is saying. It tells us nothing about the current database.

Bad passwords on purpose

[GlobalEcho]

I haven't checked, but I assume my own Adobe account was part of this leak. And I don't care.

Along with a large portion of the increasingly savvy population, I have more than one "level" of password in use. My account used the lowest of these, basically something like adobe_123. Learning that is not going to help anyone form useful heuristics on how I create my banking passwords -- it might even poison them.

On the whole, I believe the breach will probably help crackers (if decryption can be achieved). But, I think it is foolish to automatically assume that accounts with "weak" passwords are contributors to the problem. As with me, they might be poor indicators of how humans choose more important passwords.

Re:Bad passwords on purpose

[Shados]

There's still unfortunately so many people that reuse passwords. Every new MMORPG that comes out now has a huge wave of "hacked" account where the attacker simply used any one of the big password databases that came from these other leaks, and reaps it. The mass, every time, thinks its the game that got hacked. "Omg i have a super strong password....", yet they reuse it, so its irrelevant.

I used to do it the same way you do, with different levels of passwords. I eventually lost track and just started using KeyPass and generate unique passwords. Unfortunately you can't expect most people to do that, so...

90%+ do it wrong - plain text or 3DES from 1972

[raymorris]

Of the 12,000 or so sites I've seen, well over 90% do it wrong. I'd estimate 95%. Many store passwords in plain text.
Most use 3DES, which was reasonably secure in 1972. Today, 3DES is cracked in milliseconds.
Sometimes we see an unsalted hash, including MD5.

A few have used MySQL's PASSWORD() and the phpass gimmick scheme which are reasonably secure but non-portable.

I consider "doing it right" to be a salted hash. For new software, bcrypt / blowfish or a SHA primitive.
Preferably, SHA-256 or SHA-512 via crypt($5$salt$, password) for portability and consistency.
For existing code, I consider SALTED MD5 to be acceptable, but the length of the input should certainly be validated.

 

Not at all safe in this instance

[raymorris]

XKCD showed why it's not at all safe in this instance. Here's the table:

email cryptw hint
ac@slash.com 737462 first apostle
dumb@adobe.com 737462 hot neighbor

From the encrypted password, we see that these two users have the same password. Now look at the password hints. What do you suppose is the password they BOTH used?

Re:Not at all safe in this instance

[Mr. Freeman]

Yep. It's not so much brute forcing as it is a crossword puzzle.

Re:Strange advice

[VortexCortex]

SHA-2 is a family of hashes including SHA-256, SHA-512, etc. you dolt. Additionally: Keystretching is fine, so is key stretching and recording the resultant hashes into a chunk of RAM, then hashing that and continuing the process for your keystretching to make it memory hard. SHA-2 can be every bit as effective as any other option you'd go for. You're clearly an ignorant fuck.

Re:90%+ do it wrong - plain text or 3DES from 1972

[spacefight]

I use bcrypt - but then again you can pretty much f*ck it up using a work cost which isn't reasonable these days...

Wouldnt they hash the username and password?

[Marrow]

Or even the username, customer number, and password? I mean you want as much in the stew as possible right? Then add a little salt to taste.

Re:Strange advice

[Qzukk]

SHA-2 includes both SHA-256 and SHA-512. Password hash algorithms generally use repeated iterations to slow brute force attacks. For instance, crypt modular hashes use $5$rounds=....$ and $6$rounds=...$ as the prefix for these hashes (respectively) to indicate which type and the number of iterations.

As far as I know, they're currently fairly solid for the purpose of hashing passwords, but CPU/GPU power marches on.

Re:Strange advice

[LordLimecat]

SHA-2, aka SHA256 or SHA512.
http://en.wikipedia.org/wiki/SHA-2

The more you know....

I meant DES, default for crypt(), htpasswd

[raymorris]

Thank you for the correction.

I meant DES, not 3DES. Most use crypt(random), htpasswd, or compatible.

* Not to be confused with crypt($5$salt$), which is secure SHA-256.

Hashing is not better than encryption!

[L-One-L-One]

In practice hashing is often much less secure than encryption for passwords. The devil is in the details.

Here it seems that Adobe made some poor design choices in the encryption algorithm. Yet, despite these flaws, assuming the encryption key is not compromised they might still be better off with their encryption rather than a poor hash mechanism such as the one used for example by Sony and revealed in the playstation hack by anonymous.

In general if the encryption key is not compromised, then encryption provides much more security than pure hashing, or even hashing with a salt. The reason for that is that with encryption, the security of the password depends on the strength of the secret key. With hashing, the security depends of the strength of the password. This is a significant difference. So, if your password is 4 characters long, even the best hash algorithm will fail to protect from a brute force attack. However, if that same password is encrypted, you need to brute force the key which would take centuries assuming the key is long enough.

To be more precise:
1) Pure hashing (applying SHA1 alone for example) is almost the same as having no security at all.
2) Hashing with a salt is a bit better but still won't resist long given computational power offered by GPUs and cloud computing.
3) An iterated hash function with a salt is much better (see PKDF2), and buys you some security but still vulnerable from brute force attacks using GPUs and pooled cloud resources.
4) A "sequential memory-hard" hash function (with salt and iteration) such as "scrypt" is pretty safe today.

Unfortunately in reality most companies use either (1) or (2)...

The drawback of encryption is that you need to make sure that your key is safe. Once the key is compromised you're toast. This means that you should not put the key on the same system that is hosting the password database (it may sound evident, but I've seen it done). It requires putting the key in a HSM (Hardware Security Module) or in a distinct ultra secure server, distinct from the password database.

Of course, if you have the possibility to keep a key secure, the best option is to use a *keyed* hash function (an iterated salted version of HMAC for example), getting the benefits of both worlds...

Re:Hashing is not better than encryption!

[WuphonsReach]

In general if the encryption key is not compromised, then encryption provides much more security than pure hashing, or even hashing with a salt.

Horseshit.

If all of your passwords are encrypted with a single key, a single leak of that key exposes all 38 million accounts. You can wish upon a star all you want that the key won't be compromised, but if it is (all keys leak) you are utterly and totally screwed.

With one-way hashes and per-user salts, there is no single weakness that exposes all 38 million accounts. The attacker has to do at least some grunt-work against each account in order to crack a single user's password. If you enforce even modest password length, complexity and check against known passwords on your users, you've just driven up the attacker's costs by a few orders of magnitude.

Re:Hashing is not better than encryption!

[fatphil]

>> if the encryption key is not compromised, then [... not X]

>Horseshit.

>If all of your passwords are encrypted with a single key, a single leak of that key [... lots of X]

You don't understand logic, do you?

Your first argument is basically homomorphic to the following:

A: If it doesn't rain then I won't get wet at all.
B: Horseshit. Where you live, when it rains you get drenched

There's probably a formal name for this logical fallacy, but I can't be arsed to look it up, and it's certainly accurate to just call it good old fashioned bollocks logic.

It's pretty sad when

[Anonymous Coward]

even xkcd beats Slashdot to a story.

1Password

[ilsaloving]

I won't even bother railing about how completely incompetent Adobe is. Especially since they are not unique in this problem.

My solution was to use 1password. Encrypted password store that also generates login credentials for me. It has tools for Windows, Mac, iOS and Android (sorry, no linux), and it has plugins for all the major web browsers. Stores everything in AES256, syncs with dropbox so you can sync your database with multiple machines.

Now I can effortlessly create a long fugly password for every website I come across, so hashed passwords are essentially unbreakable and for situations like this, at least the password can't be used to compromise something else.

Not a perfect solution, especially given the concerns about NSA, but still very good.

Unfortunately I think those 1.9 million people that have 123456 as their password are going to learn this lesson the hard way.

Problem could be requirements

[YoungManKlaus]

because knowing that hashing would be more secure does not help you shit if management decides that they have the requirement to giving telephone support and being able to read passwords back to certain vip customers ...

Re:"I have no clue, but I wanna diss Adobe too!"

[Agent ME]

Right. Any other block cipher, including AES, could have been mis-used in this same way. (The issues were that they encrypted passwords instead of hashing them, and that they used their cipher in ECB mode. The 3DES part smells of legacy but isn't a real issue in its own.)

KeePass

[GlobalEcho]

I used to do it the same way you do, with different levels of passwords. I eventually lost track and just started using KeyPass and generate unique passwords.

I think you mean KeePass and I quite agree.

Every new MMORPG that comes out now has a huge wave of "hacked" account

It would be interesting to know which "level" people tend to choose for their MMORPGs (at least of those who have "levels"). On the one hand it's just a game, while on the other it involves a gargantuan investment of time and attention.

Re:90%+ do it wrong - plain text or 3DES from 1972

[Darinbob]

The problem is that the company has to now that there is an important security issue to be solved, and then hire someone that understands the issues. If they just head to the software team and say "make sure passwords are safe" then the twenty-something who's put on the job won't know what to do or how to do it.

Encryption *IS* better than hashing

[WaffleMonster]

I couldn't disagree more with this so called "best practice".

Hashes can be brute forced as a function of strength of users password (universally very poor) and size of password pool (2.9m..hiccup). The situation gets worse and only goes downhill as technology improves. Selecting the latest and greatest hashing algorithm does nothing to change this basic truth. Nor does amplifying weak passwords by a multiplication factor of redundant rounds do anything much useful to fix a problem in which only exponents provide actual security.

Encrypted passwords on the other hand are useless to an attacker unless they possess the decryption key. On a well designed system storage is completely separate from decryption key and as such breaches have no consequence.

Further this industry is universally doing it wrong while knowing better. Accepting passwords in the clear over SSL as virtually everyone does is **NOT** acceptable or secure. The phishers love each and every one of us for not insisting on real security. Doing it the right way requires either server side decryption of the password or possession of the hashed version as proof of knowledge in which case the hashed version of the password is fundamentally no different than the plaintext.

When we are storing things resembling SRP verifiers on the server protected by encryption keys and entering passwords into special browser provided fields rather than ad-hoc fields on web forms them come back to me.. Until then OWASP and everyone else parroting back this "best practice" without thinking are making things worse for everyone.

If you want to be amused by people with no understanding of the proper use of hash algorithms in a security standard check out PCI DSS 3.4 "One-way hashes based on strong cryptography"

Lets do the math here. When you strip away the first >6 digits representing a few hundred issuers and subtract the check digit it leaves a search space in billions to trillions making it trivial for anyone to reverse regardless of hash algorithm. Being a "secure" hash algorithm does nothing to protect you from insane misuse of said algorithm.

Re:Encryption *IS* better than hashing

[WaffleMonster]

You could do both: Hash and encrypt.

No, I explained why when I talked about establishing proof of password knowledge.

Entering your password into a site which falsely claims to be twitter or facebook or google or whatever should NOT result in compromise of your password. It should instead result in detection of a scam (e.g. failure to connect to site)

Entering passwords into plaintext web forms on SSL sites obviously does NOT accomplish this.

Being trained to entering passwords only into browser based login dialogue which mutually authenticates using appropriate zero knowledge proof does.

All mutual authentication requires guarding of source of trust. You can hash a password and store the hash but this only shifts the burden from protecting the password to protecting the hash. If the hash is compromised trust is also compromised (e.g. "passing the hash"). There is fundamentally no way around it other than to maintain the current ridiculous status quot.

Re:Encryption *IS* better than hashing

[scdeimos]

If you only use hashing then, yes, you are open to Rainbow Table attacks because common passwords can be immediately exposed.

But hashing is not salted hashing. Best practice uses salted hashing with a unique salt for each user, thus making Rainbow Table attacks useless - you have to generate a whole new set of Rainbow Tables for each known salt which is a whole lot more work for an attacker.

Re:Encryption *IS* better than hashing

[WaffleMonster]

If you only use hashing then, yes, you are open to Rainbow Table attacks because common passwords can be immediately exposed.

But hashing is not salted hashing. Best practice uses salted hashing with a unique salt for each user, thus making Rainbow Table attacks useless - you have to generate a whole new set of Rainbow Tables for each known salt which is a whole lot more work for an attacker.

Who cares if you use a salt or not? If entropy of the underlying password is shit as most passwords are the password will still be compromised. When you are working with a space of 2.9 million passwords there are plenty of easy pickings to make your botnet army's computer time well worth the trouble.

Cost of compromise goes down as technology advances while human capacity/willingness to manage large passwords remains constant.

Re:Encryption *IS* better than hashing

[WuphonsReach]

Encrypted passwords on the other hand are useless to an attacker unless they possess the decryption key. On a well designed system storage is completely separate from decryption key and as such breaches have no consequence.

So now all the attacker has to do is steal your password list, plus that single encryption key and they've just saved themselves week/months of work of brute-forcing and dictionary attacks against the list.

One key to rule them all and in the darkness bind them.

Re:Encryption *IS* better than hashing

[WaffleMonster]

So now all the attacker has to do is steal your password list, plus that single encryption key and they've just saved themselves week/months of work of brute-forcing and dictionary attacks against the list.

Unless you are willing to properly weigh risks throughout the threat tree this all an attacker has to do game is not worth playing. Everyone is always one hop away from an "all an attacker has to do" disaster scenario regardless of what they do.

All an attacker has to do is compromise system generating user accounts or accepting password changes and they can collect millions of plaintexts at their leisure.

Nobody said anything about a "single encryption key" ... that was something you made up. Proper key management includes mitigation of risk.

very few programers trained in security, hire secu

[raymorris]

Indeed very few programmers are trained in security. Probably a minority have any security training to speak of and darn few are trained to design a security system. Yet, most companies don't hire a security professional, or even bring one in for a consultation. Security is my field. When another division was designing a single-sign-on system, they had me spend an hour with them to avoid the top 10 most common problems. Before bringing me in, they had already planned falling prey to at least two of those "obvious" problems. An hour with a security professional can make all the difference.

When I see something like this I have to wonder...

[Jmac217]

Have we just witnessed the fall of Adobe? If not how can they hope to regain users' trust?

Year old backup

[the eric conspiracy]

Not really that bad if...

you change your passwords occasionally.

you don't reuse passwords.

I mean at least 0.01 % of users do that, right?

Re:NOT correct

[HiThere]

Microsoft.

Kim Komando is not a "computer security expert"

[raymorris]

I'm almost offended by your post. Almost, but you did say "so called experts" in one sentence. The linked XKCD comic is right on the money, and experts know that.

Computer geeks and code monkeys are not computer security experts. Security experts know what what entropy is and know that password entropy comes primarily from length.

    "Computer geeks" ala Kim Komando (and many people on Slashdot) go around telling people to use strange mixed case, numbers, punctuation, etc. Code monkeys design login systems that require at least one upper case letter, one lower case, some numbers, some punctuation - and it has to be 6 - 8 characters.

Computer security experts know that 6 -8 characters guarantees weakness, and punctuation increases tech support calls far more than in increases security. (Such requirements often actually DECREASE security by making resets so routine). Experts have known for a long time that the thing to drill into people's heads is "Use LONG passwords! Make it a sentence or phrase. Make it LONG".

The one problem is that a TON of web applications have been authored by coders with almost zero security training. They make an effort to do it right. The encrypt passwords using crypt(). Crypt defaults to a 1972 algorithm that throws away everything but the first eight characters. That thoroughly screws up security.

Re:Kim Komando is not a "computer security expert"

[theshowmecanuck]

and punctuation increases tech support calls far more than in increases security.

This is exactly the use case I was thinking about when writing my post. And the need to design using a salted hash instead of encryption. I am not a security expert, but I do try to keep current and learn from them for use in projects... and for anything critical hire experts to do audits before releasing to the public. And put more of the onus on the system than the user. And... I do use longer passwords, more than 10 or 12 characters, but the problem is that when they are too long, and you have to constantly enter passwords wherever you go, they are a pain in the ass, and people won't make them long. On the other hand, one of my banks won't let you make a password over 8 characters long. Yikes.

torrent magnet link

[rduke15]

Here is the essential part missing from the summary:

magnet:?xt=urn:btih:441582b9204dad5a26199aa51c7746d641f95b21&dn=users.tar.gz&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Ftracker.ccc.de%3A80&tr=udp%3A%2F%2Fopen.demonii.com%3A1337

The file is called users.atr.gz, and is 4 GB.

As already shown by http://xkcd.com/1286/ , this looks like a fun project for a lonely rainy week-end...

Re:torrent magnet link

[rduke15]

the filename is users.tar.gz of course, not users.atr.gz

Re:When I see something like this I have to wonder

[Shados]

If Sony can, anyone can...

Re:When I see something like this I have to wonder

[TechyImmigrant]

If you're stuck with Photoshop, Illustrator, Dreamweaver and all the rest, trust doesn't come into it. Adobe has a lot of lock in on graphical file formats and tools.

Re:Strange advice

[readacc]

You might be knowledgeable in various geeky areas but you don't have to be a dick about it. You're exhibiting various autistic characteristic which I share, but I on the other hand know the value in treating others with measured respect.

Re:90%+ do it wrong - plain text or 3DES from 1972

[russotto]

Most use 3DES, which was reasonably secure in 1972. Today, 3DES is cracked in milliseconds

Rather a large number of milliseconds. Brute force against plain old DES still takes a while especially without specialized hardware. Also, 3DES doesn't go back nearly as far as 1972. (nor does DES for that matter)

FIPS 46 in 1977, IBM before that. I crack, try it

[raymorris]

It sounds like you saw my correction. I typed 3DES when I meant DES, so I'll reply to your comments DES.

> DES doesn't go back nearly as far as 1972. (nor does DES for that matter)

Below is the official NIST paper describing DES. You'll note that after a four year approval process, DES officially became a government standard in 1977. As described in the paper, IBM was using it by 1974 after it was developed in the years prior.

http://nvl.nist.gov/pub/nistpubs/sp958-lide/250-253.pdf

You could reasonably choose any year between 1972-1977 as the beginning of DES usage, so you're mistaken about "not nearly as far back as 1972, sorry.

> rather a large number of milliseconds

Try cracking a password database sometime. I do this stuff for a living. The larger the database, the faster you'll get working passwords, so we'll give you the benefit of the doubt and use a fairly small database of only 1,000 accounts as an example. We'll also be generous to you and not use a rainbow table. With a small (difficult) database like that, you can expect to get maybe 12 passwords in the first second or two. In the first ten minutes, probably 250 working accounts.

A 100X larger database will yield roughly 100X as many passwords per time - around 1,000 working accounts in the first few seconds, or 2-3ms per account at first.

If we want to go fast, we use a rainbow table. Standard DES password hashing ala crypt() collides at about 1:1000 since it uses only the first eight characters. On modern PCs with GBs of RAM, we can use in-memory tables and crack millions per second. No need for that, though, I don't mind waiting several milliseconds.

Re:Strange advice

[GODISNOWHERE]

Recently, cryptanalysts have found collisions on the MD4, MD5, and SHA– 0 algorithms; moreover, a method for finding SHA–1 collisions with less than the expected amount of work has been published, although at this time SHA– 1 collisions have not yet been demonstrated. Although there is no specific reason to believe that a practical attack on any of the SHA–2 family of hash functions is imminent, a successful collision attack on an algorithm in the SHA–2 family could have catastrophic effects for digital signatures. NIST has decided that it is prudent to develop a new hash algorithm to augment and revise FIPS 180–2. The new hash algorithm will be referred to as ‘‘SHA–3’’

This was published in 2007. My joke was about the general uneasiness in the community about SHA-2, even if it hasn't been broken yet. Unfortunately, it seems that the members of \. who responded to me were too thick to understand this. You could have just pointed out that SHA-2 hasn't been broken yet. Instead you evinced your lack of ability to make clever insults.

...you dolt...You're clearly an ignorant fuck.

If you use the word "dolt" in conversation in a non-facetious manner it means that you're either a horribly self-conscious member of the middle class who is afraid of appearing "unprofessional", or a dummkopf who hasn't learned that using "dolt" is a shibboleth of immaturity. If you're going to call someone a motherfucker, as any other confident fellow with an iota of social intelligence would, please do it at the outset. Your prose will have a more even tone and you won't be downmodded for flaimbaiting.

Re:Strange advice

[GODISNOWHERE]

Thanks, but I know what SHA-2 is. I also know that there was so much concern that SHA-2 would be broken that SHA-3 was created. My joke was that the NSA might have broken SHA-2 (they haven't) and that's why they were encouraging us to use it.