Dropbox: Security update & new features | Hacker News Reader

Dropbox: Security update & new features

blog.dropbox.com

95 pointsmarklabedz62 comments

I hope Dropbox uses google's authenticator. It supports multiple accounts and won't clutter up my phone.

http://code.google.com/p/google-authenticator/

Their "Such as" example makes it seem they only decided to use 2-factor but haven't chosen an implementation yet.

A password as secure as my phone is not promising; T-Mobible was recently happy to reset my lost PIN by having me give the last four digits of any phone number I'd dialled in the last 23 hours. I don't really think it's as useful two-factor because the token is only as secure as another company's password system. (Aside from the problems that you have to have a Google Account and a smartphone.)

I looked into this recently when Dreamhost launched google-authenticator instead of two-factor auth. Disappointing.

Someone would need to not only have possession of your phone, but your password as well. So for a hacker to work this:

First, get your password. Second, find your location. Third, steal your phone, which for most people, is almost always on their person. Finally, crack whatever security mechanism you have on your phone.

For someone to go through all that trouble ... you must be storing some very valuable info. If that's the case, may I suggest that Dropbox is probably not the right platform? In fact, any internet connected platform is probably not the right answer.

well most "security mechanisms" on phones are a joke.

The point isn't the security mechanism, but for consumer products the point is physical location. Without two factor authentication, a sweat shop in China could hack you (and thousand others) easily. With two-factor authentication they would need physical proximity to you, so they won't even try.

No. First, get password. Second, get phone number. Third, pretext to gain control of the account and forward/copy texts, view them via web interface, or replace the phone.

I agree. Their is no space for another Authenticator. I already use it with Lastpass.

RFC 6238 TOTP: Time-Based One-Time Password Algorithm describes how to implement your own google authenticator if you wish http://tools.ietf.org/html/rfc6238

The one thing I'm missing from this thing is to be able to export the data. Migrating from one device to another is painful as it is..

Edit: I was annoyed so long by this missing feature and - never did something myself. My bad.

If you have the same problem (one device paired with a couple of services, you want to migrate the accounts):

'/data/data/com.google.android.apps.authenticator2/databases' contains the sqlite3 file 'databases', which contains a table 'accounts' with your keys (and counter values, if necessary).

The email they sent was unfortunate. It's from no-reply@dropboxmail.com. I presumed it was a phishing attempt.

Likewise. It's the kind of email I always delete.

Agreed. Excessively unfortunate that they didn't send it from @dropbox.com, as I'd never heard of dropboxmail.com.

Isn't it ridiculously easy to spoof the "from" address anyway?

You should pay a lot more attention to the where the links go than where the email is from.

What about emails that are sent from services like Campaign Monitor and the like? There's almost no way to know where that link's going to end up because of the 'tracking middleman' that they all have setup.

Good, solid response to the intrusion. I'm particularly happy about the two-factor opportunity. I have no problem re-authenticating every 60-90 days with an SMS sent to my phone, and _definitely_ want any new system to be two-factored before having access to my Dropbox.

The only issue is that a lot of programs (mobile apps, especially) seem to interact directly with the Dropbox API, which leaves no possible interface for a secondary authentication. Google gets around this by having app-specific passwords that you can generate and de-authenticate at will; it'll be interesting to see how Dropbox handles it.

Good point, and perhaps the reason they're taking some time to roll it out.

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

I see two ways to read this.

a) An employee happened to have a personal Dropbox account, and it was that personal account that was hacked, in exactly the same manner as the other accounts referenced. The employee probably used a different password on Dropbox's internal systems, and as a result there was no internal breach.

b) An employee account for an internal Dropbox system was hacked, and this internal account allowed the attacker to access the project file. In this scenario, even though Dropbox made no specific comments to this effect, we can assume that the attacker may have obtained access to Dropbox's internal networks, so who knows what they could have made off with.

It makes a huge amount of difference to me which of those two readings actually took place. In scenario (a), this all boils down to users (including one particular employee) using the same password on too many sites. In scenario (b), Dropbox could be hiding a much larger breach.

Why would an employee have work-related data in a personal dropbox account?

Presumably because they dogfood their own product to their employees. I don't actually know if they do that, but I do know a lot of other companies that do. And it makes sense--if your employees don't use your product on a regular basis, then you're in trouble. But apparently keeping company data in a Dropbox account (personal or otherwise) also has potential security implications.

Every time I see a Dropbox update I hope it is:

* Added ability to sync arbitrary directories

And I'm let down. Every single time.

This is why I'm disappointed that end user open source software is in such decline right now. These kinds of "long tail" user needs will never be met by the proprietary software world. Well, this particular one might, but for every need that gets implemented, 10 more obscure needs will spring up behind it.

Dropbox is making fistfuls of money, and, like all proprietary software companies, they need to stay focused to maintain momentum.

Although it might not feel like it to most people, I think we're in still in the dark ages of software. Not quite as dark as the Microsoft era, but dark nonetheless. We just don't have the tools, infrastructure, and culture necessary for open source to really be a viable space for the typical, scattered programmer to spend their time. I'm optimistic that will change, but I'm not sure how long it will take.

https://www.dropbox.com/help/175/en and a symlink?

Yeah, I understand ways to work around it.. it's more of why isn't it a feature? In SugarSync, Carbonite and Moxy I can quite literally do:

right click -> Sync Folder (or some variation thereof)

and it just works.

Because where are you going to put it on the other computers? So far dropbox has decided it's not worth the complication.

What you want is two clicks plus a confirmation popup and/or wizard. Moving a folder and making a shortcut is two drags and one extra click. It's not a big deal.

and it just works.

Symlinks are not synced automatically, only when restarting Dropbox, or pause/resume syncing.

It's a UI issue. Where would an arbitrary directory show up on other devices? How could you tell quickly which files on your device are being shared?

SugarSync handles it just fine: http://d.pr/i/hluY

That looks complicated. Dropbox targets itself at people who just want it to work without having to think about it.

Same here except the feature I am waiting for is a full featured Android client ie sync all files to the local Android device filesystem (with the option to only sync when connected to Wifi).

I really hope they don't make 2fa mandatory. I hate most 2fa systems I've seen (I use Google Authenticator for one gmail account I have, and it makes life even more of a pain than it needs to, even just on Google properties). Having to reauth ~6 devices every month is obnoxious, and I already have a perfectly good password manager with long random per-site passphrases, plus secure storage of my key file and a strong memorized passphrase for it, unlocking sets of passwords only on certain machines. 2fa, particularly a naive version involving SMS or telcos, would make my security worse.

> In some cases, we may require you to change your password. (For example, if it’s commonly used or hasn’t been changed in a long time)

This is ambiguous...by "commonly used" do they mean 1) I'm logging in with my password frequently or 2) my password itself is a commonly used password? I'm assuming (and praying!) they mean the former since the latter would mean they're storing my password in plaintext.

UPDATE: Dropbox doesn't store in plaintext. I was incorrect to assume these were the only two possibilities. Confer child comments.

They wouldn't have to store your password in plaintext to determine that. They could just hash commonly used passwords and compare the hashes to yours.

If the number of salts used in the system is equal to the number of users, this could be expensive.

They will just check your password against a list of 'bad' passwords when you log in. No need to brute force the stored hash.

Obviously that would work, but not if you're using Challenge-response authentication. In general, I don't think people bother with now that when using https.

A little bit of googling makes it seem like auth tokens are not sent it plaintext over HTTPS but are authenticated using challenge response – http://forums.dropbox.com/topic.php?id=47952 The WWW site may differ.

Assuming they use straight up salted sha256, my five year old core2 laptop does at least 10,000 per second, per core. They could check every user for the top 10k passwords for a few hundred bucks of EC2 time.

Why do you assume that?

It wouldn't, necessarily -- I thought about this a little, and there are ways to identify commonly used passwords without storing them in plain text.

They could check passwords on login (before salting/hashing) against a blacklist of 'commonly used passwords'. This is probably the most secure method, as it only implies that users passwords are not on the blacklist, but does not imply plain text storage or unsalted hashes.

If they were not salting their hashes, then they could query their database for hashes that match the hashed version of commonly used passwords. Similar to the blacklist above, but implies that the passwords are stored unsalted, which is sad.

Dropboxer here. We do not store passwords in plaintext, or unsalted. End sentence. :)

How do you store them?

I believe the implication is that they are stored hashed and salted.

There are many different ways to salt and hash, some more secure than others (bcrypt and DES crypt() being two examples with vastly different levels of security).

With regards to security, I'd rather not read into subtext. Hopefully they can provide a definitive answer.

It's quite obvious from context that it's the latter. However, there is zero implication that they are storing passwords in plaintext. There are several ways to implement such a feature.

First, the password could be checked on login when it is sent in plaintext but not stored. Second, they could run an offline dictionary attack against the hashed password database.

Given they state that some accounts were compromised by stolen passwords from "other websites," it would make sense to run some sort of dictionary attack using lists from those sites.

I'm curious who all received this email? Was it sent to the entire user base? If not, what selection criteria did they use?

Everyone I've talked to seems to have received the "reset your password" email. I'm quite curious because I'm certain (up until now) that the password I used for Dropbox was both (a) not commonly used and (b) had been changed recently and (c) not leaked anywhere else (to the best of my knowledge).

I also received the reset email and my password for dropbox was a random string generated by lastpass so I'm fairly confident that it wasn't leaked elsewhere. I wouldn't be alarmed if you got the email.

FWIW, I use Dropbox with multiple accounts and did not receive a "reset your password" email.

I got one

It would be useful info to know what triggered their email.

One of the more glaring security issues with Dropbox, is the way they are handling 3rd party integration.

Giving full access to some random new startup or app is NOT cool. Sure I don't have to, but people also like to try new stuff, and the integration is half the reason for using cloud services in the first place.

In fact this really applies to all 'platform' plays facebook, linkedin etc. Rather request minimum priviledges to inter-operate or authenticate, rather than sweeping authorizations.

I love the art at the top. Go Jon!

When are email addresses going to be considered something that should be protected as well. Obviously you can't one-way hash these, but you can secure them, and definitely not leave them in project documents.

"In some cases, we may require you to change your password. (For example, if it’s commonly used or hasn’t been changed in a long time)"

Commonly used? What do they mean by that? Aren't they supposed not to know my password?

Good question, but perhaps it's shorthand for "your password generates a hash matching that generated by passwords found in various stolen password lists in circulation".

In which case they're not hashing the password properly, they're likely checking the plaintext password as it's sent over HTTPS.

They do not need to transmit plaintext passwords, they merely need to pick when and how to salt each password carefully.

What they can't do is randomly salt each stored password.

This remark may be OT but why use a grey font on a white background?!? This makes the blog very difficult to read. Please don't do that.

What's the best password manager?

I didn't receive a reset password email. Good thing that I don't store important files in it.

Reply on news.ycombinator.com