Dropbox employee’s password reuse led to theft of 60M+ user credentials

https://techcrunch.com/2016/08/30/dropbox-employees-password-reuse-led-to-theft-of-60m-user-credentials/?ncid=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29

by prostoalex • 10 years ago

294 101 10 years ago

techcrunch.com

mkj2• 10 years ago

Are there any decent technical measures to discourage password reuse across sites? Server generates the password?

dewiz• 10 years ago

Perhaps someone could come up with a service saying "sorry, this password has already been used somewhere on Internet, are you sure you want to proceed?". Sites would have to adopt it, a-la re-captcha

eatbitseveryday2• 10 years ago

I ask, can we do away with passwords entirely? Trying to defeat computers with human memory seems like the wrong approach.

0xFFC• 10 years ago

Coming up with appropriate password for ordinary user's is hard enough right now.lets imagine you are not being sarcastic-for the sake of argument-, then I think it is almost impossible to create good enough password, yet rememberable.

blake8086• 10 years ago

I've often wondered if this is possible. I bet there's an academic paper somewhere about zero-knowledge multi-lookups or something.

enobrev• 10 years ago

Lastpass does this. It will warn you when saving a password, and it also warns you when loading data for an already saved password.

dredmorbius2• 10 years ago

This.

I think it's going to have to be legislated:

1. Mandate that all publicly disclosed passwords are collected in a compiled set.

2. Require that any Internet service vendor check against this set on password change revisions, and against different portions of the file, as maintainable, on each authentication.

Known passwords are rejected when set, and mandate changes when detected on login.

Asking a 76 year old mostly-computer-illiterate pereson to come up with a never-been-used-before password simply doesn't work.

This also means mandating password safes on all consumer-grade OSes. Apple already does, Microsoft and Android. For Linux, you might be semi- on your own, though most distros offer several options.

I'd also like to see 2FA via a keyfob generator rather than contact token (e.g., phone, email).

spullara• 10 years ago

I generate them using Apple keychain

tempestn• 10 years ago

Indeed, or any major password manager. I use lastpass, which will automatically generate (and even fill in the appropriate fields) long, random passwords. I'm sure the others have a similar option.

FullMtlAlcoholc• 10 years ago

As a recent convert, I highly recommend using a password manager (Lastpass, Dashlane, 1Password, etc.).

For sites where I don't really care about security (present company included :), I use a passphrase, usually in the form of a mnemonic. As an example, the password I may choose for this site would be "Hack_G1bson_RedPill_KungFooey" Much easier to remember and it only makes sense to me. Also, for apps like Dropbox, you better be using multi-factor authentication.

I can't do this for every site because of their tyrannical password requirements. I wish they used overall password complexity as an entropy threshold instead of 1 lower, 1 upper, etc.

bigiain3• 10 years ago

I've walked away from signup at sites where I'm mildly curious, and when I go to sign up - I have a 25 char random password-safe generated string rejected as a secure password due to stupidly enforced lowest-common-denominator rules. (Or worse still, rejected as "too long").

If Im feeling "community minded" that day, I might email their contact address and tell them why I didn't complete the signup process - if I'm in a stabby mood I'll more likely just lampoon them as morons on Twitter. doubt either action on my part makes any difference.

prawn• 10 years ago

I use the 1Password Teams service, having converted from PasswordSafe, and it's excellent. Easily worth paying for. Syncing, browser integration, etc - saves a lot of pain.

Mahn2• 10 years ago

You should absolutely use a password manager and two factor auth whenever you can, but the problem is what to do as a service provider and/or employer if people won't use either of the things. A lot of people are pretty careless about their digital security and don't care for password managers or 2fa; and then of course they reuse passwords because nobody can be arsed to remember a different password for each service.

You could argue that if someone doesn't care for their digital security that's their problem, but we live in a time when one single careless employee can screw over 60 million people, as it was the case with Dropbox.

witty_username• 10 years ago

For server-side, that'd be OpenID.

Hermel• 10 years ago

Enforcing arbitrary password rules. "Must contain at least two '$' characters", "Cannot contain more than one '?'", etc.

However, I think being able to use the same stupid password on all sites I do not care about is a feature rather than a bug.

therealidiot• 10 years ago

I recently had a fight with password selection on the Azure portal. They have some truly awful password rules, and I've ended up using something that isn't completely terrible but is much worse than normal, because I simply couldn't get it to accept anything decent.

Thinking about it, my account was added by a company using Azure, perhaps they are able to set the password restrictions for their sub-accounts...

bigiain3• 10 years ago

The problem with that is you never know at signup whether this site is going to be "one you don't care about" 2 or 5 years later.

I had a "stupid" multiply re-used password exposed in a breach of PerlMonks (which I didn't really care about in 2007 or so) which I also used when signing up to check out yet another new social media site in 2008. A couple of years later my Twitter account was sending Acai berry spam to my friends...

(And even if new-site-de-jour doesn't turn out to be something you stick with, it's now got your name (or regular handle) with the risk of damaging your reputation when it gets exploited without you even knowing...)

hiram112• 10 years ago

There are plenty of technical solutions to this problem.

None that will not dissuade potential paying customers, though.

mkj2• 10 years ago

Yeah, I was thinking more of dissuading employees.

fizbin4• 10 years ago

Don't store passwords at all if you can avoid it. Then, bend over backwards to avoid it.

Do all login through OAuth or the related proprietary "login with" mechanisms Facebook and Twitter have. Offer your users a choice of mechanism, in the signup flow, and don't require that they first set up a password that they then replace with login-with-(whatever).

If you can't imagine what this looks like, open an incognito browser and go through the signup-for-an-account flow at stackoverflow.com. That should be what you're aiming for.

pilif• 10 years ago

is an evolution of the company’s stance on the 2012 incident

what a nice way to say that they lied before and that they are now finally coming clean - three years too late.

0xmohit2• 10 years ago

three years too late

From 2012 to 2016 -- it'd be four.

0xmohit2• 10 years ago

The report doesn't contain much details, but 2-factor auth might have helped.

What is also not apparent is whether the stolen credentials were utilized to pull off data from the accounts? Users might have had sensitive documents stored!

alanh• 10 years ago

I've been waiting for light to be shed on this incident for a long time, as I have known for years and with zero doubt that invented email addresses used only for Dropbox must have been stolen from Dropbox. I have said so, publicly, too, but I never heard Dropbox admit to a serious incident like this.

an_account• 10 years ago

Dropbox admitted in 2012 that the emails were stolen. The new information coming to light now is that encrypted passwords were also leaked.

Exact phrasing from 2012 blog post:

A stolen password was also used to access an employee Dropbox account containing a project document with user email addresses. We believe this improper access is what led to the spam. We’re sorry about this, and have put additional controls in place to help make sure it doesn’t happen again.

jacquesm• 10 years ago

A stolen password was also used to access an employee Dropbox account containing a project document with user email addresses.

The fact that such a document can even exist is plenty of reason to worry about processes and access at dropbox.

rjbwork• 10 years ago

This is a really good reason to be careful about what you log to log analytics platforms. I just recently implemented an ETL system that has the credentials (along with other stuff about the job) for data access passed into it from a PaaS framework. While I want to log the information, I don't want to log my DB connection strings! It's very easy to overlook such things and produce them as part of application logging/exhaust without realizing it, especially now that we have mass adoption of things like Splunk, Logg.ly, CloudFront, Cortana Analytics, Elmah.IO, LogEntries, Seq, and a dozen others.

rdtsc• 10 years ago

It's very easy to overlook such things and produce them as part of application logging/exhaust without realizing it

Very true. It is a constant battle between debuggability and not leaking credentials.

In Erlang for example, when processes crash they dump their state, their neighbours, links to other processes, and other such useful stuff. That's very helpful, however it means it could dump credentials as well.

Luckily there a custom function to format the state of a process http://erlang.org/doc/man/gen_server.html#Module:format_stat... which helps with that. But have to implement that each process which holds credentials.

Also some of those log ingesting services provide a pre-indexer credentials filtering. I know Splunk has it:

http://docs.splunk.com/Documentation/Splunk/6.4.3/Data/Anony...

Of course it is better if it is filtered out before that. But it could be a safety net perhaps.

mootothemax2• 10 years ago

Very true. It is a constant battle between debuggability and not leaking credentials.

And there are so many ways of getting bitten.

Another anecdote for you:

I recently found out that an API wasn't logging errors anywhere.

Easy enough to fix, plug in a library and bam, everything is nicely logged to the database.

Including the HTTP headers.

Headers that include API auth tokens.

Ouch.

dotancohen• 10 years ago

I'm actually fixing an issue with this right now. My logging framework is capturing user passwords, so I've delayed the release one day while I blacklist certain known-sensitive information from the capture.

mootothemax2• 10 years ago

while I blacklist certain known-sensitive information

Is there any way you can take the opposite approach and whitelist stuff to include?

That way you don't have to worry about stuff sneaking in in the future.

(not that blacklisting has ever bitten me in the behind before, no siree...)

lima• 10 years ago

Also Linux kernel logs. Kernel ASLR requires kernel addresses to be secret, yet dmesg is full of them sometimes and you usually ship those out over unencrypted syslog.

aram• 10 years ago

Completely agree. Here's another example: BitDefender (antivirus) passes your email and MD5 of your password in the hash when you want to go to your dashboard. When I contacted them more than 1 year ago about it, their "senior e-threat analyst" said it's nothing to worry about. Absolutely ridiculous.

What to do when the company is ignorant and continues to use something as stupid as that?

joshka3• 10 years ago

Alternatively use managed service accounts. You shouldn't even know or be able to expose the db connection credentials - let AD manage that for you. This is Windows specific advice and obviously doesn't count if your services don't support this (log a bug in the product if it doesn't).

lawpoop• 10 years ago

For this reason, and others (version control, backups), I think we need to move to key authentication, ring of trust, etc.

skyrw2• 10 years ago

Its [Current Year] and [Semi-Respectable Tech Blog] still doesn't know the difference between encryption and hashing.

knweiss• 10 years ago

Quote: "Dropbox was moving away from using the encryption algorithm SHA-1"

skyrw2• 10 years ago

I know the article explicitly and consistently says 'encryption' everywhere. I simply cannot fathom that they were encrypting instead of hashing. While I suppose it's possible that the SHA-1 versions were encrypted, I refuse to believe that the dropbox security team would transition from that to bcrypt 2-directional encryption over bcrypt 1-directional hashing. With that assumption I find it safe to say the tech journalist is being inaccurate.

Mahn2• 10 years ago

Because Dropbox stores its user passwords encrypted [...]
[...] batch of encrypted passwords [...]
[...] from using the encryption algorithm SHA-1
Some of the stolen passwords were encrypted with SHA-1, while 32 million were encrypted with bcrypt
The passwords were also secured with a salt, a random data string added to strengthen the encryption.
it does not appear that the encryption protecting them has been cracked.

I know it's completely tangential and I'm just nitpicking but damn that does bother me more than it should.

roel_v• 10 years ago

Does it matter in this context? What tangible benefit is there for end-use, those that need education the most, to know the difference?

bo10242• 10 years ago

I think everyone should know what password hashing is. You wouldn't buy a car without airbags.

tdkl• 10 years ago

Because $deity forbid that someone would actually learn something when reading news.

wtbob• 10 years ago

Does it matter in this context?

Yes, yes it matters. Correctness matters. Falsehood is wrong.

toodlebunions• 10 years ago

Oops.

runesoerensen2• 10 years ago

Troy Hunt's analysis: https://www.troyhunt.com/the-dropbox-hack-is-real/

jsmthrowaway• 10 years ago

It was pretty neat to read Troy's line there about sending emails out near the end, raise an eyebrow, tap over to my inbox and hear an immediate and satisfying ding. I highly recommend the HIBP service, hiding your e-mail from showing up in public searches (important for opsec), and donating whatever you can to Troy.

Truly essential service and I'd be happy to pay more. Even with good password discipline it's useful knowledge on your exposure.

raingrove• 10 years ago

~It's pretty shocking that the SHA1-hashed passwords weren't salted.~

Edit: I misread the article. It says the leaked hashes were salted, but the leak didn't include the salts.

runesoerensen2• 10 years ago

Are you referring to "the bcrypt accounts include the salt whilst the SHA1 accounts don't"?

I think he's saying that the leak didn't include the salts.

themihai• 10 years ago

You would think Dropbox doesn't behave like a startup anymore...Proves again that simply passing the responsibilities to a "cloud" provider doesn't fix the security issues.

icebraining• 10 years ago

Well, the leak is from 2012. But unfortunately, startups are hardly unique in mishandling their passwords, there are plenty of large companies on http://plaintextoffenders.com/

At least their passwords were hashed!

matt_wulfeck• 10 years ago

I really wish HIBH would actually send me the data related to my email. I currently have no way of know the current password except by going on to some shady website and downloading a dump. Why not provide the option to send it to the user's email address?

emilburzo• 10 years ago

What's the shady website that has the dump?

I'll go check it for you.

CameronBanga• 10 years ago

Why would this ever be valuable? Never mind it's probably a huge liability risk to Troy, who runs the service for free.

bigiain3• 10 years ago

Ummmm, wat?

You have no way to know the password you set on sites you signed up with, except from pastes of breaches?

I don't think that's a problem Troy needs to fix...

I think he's chosen very smartly to explicitly and publicly _not_ know anything about the passwords, and only store email addresses. If you think 60mil Dropbox passwords sounds like a spectacular fail, imagine the headlines if an attacker got into HIBP and exfiltrated 1.3_billion_ passwords (or password hashes)! It's be the first "Unicorn credential breach" ;-)

Kadin3• 10 years ago

Except all those credentials are public anyway, so it has to be assumed that anyone who wants them, already downloaded them.

Unless HIBP is getting its dumps from nonpublic sources..?

maruhan2• 10 years ago

So how does this work? Did the hacker go "Hey look, i managed to hack Dropbox, here are the data related because I trust you!" Or was it that HIBP managed to find where the data was?

raesene62• 10 years ago

Well in this case all you would have received is a salted hash without the salt, which would be pretty useless.

So that's only useful where cleartexts are breached and there he'd then have the massive headache of securing that data.

The best approach if this is a concern for you would be for you to store a password history of ones that you have used and when you changed them.

nullc• 10 years ago

Title should say that Dropbox's security procedure provided inadequate security when confronted with well known user behavior.

franciscop• 10 years ago

"it does not appear that the encryption protecting them has been cracked"

Please Techcrunch, you are making it sound like you are talking about actual encryption while you are really talking about hashing. From that sentence people would believe that it takes a single "crack" to get them all.

The magic of bcrypt (and hashing in general) is that probably some low-hanging fruits have been picked already while any non-trivial password remains secure.

fizbin4• 10 years ago

And worse, when you actually need to talk about someone screwing up and encrypting passwords (see http://www.xkcd.com/1286/ ), this mis-education of your readers will have to be carefully undone first.

corv• 10 years ago

Glad I deleted my account a while back.

Hopefully all these clouds will pass over and we can get back to personal computing.

akerro2• 10 years ago

I dropped it after reading http://www.drop-dropbox.com/

fastball• 10 years ago

Because you really like conflating politics with software?

oneloop3• 10 years ago

Why not just encrypt everything in Dropbox?

a_imho• 10 years ago

I did too, but I'm not sure if it has any effects other than maybe setting a disabled flag somewhere.

beilabs• 10 years ago

Changed the email on dropbox about 2 years ago; seems like i've been pawned on the old email with the same password.

Incredibly poor response from Dropbox on this issue.

nextstep• 10 years ago

Not at all surprising. Maybe things have improved, but Dropbox's security was a total joke in 2011-2012. Remember "no password day"? https://techcrunch.com/2011/06/20/dropbox-security-bug-made-...

bandrami• 10 years ago

Somebody remind me what's justifying those six-figure tech salaries that are pricing everybody else out of the Bay Area?

jpalomaki• 10 years ago

If two-factor authentication or single sign-on is not an option, should you force at least partly random passwords for employees to prevent password re-use?

In the past this would have been considered as bad practise, since nobody can remember that kind of passwords but nowadays it is pretty clear that everybody (in IT) is either using some password manager or reusing their passwords between systems.

(And to clarify, I'm not talking about end users of service like Dropbox, but people who are working with security sensitive stuff on the backend)

impe83• 10 years ago

ok thats why I just got a dropbox pop up to change my password :P

iagooar• 10 years ago

The email Dropbox sent me was talking about a preventive measure. Did they lie?

koolba• 10 years ago

Some of the stolen passwords were encrypted with SHA-1, while 32 million were encrypted with bcrypt, Motherboard reports. The passwords were also secured with a salt, a random data string added to strengthen the encryption. Even though these passwords have now been dumped online, it does not appear that the encryption protecting them has been cracked.

Whenever I've seen passwords stored without a salt it's either because there is no salt or the salt is derived from the username. If it's the latter, it's only a matter of time till the specifics are figured out.

I'd be very surprised if there is a random salt for each of the SHA-1 passwords that's stored separately from the hashes themselves.

CiPHPerCoder• 10 years ago

SHA1 isn't encryption, it's a hash function.

Dropbox employee’s password reuse led to theft of 60M+ user credentials

Related Stories