Dropbox prompts password resets
dropbox.com
dropbox.com
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.
Yet another reason to love what React and other virtual dom libs give us
(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.)
> 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.
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.
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.
if date < '2016-01-01'
return newly_hashed == new_hash(old_hash($password))If a DB has an old hash, call it V1 obtained as H1(password), one can apply a newer hashing scheme H2(V1) and save V2. To avoid having two classes of users forever one can always apply H2(H1(password)) for new users.
It appears though, that this is not what dropbox did, when they changed the scheme to H2 in 2012, applying H2(password) for new users instead.
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.
The first time such a user logs in, you can upgrade their hash to the latest scheme, so there's no extra work on later logins. Django, e.g., does just this, automatically.
https://docs.djangoproject.com/en/1.10/topics/auth/passwords...
I'm familiar with Django, and they happen to have some nice docs on both parts of the process: bulk upgrade to stronger scheme by wrapping [1] and individual upgrade on login [2]. But the technique isn't unique to Django.
[1]: https://docs.djangoproject.com/en/1.10/topics/auth/passwords... [2]: https://docs.djangoproject.com/en/1.10/topics/auth/passwords...
I'm curious about using two different algorithms for hashing at the same time would affect entropy. It could be that the original plain-text password has better entropy than the SHA1 hash (if that was your old hashing scheme) of the original password has.
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...)
UPDATE users SET password=[generateRandomString] WHERE hashing_scheme='old';
?
This will make it impossible for those users to login. Also, if you are luck it won't take the rest of the service down with them, making it impossible for the other users to login too.
But if you're trying to proactively strengthen your password hashes to make them more resistant in case of a future breach, this lets you do that with no inconvenience to your users.
I'm constantly switching between three OS, two browsers, different, sometimes auto-resetting computers, and it seems to be too much of a hassle.
How do I handle this? The only obvious option is a paper notebook.
I'd rather be on an Open Source password manager, but I've found the sync is always too painful to do yourself.
I find it also nicer than LastPass as it combines with the native password saving of FF/Chrome rather than the highjacking and restyling of input boxes that look like user/passwords done by LastPass.
[1]: https://github.com/pfn/passifox
[2]: https://chrome.google.com/webstore/detail/chromeipass/ompiailgknfdndiefoaoiligalphfdae/related?hl=en-USIt's probably fine so long as both your 'client' and 'server' are on localhost, but it'll probably never be secure if the server is exposed to the internet.
I use 1Password with the encrypted vault synced to Dropbox and it works wonderfully well. 1Password has native apps / browser extensions for all of those platforms (except Linux local app where they support and recommend using Wine).
Doesn't help if $attacker has a list of breached oldScheme(password) hashes, and can crack useful numbers of passwords from you old weak oldScheme hash. They can still log into migrated accounts if they can reverse oldScheme into the characters of password.
If you're preemptively upgrading your password hashing aglo with the assumption that you have not (yet) been breached, that works (if your assumption is good). Once the oldScheme hashes are out there though, it's too late.
Next, I went to dropboxmail.com in my web browser, which redirected me to a page on dropbox.com [0] assuring me that dropboxmail.com was owned by dropbox.com.
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.
Or they have an issue they don't want to talk about and this is one way to get it resolved...
That's normally how you'd do a hashing upgrade
* decide an upgrade window
* each time a user logs in check their hash version, upgrade if necessary
* the upgrade period expires
* if you can, force log out all non-upgraded users - hoping they'll now log in and get auto-upgraded
* email all non-upgraded users and ask them to update their password
Hopefully that set of users is now very small.
"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."
they screwed up. yes, it was 4 years ago but they did. they should acknowledge it in the most simple manner.
I changed my password since then, still received the email, mmmm
> 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].