
Dropbox prompts password resets - borski
https://www.dropbox.com/help/9257?oref=e
======
mintplant
Thanks for posting this. Fortunately I'm not one of the ones affected, but I
took the opportunity to rotate my Dropbox password and audit/prune my
authorized devices.

[https://www.dropbox.com/account/security](https://www.dropbox.com/account/security)

I had a bunch of old devices in that list and removing each one triggered a
full page refresh, which took longer than normal thanks to the JS-driven
single-page design of the dashboard. The removal request itself went over
AJAX, so I guess someone figured it was easier to throw away the page state
every click than to remove an element from the list's DOM. Made the whole
thing much more tedious than it needed to be; a form with a series of
checkboxes and a single "remove" button at the bottom would have done fine.

~~~
hkjgkjy
> so I guess someone figured it was easier to throw away the page state every
> click than to remove an element from the list's DOM.

Yet another reason to love what React and other virtual dom libs give us

~~~
acdha
Can we leave the toolkit evangelism to a different thread? The subject is
behavior which was routinely implemented better in the mid-90s without using
JavaScript at all.

~~~
naspinski
I agree with the first part of your statement, but I am curious how AJAX
behavior was implemented without JavaScript? Are you talking about Java? CGI?
I have no idea.

~~~
acdha
Sorry if that was confusing, I wasn't trying to say AJAX-like behaviour
happened without JavaScript but simply echoing mintplant's concluding
observation that a 1995-style <table> with a bunch of checkboxes and a remove
button would work just as well as the fancier tech stack.

(That said, I'm certainly not saying that JavaScript doesn't allow much richer
UIs, only that as an industry we're often prone to assuming that the cooler
tech automatically implies benefits to users – e.g. ask anyone who's had to
reload a simple form UI because the AJAX logic failed to handle network /
server errors, out of order dispatch, etc. in a non-confusing manner – or
everyone should love your favorite tool without asking whether it has actual
benefits for what they need to do.)

------
gjm11
This page says:

> _we learned about an old set of Dropbox user credentials (email addresses
> plus hashed and salted passwords) that we believe were obtained in 2012. Our
> analysis suggests that the credentials relate to an incident we disclosed
> around that time._

There's a link to a page about that "incident", which says:

> * usernames and passwords recently stolen from other websites were used to
> sign in to a small number of Dropbox accounts.* [...] _A stolen password was
> also used to access an employee Dropbox account containing a project
> document with user email addresses._

This doesn't add up, does it? I mean, their account of the incident in 2012 is
usernames and passwords were stolen from other accounts; this got the
attackers into a Dropbox employee's Dropbox account; that contained "a project
document with user email addresses".

But now they're saying that "email addresses _plus hashed and salted
passwords_ " went astray. It seems to me that there's an important distinction
between losing "a project document with user email addresses" and losing one
with user email addresses _plus password hashes_.

------
ljoshua
> _Our security teams are always watching out for new threats to our users. As
> part of these ongoing efforts, we learned about an old set of Dropbox user
> credentials (email addresses plus hashed and salted passwords) that we
> believe were obtained in 2012. Our analysis suggests that the credentials
> relate to an incident we disclosed around that time._

Sounds reasonable. I wouldn't be surprised if hashing techniques have changed
since then, and this would be another way of upgrading users to the stronger
scheme.

~~~
pixelcort
This line of reasoning always confused me. To upgrade to a stronger scheme,
couldn't a service just rehash the prior hashes subsequently with a stronger
scheme?

So for those users you'd have newScheme(oldScheme(password)). Then you could
do a one-time migration of users with older scheme to increase the security to
the new one.

~~~
Svenskunganka
That's a waste of resources, because each subsequent time a user logs in you
have to hash the password twice with two different hashing schemes to verify
their password.

The normal way of doing this is when the next time the user logs in, you use
the old hashing scheme to check that the passwords match, if they do, you hash
the password with the new hashing scheme and overwrite the old one with the
new one. This is often coupled with invalidating all session tokens to force
all users to login again (in order to speed up the process of migrating active
users to the new hashing scheme).

The problem comes with the users that hasn't logged in for years, they still
have their password hashed with the old scheme, but normally you would
invalidate those hashes. That means getting rid of them completely so if a
data breach would occur, their accounts doesn't have any hashes that could be
attacked (UPDATE users SET password=null WHERE hashing_scheme='old'). From the
users perspective, this would force them to reset (it's actually set now, not
reset) their password via their email.

~~~
bigiain
> (UPDATE users SET password=null WHERE hashing_scheme='old')

Except you did this while the world was on fire, late on a Friday night, after
a few beers, with management screaming down the phone. And you didn't check to
make sure it didn't allow anyone to log into all effected users accounts with
a null/empty password. Oooops...

(Been there, done that, made similarly stupid mistakes...)

~~~
jonlucc
Biologist here; so would the proper approach be

UPDATE users SET password=[generateRandomString] WHERE hashing_scheme='old';

?

~~~
anujanpan
No, same query but you need to make sure your authentication system disallows
logging into accounts with null / empty passwords.

------
mariusc23
I received an email from @dropboxmail.com about this. I figured it was a
phishing attempt... I guess not.

~~~
Spiritus
Why aren't they using dropbox.com instead of the suspicious looking
dropboxmail.com?

~~~
inertial
One reason could be to not let spam reports on dropboxmail.com affect the
primary domain's reputation (which is also used for corporate communication).
If for any reason, the reputation of dropboxmail.com is compromised, they can
move on to dropboxmail-1.com etc.

------
rbritton
> We are prompting a password update purely as a preventive measure. We have
> no indication your account was improperly accessed.

Preventative of what? In case they were compromised and don't know it? I have
zero reason to suspect _my_ own password file has been compromised, so there's
no reason on my side to change it.

~~~
teach
The reason is explained in the linked article:

"We learned about an old set of Dropbox user credentials (email addresses plus
hashed and salted passwords) that we believe were obtained in 2012. Our
analysis suggests that the credentials relate to an incident we disclosed
around that time."

~~~
rmvt
that's a shitty thing to do imo. they first lure their users into a false
sense of security with "This is purely a preventative measure (...)" and only
provide an explanation if you go through the linked article.

they screwed up. yes, it was 4 years ago but they did. they should acknowledge
it in the most simple manner.

------
baby
> Have not changed their password since mid-2012

I changed my password since then, still received the email, mmmm

~~~
tdkl
> I received the email about this, but haven’t been prompted to update my
> password—what should I do?

> If you received the email but were not prompted to update your password,
> then you do not need to do so. This means that you did not meet the
> criteria. We’re prompting the update for users who haven’t changed their
> Dropbox password since mid-2012[1].

[1]
[https://www.dropbox.com/help/9257?oref=e](https://www.dropbox.com/help/9257?oref=e)

------
sambe
This is strange. I thought I'd changed my password in that time, but received
the email. However, I'm not prompted to change my password when I log in. Now
it's unclear to me if they think I should do this manually or not. Anyone else
see this?

~~~
yoplait_
They address this in their faq on the linked page.

~~~
sambe
Ah, right, I took the section above to imply that they only send the e-mail to
the affected users (which would make sense...). It doesn't specifically say
that though.

------
akg_67
Just curious, what happens if someone doesn't visit dropbox.com and login to
the account? Do all devices connected to Dropbox with app lose connectivity?

~~~
jbverschoor
All authentication tokens seem to keep working.

------
chmars
I had received the mail but was not prompted to update my password when I
signed in … should I be worried?

~~~
Dolores12
when in doubt just change your password

