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

[runesoerensen]

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

[jsmthrowaway]

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]

~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.

[rjbwork]

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]

> 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.

[dotancohen]

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.

[joshka]

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).

[lima]

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]

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?

[lawpoop]

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

[skyrw]

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

[Mahn]

> 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]

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

[knweiss]

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

[franciscop]

> "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.

[fizbin]

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.

[nextstep]

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-...

[corv]

Glad I deleted my account a while back.

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

[akerro]

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

[a_imho]

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

[mkj]

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

[FullMtlAlcoholc]

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.

[Hermel]

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.

[dewiz]

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

[fizbin]

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.

[hiram112]

There are plenty of technical solutions to this problem.

None that will not dissuade potential paying customers, though.

[witty_username]

For server-side, that'd be OpenID.

[spullara]

I generate them using Apple keychain

[jpalomaki]

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)

[matt_wulfeck]

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?

[bigiain]

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" ;-)

[CameronBanga]

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

[raesene6]

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.

[koolba]

> 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.

[0xmohit]

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!

[themihai]

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]

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!

[pilif]

>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.

[0xmohit]

> three years too late

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

[beilabs]

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.

[iagooar]

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

[CiPHPerCoder]

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

[bandrami]

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

[impe83]

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