
Dropbox employee’s password reuse led to theft of 60M+ user credentials - prostoalex
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
======
runesoerensen
Troy Hunt's analysis: [https://www.troyhunt.com/the-dropbox-hack-is-
real/](https://www.troyhunt.com/the-dropbox-hack-is-real/)

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

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

------
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...](http://erlang.org/doc/man/gen_server.html#Module:format_status-2)
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...](http://docs.splunk.com/Documentation/Splunk/6.4.3/Data/Anonymizedata)

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

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

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

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

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

~~~
oneloop
You wouldn't have an e-mail account without authentication.

You WOULD have an e-mail account without knowing how password hashing works.
You WOULD buy a car without knowing how airbag works.

If you think you know everything about every aspect of everything you interact
with, you're so clueless you don't even realise.

~~~
pop8row9
This reply seems a little unhinged in comparison to the preceding comment.

~~~
oneloop
The preceding comment suggested that using a website without understanding
authentication is like buying a car that has no airbags. That's unhinged. You
know those "IQ tests" where they go "the foot is to the leg like the hand is
to the..." type analogies? This person would fail hard.

------
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/](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-...](https://techcrunch.com/2011/06/20/dropbox-security-bug-made-
passwords-optional-for-four-hours/)

------
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/](http://www.drop-
dropbox.com/)

~~~
fastball
Because you really like conflating politics with software?

~~~
akerro
Software is more tightly coupled with politics than you think.

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

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

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

~~~
rangibaby
SSH keys all day. They can be troublesome for even an "expert" to look after,
so I guess there's no hope for your average idiot. Still, logging in without
using a password is the bomb

~~~
varjag
Keys are great until you find a sudden need to log in from your wife's
cellphone or a public terminal..

~~~
joshka
opsec 101 - don't use other people's devices / machines

~~~
varjag
Do you never, ever, use devices not in your full possession?

~~~
pop8row9
Isn't that what you do?

If you have deals with many strangers do you not expect to get your hands
dirty in some way?

~~~
varjag
I definitely don't store my SSH keys on stranger computers. I however used
passwords on my relatives or customers devices on numerous occasions. Don't
pretend you never did, I'm not going to believe you.

~~~
joshka
Sure, I've used other machines in the past. I prefer not to though in most
circumstances and assume that any account / password that I use on said
machine is compromised from then on.

This was something I changed when I realized that a tax related government
agency's machine I was using about 10 years ago man in the middled SSL
connections to my online banking. Who knows what was logged and what the
retention on that was? I don't have time or the inclination to ensure every
relative's / customer's devices are secure, so I use my own or go without.

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

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

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

------
toodlebunions
Oops.

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

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

