Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Dropbox Authentication: Insecure By Design

Soulskill posted about 3 years ago | from the drag-and-drop-and-hey-stop-that dept.

Security 168

An anonymous reader writes "Dropbox can be very useful, but you might be a little surprised to learn that by copying one file from a computer running the application, an attacker can access and download all of your files without any obvious signs of compromise. Normal remediation steps after a compromise such as password rotation, system re-image, etc will not prevent continued access to the compromised Dropbox. Derek Newton, a security researcher that published this finding yesterday, discusses the security implications of this by-design security authentication method on his blog."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Dropbox (-1)

Anonymous Coward | about 3 years ago | (#35761560)

If you currently find these silly cloud services truly useful, then you are doing computers wrong.

Re:Dropbox (5, Insightful)

Hijacked Public (999535) | about 3 years ago | (#35761630)

There is a significant difference between a service I find useful for embedding photos on web forums, or similar things, and one I'd store my plain text tax forms on.

Re:Dropbox (3, Funny)

Anonymous Coward | about 3 years ago | (#35761684)

Agreed! I upload my tax forms to Pastebin and keep my photos securely locked away.

Re:Dropbox (3, Insightful)

Wrath0fb0b (302444) | about 3 years ago | (#35761718)

Replying to undue accidental 'redundant' instead of 'informative'.

Doh. Also poster is right. Different data have different security requirements -- think about that for a while.

Re:Dropbox (1)

grub (11606) | about 3 years ago | (#35761810)

Actually I find Dropbox to be very useful for things like ebooks and technical PDFs.

I can access them from my desktop, iPhone, iPad, wherever.

Re:Dropbox (4, Funny)

lgw (121541) | about 3 years ago | (#35761960)

Actually I find Dropbox to be very useful for things like ebooks and technical PDFs.

I can access them from my desktop, iPhone, iPad, wherever.

And so can I! Thanks for putting those up there, by the way, it doesn't work if everyone leeches.

Re:Dropbox (2)

RobDude (1123541) | about 3 years ago | (#35762464)

I'm a big fan of Dropbox.

Having said that, long before I read this, I realized that anything I put into my Dropbox folder would be visible by *OTHER PEOPLE*. After all, the data is being stored on a server that I don't own. In this day and age, anything that is out of your hands is likely to be stolen, sold or lost by whatever company you are dealing with.

Dropbox is great for storing crap that is either....

1.) Not personal (my collection of .mp3s - I don't care if the world can access them)
2.) Personal, but trivial (pictures of my home renovations....I don't care if the world can access them)
3.) Encrypted

If you want to store your important tax documents or scans of your birth certificate or whatever else; cool. Go for it. But you'd better encrypt the heck out of it.

Re:Dropbox (2)

HikingStick (878216) | about 3 years ago | (#35761828)

Let's face it. Many times, it doesn't matter whether you or I find such sites useful. What matters is whether or not senior executives, marketing partners, or "the guy who signs the checks" finds them useful. The rest of us are just screwed until we can convince management otherwise.

Re:Dropbox (0)

Anonymous Coward | about 3 years ago | (#35762482)

What the fuck are you talking about?

Re:Dropbox (0)

MachDelta (704883) | about 3 years ago | (#35762488)

If you DON'T find cloud services useful... you must have a very nice basement you enjoy spending all of your time in.

Duh? (2, Informative)

zachriggle (884803) | about 3 years ago | (#35761582)

If your local machine is accessed by an untrustworthy party and they get your shared secret/API token/whatever, they can impersonate you. ALSO: Applications store your login information locally when you request that they save your login information!!! News at eleven.

Re:Duh? (0)

Anonymous Coward | about 3 years ago | (#35761692)

No kidding. If someone breaks into your computer and steals your config file, they'll have access to the files on your computer from which they stole the file from! Oh noes!

Re:Duh? (0)

Anonymous Coward | about 3 years ago | (#35761706)

Not having a way to either expire/change/revoke it or notice that something is wrong (as in attacker changed password quicker) would be news - and the summary makes it look like it is the case.

Actually, you do have possibility to revoke compromised host_id.

Re:Duh? (4, Interesting)

meloneg (101248) | about 3 years ago | (#35761712)

But, according to the summary up there, this one survives password changes. That's really the gotcha. It sounds like they are using something similar to the SSH authentication keys. http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&sektion=1 [openbsd.org]

But, they really need to implement a way to reset the key files and force you to restart the authentication cycle.

Re:Duh? (1)

oscartheduck (866357) | about 3 years ago | (#35761848)

I always assumed they were using an S3 backend, in which case it'd be the S3 public/secret key combination that wasn't being updated. There's an API to regenerate the key, but I know dropbox encrypts all of your files. I had always assumed that the simplest way to do that securely would be using the S3 secret key. If that's what they did, then regenerating the keys would become less trivial.

Re:Duh? (5, Informative)

hoggoth (414195) | about 3 years ago | (#35762500)

Then they did it wrong.
Truecrypt encrypts your data with a key. This key is encrypted with ANOTHER key (your password). You can change your password and it will reencrypt the encrypted key, without having to reencrypt all of your data.

Re:Duh? (0)

Anonymous Coward | about 3 years ago | (#35762194)

But, they really need to implement a way to reset the key files and force you to restart the authentication cycle.

If I go to the Dropbox webpage I can see a list of my authorized computers/devices, with the option to unlink individual computers/devices. TFA doesn't mention if unlinking a computer from that page invalidates the copied key or not.

If it doesn't, it is a bug. If it does, it is no worse than the case with SSH authentication keys.

Re:Duh? (0)

Anonymous Coward | about 3 years ago | (#35761714)

I think the author was trying to express that compromising one device allows access to every dropbox folder on every device associated with that account. If I understand the article correctly, this also means that a compromised device can be used to gain access to shared folders from non-compromised devices/accounts.

Re:Duh? (0)

Anonymous Coward | about 3 years ago | (#35761734)

It's called permissions. Run Dropbox as an unprivileged user and only allow it access to a certain files/folders. When you want to send a particular file/folder, give Dropbox permissions to access only that resource, and then remove all access when the action is complete.

Re:Duh? (1)

Carik (205890) | about 3 years ago | (#35761986)

At least few months ago, that wasn't possible, at least with the Windows client. You had to install the client as an admin, and it was immediately installed for every user, with the same login/password combination. No per-user config at all.

That may very well have changed, but that's how it was when I looked at it.

Re:Duh? (2)

OverlordQ (264228) | about 3 years ago | (#35761802)

Did you even RTFS?

Once you're compromised, it's permanent, you cant change your password, you can't reformat, etc. Regardless of what they steal, changing your credentials though available means should lock them out.

Re:Duh? (2)

zachriggle (884803) | about 3 years ago | (#35761922)

If I steal your SSH key, and then you change your password, I can still access your box.

The only difference here is that you're no longer in control of the effective authorized_hosts file, Dropbox is. Yes, they should regenerate the key every time you change your password.

The article's hysteria seems to be much more about the file, rather than the fact that a password change doesn't change your API key / secret key / etc.

Re:Duh? (1)

masterwit (1800118) | about 3 years ago | (#35762574)

They use an SSL protocol I do believe (I do understand SSH uses SSL essentially internals, just no messy certificates).

Your point is still perfectly applicable.

This is why my online data is stored on a low pay-per-month server using SSH (and UNIX commands)... with sub-accounts I use for access. That way I can login as my own pseudo-root top level on a different key on a machine I consider more secure... but my netbook/etc. actively uses the sub account.

In addition having a paper trail (credit card) with my name I get the added advantage of putting my name behind the access to the account so I can be properly identified as the account holder. (I use rsync.net, they have a pretty good service over there...) Encryption of files that are important with a password is always a good idea too... plus archiving saves space and md5 files are a good way to ensure proper transfers.

Long story short a system is only as secure as the user wants it to be and as it is fundamentally designed... If I had a Dropbox acct I would be fine because I knew what I was getting.

Re:Duh? (1)

Richard_at_work (517087) | about 3 years ago | (#35762716)

Unlink the affected computer through the Dropbox website (accounts -> My Computers -> Unlink), relink the affected computer and the token is changed, the "attacker" is locked out.

Re:Duh? (1)

Carnildo (712617) | about 3 years ago | (#35762432)

Did you read the article? What Dropbox does is the equivalent of authenticating using only a username -- with no password, and no way of changing your username. Once your account is compromised, it is compromised forever.

Re:Duh? (0)

Anonymous Coward | about 3 years ago | (#35762602)

Did you read the article? What Dropbox does is the equivalent of authenticating using only a username -- with no password, and no way of changing your username. Once your account is compromised, it is compromised forever.

Wow, hysterical and misleading much? The clear message here is that if your account is already compromised, the data an attacker already has access to can be read from your dropbox backup -- DUH!

Re:Duh? (1)

Richard_at_work (517087) | about 3 years ago | (#35762730)

What Dropbox is doing is saving an authentication credential after initial authentication and reusing it - no different to a website storing a cookie that tells the website you are logged in.

What about Ubuntu One? (3, Interesting)

josgeluk (842109) | about 3 years ago | (#35761584)

Ubuntu One is a similar service, running native on Ubuntu systems. I wonder whether that has the same built-in vulnerability.

Re:What about Ubuntu One? (0)

Anonymous Coward | about 3 years ago | (#35761608)


Drop some more Canonicals why don't ya?

Re:What about Ubuntu One? (0)

Anonymous Coward | about 3 years ago | (#35761908)

Yo dawg, I herd you liek Canonical so I put an Ubuntu in your Ubuntu so you can spin your cueb while you spinnan your cueb!

Re:What about Ubuntu One? (5, Informative)

Dr_Barnowl (709838) | about 3 years ago | (#35761808)

Ubuntu One uses OAuth, which should have a sensible means of expiring tokens.

And seeing the sibling poster - obligatory extra SPAAAAM! Ahem... U1 is currently cheaper than Dropbox, being a buck fifty per GB per year, rather than the 2 bucks per GB that Dropbox charge, and you can get extra storage in smaller increments, so if you need 60GB you'll only need to shell out $90 per year for 3x20GB packs, not $200 for the 100GB account on Dropbox. The downside is that the service isn't quite as good as Dropbox ; their Windows client is less mature than their Linux client, it doesn't AFAICT have LAN syncing, or delta compression. The upside is that you could view it as supporting something important to you, if that has value in your personal catalogue. And it's cheaper for the same volume of storage.

Slashdotted before the comments even started? (0)

Anonymous Coward | about 3 years ago | (#35761586)


Re:Slashdotted before the comments even started? (3, Insightful)

hedwards (940851) | about 3 years ago | (#35761874)

I'm always shocked by how much load is put on a server by people not reading the article.

/.'ed (3, Informative)

just_another_sean (919159) | about 3 years ago | (#35761600)

Site seems to be /.'ed already. Here is another site mirroring the original blog [greyhat-security.com].

Re:/.'ed (-1)

Anonymous Coward | about 3 years ago | (#35761784)

Fucking karma WHORE.

Re:/.'ed (1)

Anonymous Coward | about 3 years ago | (#35761864)

No, troll -- the public service provided is not the evil act you seek to criticize. Nothing wrong with doing a good deed and attaching one's name to it. Please stop the uneducated, shame-based trolling.

Re:/.'ed (4, Informative)

clang_jangle (975789) | about 3 years ago | (#35761820)

FTFA (emphasis in bold added)

Dropbox Insecure by Design
/ by / Mr. P / on / April 08, 2011 @ 4:54 am
http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/ [dereknewton.com]
Security Engineer Derek Newton recently discovered a vulnerability in Dropbox's authentication mechanism, whilst looking for forensic traces left behind by such software. Derek discovered that in one of Dropbox's SQLite Database files, config.db, there are 3 fields contained:


After testing (by modification of existing fields), Derek was able to determine that the only field that affected authentication in any way, was host_id. Any other fields did not affect the way in which the machine was able to communicate or sync files with Dropbox. After some more testing, Derek was able to prove that by taking the config.db, and installing it/copying it to another machine, that he was instantly able to access/sync the existing files of that users' Dropbox. In doing so, he was not once prompted for authentication or credentials, and the user was not notified of any access to their files.

This carries a lot of implications, as stated by Derek, as it allows Malware to quickly and quietly steal access to your files, without you knowing. It also allows malicious users to copy over a very small file in order to steal many larger files later, rather than copying over all the files at the time of theft. Malware would also be able to be persistently installed in the Dropbox files, so that when a user reformats their computer, it is simply synced and run all over again.

A user would need to delete/revoke the affected device ID from their Dropbox after infection to prevent continued access.

Note this requires an attacker to already have access to the config.db, i.e. one must have physical access to the machine and already be logged in as a privileged user or owner of the config.db.

Re:/.'ed (1)

BitZtream (692029) | about 3 years ago | (#35761902)

Note this requires an attacker to already have access to the config.db, i.e. one must have physical access to the machine and already be logged in as a privileged user or owner of the config.db.

Or have network access to the machine and a way to copy config.db off of it.

Unlike say ... using the OS X keychain facility or the Window Protected Storage facilities for storing information in such a way that it requires authentication to get the data out.

As a domain admin, I can pull data from any dropbox account for any user on my network just by grabbing their config.db.

I can't change their network password without them noticing a change, which would prevent me from gaining access to their dropbox config if it was stored securely, but I can steal their dropbox credentials since it is essentially storing the password in plan text, except ... its not even a password that becomes useless if changed, its nothing more than a unique ID that tells dropbox what users to sync with. Its just a unique username that once known can be used at will forever, no authentication required.

Its like using your social security number for authentication.

Re:/.'ed (1)

clang_jangle (975789) | about 3 years ago | (#35762032)

As a domain admin, I can pull data from any dropbox account for any user on my network just by grabbing their config.db.

I understand that, and yes it should be fixed -- but it's a far cry from being as scary as some people are making it sound. I'm glad I use rsync though. :)

Re:/.'ed (1)

njvack (646524) | about 3 years ago | (#35762102)

Note this requires an attacker to already have access to the config.db, i.e. one must have physical access to the machine and already be logged in as a privileged user or owner of the config.db.

You don't need physical access, just the ability to run code as the logged-in user. So any number of browser driveby attacks or emailed trojans should be able to grant an attacker irrevocable access to your dropbox.

If true, this is actually a big deal.

Re:/.'ed (1)

clang_jangle (975789) | about 3 years ago | (#35762216)

My mistake regarding the statement "one must have physical access to the machine". But one must be able to execute code on the machine as the user in question, i.e. the account would have to be already compromised.

Dropbox at work (0)

Anonymous Coward | about 3 years ago | (#35761602)

I guess we won't be using Dropbox at work anymore.

Re:Dropbox at work (1)

SimplyGeek (1969734) | about 3 years ago | (#35761756)

This could be a big problem for me as well. In my startup, we'll continue using Dropbox as it's proven invaluable for a company of 50 spread across US, Canada, China, and Australia. But for companies that are more conservative, and especially for large firms with more to lose, this is a potential deal breaker. The way I mitigate risk for my company is to keep all sensitive documents like legal filings, tax docs, etc off of Dropbox and in another system that's less accessible.

Re:Dropbox at work (-1)

Anonymous Coward | about 3 years ago | (#35762078)

In my startup, we'll continue using Dropbox...

Wow. Solid planning at your "startup". What was the name again? I'd like to avoid any contact with your "startup"...

Re:Dropbox at work (0)

Anonymous Coward | about 3 years ago | (#35762360)

AC, why be a tool? SimplyGeek just needs to stop being cheap and host their own fileserver...and that can of worms.

Re:Dropbox at work (1)

paultwang (946947) | about 3 years ago | (#35762100)

Remedy for company owned computers/laptops:
Run Dropbox on an account that's not accessible by users. You can set it to run at startup via Scheduled Tasks or crontab. For added security, encrypt those db files containing the authentication keys with EFS (Windows only). The Dropbox folder will then be made accessible to authorized users via filesystem permissions. Unfortunately, this won't scale well for multiple Dropboxes per computer.

One should not use Dropbox for sensitive documents anyway, because:
1. Dropbox staff can read file names [dropbox.com]
2. They can obtain the decryption key if they really wanted. (If you can reset your password, they obviously can, too.)

Re:Dropbox at work (0)

Anonymous Coward | about 3 years ago | (#35761814)

Why did you in the first place? I always thought Dropbox was the semi-equivalent to using one of those startup websites to remember your online passwords. i.e., insane.

At least with the inefficiency and snooping of Google Docs or (ugh) SkyDrive you could be reasonably certain that an outside attacker isn't going to gain access. Google moreso.

It's kind of sad that in the age of web services, Google & Amazon seem to be the only companies who truly understand security.

Full Article (site is /.'ed) (1)

Anonymous Coward | about 3 years ago | (#35761730)

--- snip ---

For the past several days I have been focused on understanding the inner workings of several of the popular file synchronization tools with the purpose of finding useful forensics-related artifacts that may be left on a system as a result of using these tools. Given the prevalence of Dropbox, I decided that it would be one of the first synchronization tools that I would analyze, and while working to better understand it I came across some interesting security related findings. The basis for this finding has actually been briefly discussed in a number of forum posts in Dropbox’s official forum (here and here), but it doesn’t quite seem that people understand the significance of the way Dropbox is handling authentication. So, I’m taking a brief break in my forensics-artifacts research, to try to shed some light about what appears to be going on from an authentication standpoint and the significant security implications that the present implementation of Dropbox brings to the table.

To fully understand the security implications, you need to understand how Dropbox works (for those of you that aren’t familiar with what Dropbox is – a brief feature primer can be found on their official website). Dropbox’s primary feature is the ability to sync files across systems and devices that you own, automatically. In order to support this syncing process, a client (the Dropbox client) is installed on a system that you wish to participate in this synchronization. At the end of the installation process the user is prompted to enter their Dropbox credentials (or create a new account) and then the Dropbox folder on your local system syncs up with the Dropbox “cloud.” The client runs constantly looking for new changes locally in your designated Dropbox folder and/or in the cloud and syncs as required; there are versions that support a number of operating systems (Windows, Mac, and Linux) as well as a number of portable devices (iOS, Android, etc). However, given my research is focusing on the use of Dropbox on a Windows system, the information I’ll be providing is Windows specific (but should be applicable on any platform).

Under Windows, Dropbox stores configuration data, file/directory listings, hashes, etc in a number of SQLite database files located in %APPDATA%\Dropbox. We’re going to focus on the primary database relating to the client configuration: config.db. Opening config.db with your favorite SQLite DB tool will show you that there is only one table contained in the database (config) with a number of rows, which the Dropbox client references to get its settings. I’m going to focus on the following rows of interest:
  email: this is the account holder’s email address. Surprisingly, this does not appear to be used as part of the authentication process and can be changed to any value (formatted like an email address) without any ill-effects.
  dropbox_path: defines where the root of Dropbox’s synchronized folder is on the system that the client is running on.
  host_id: assigned to the system after initial authentication is performed, post-install. Does not appear to change over time.

After some testing (modification of data within the config table, etc) it became clear that the Dropbox client uses only the host_id to authenticate. Here’s the problem: the config.db file is completely portable and is *not* tied to the system in any way. This means that if you gain access to a person’s config.db file (or just the host_id), you gain complete access to the person’s Dropbox until such time that the person removes the host from the list of linked devices via the Dropbox web interface. Taking the config.db file, copying it onto another system (you may need to modify the dropbox_path, to a valid path), and then starting the Dropbox client immediately joins that system into the synchronization group without notifying the authorized user, prompting for credentials, or even getting added to the list of linked devices within your Dropbox account (even though the new system has a completely different name) – this appears to be by design. Additionally, the host_id is still valid even after the user changes their Dropbox password (thus a standard remediation step of changing credentials does not resolve this issue).

Of course, if an attacker has access to the config.db file (assuming that it wasn’t sent by the user as part of social engineering attack), the assumption is that the attacker most likely also has access to all of the files stored in your Dropbox, so what’s the big deal? Well, there are a few significant security implications that come to mind:
  Relatively simple targeted malware could be designed with the specific purpose of exfiltrating the Dropbox config.db files to “interested” parties who then could use the host_id to retrieve files, infect files, etc.
  If the attacker/malware is detected in the system post-compromise, normal remediation steps (malware removal, system re-image, credential rotation, etc) will not prevent continued access to the user’s Dropbox. The user would have to remember to purposefully remove the system from the list of authorized devices on the Dropbox website. This means that access could be maintained without continued access/compromise of a system.
  Transmitting the host_id/config.db file is most likely much smaller than exfiltrating all data found within a Dropbox folder and thus most likely not set off any detective alarms. Review/theft/etc of the data contained within the Dropbox could be done at the attackers leisure from an external attacker-owned system.

So, given that Dropbox appears to utilize only the host_id for authentication by design, what can you do to protect yourself and/or your organization?
  1.Don’t use Dropbox and/or allow your users to use Dropbox. This is the obvious remediating step, but is not always practical – I do think that Dropbox can be useful, if you take steps to protect your data
  2.Protect your data: use strong encryption to protect sensitive data stored in your Dropbox and protect your passphrase (do not store your passphrase in your Dropbox or on the same system/device).
  3.Be diligent about removing old systems from your list of authorized systems within Dropbox. Also, monitor the “Last Activity” time listed on the My Computers list within Dropbox. If you see a system checking in that shouldn’t be, unlink it immediately.

Hopefully, Dropbox will recognize the need for additional security and add in protection mechanisms that will make it less trivial to gain long-term unauthorized access to a user’s Dropbox as well as provide better means to mitigate and detect an exposure. Until such time, I’m hoping that this writeup helps brings to light how the authentication method used my Dropbox may not be as secure as previously assumed and that, as always, it is important to take steps to protect your data from compromise.

Re:Full Article (site is /.'ed) (1)

Hatta (162192) | about 3 years ago | (#35761926)

Dropboxâ(TM)s primary feature is the ability to sync files across systems and devices that you own, automatically.

I use rsync for this. It can use SSH as the transport, so it should be as secure as SSH. Why would someone need to involve a third party for such a simple feature?

Re:Full Article (site is /.'ed) (1)

Carik (205890) | about 3 years ago | (#35762068)

Because most users don't have a handy server, or know how to use rsync.

Yeah, yeah, you're a linux user and you don't care. But the average "power user" with a desktop and a laptop doesn't have a spare server in their closet, and isn't running a system that makes rsync easy. They're running Windows, and there isn't an automated system to sync the two computers. They want to just start up whichever computer they're in front of and know their files will be there. That's what Dropbox does.

Re:Full Article (site is /.'ed) (-1, Troll)

clang_jangle (975789) | about 3 years ago | (#35762148)

But the average "power user" with a desktop and a laptop doesn't have a spare server in their closet, and isn't running a system that makes rsync easy.

But you've just described a luser, not a "power user". There's no "power user" who can't use rsync, sorry. Though I know delusions of adequacy are common 'round slashdot these days...

Re:Full Article (site is /.'ed) (-1)

Anonymous Coward | about 3 years ago | (#35762404)

Oh, some luser with mod points got all pissy-poo over the obvious truth being stated. Predictable. Here [aboutmyip.com] you go, you poor, delicate snowflakes.

Re:Full Article (site is /.'ed) (1)

Carik (205890) | about 3 years ago | (#35762874)

No, I've described a power user. People who describe themselves as power users mostly haven't used rsync. They mostly use only their own OS, and it's usually Windows. They know how to change basic system settings, set up network file sharing, and keep a backup on an external drive. They understand that they shouldn't run as an admin for daily use, and use a limited account for most things. They more or less understand what a secure password is, and they set up their computer so that it's more secure than it was when it came from the factory. They use encryption and good passwords on their wireless router. They're a power user, but they're not a sysadmin. They're not hackers, they're not IT professionals, and they're not experts. They're users who know a little more than most.

Referring to them as "lusers" just makes them think you're an idiot, and keeps them from respecting your opinions. Treating them respectfully means they'll accept training from you in how to keep their systems more secure. It's not as much fun as mocking them, but it sure cuts down on the number of compromised machines.

Re:Full Article (site is /.'ed) (0)

Anonymous Coward | about 3 years ago | (#35762892)

Ok, so in other words it's a term windows users apply to themselves for the purpose of ego glorification?

Re:Full Article (site is /.'ed) (1)

Dr_Barnowl (709838) | about 3 years ago | (#35762094)

Because they don't grok / can't be bothered / can't see the value.

Setting up regular SSH / rsync backup is fiddly, and not even easy on Windows. Installing Dropbox is easy on every OS I've tried it on.

Couple that with a full backup history for files (even for every version of a file), syncing between machines across the LAN (faster than uploading files via the web), and a hosted solution for backups that you don't have to administer ; it's a lot more capable than just SSH / rsync. Although obviously not as secure. But let's face it, no-one with both a clue about security, and the need to maintain it, are uploading files to Dropbox. Unless they're using it as DeadDropBox to trade encrypted files with their fellow spooks.

Re:Full Article (site is /.'ed) (0)

npsimons (32752) | about 3 years ago | (#35762174)

I use rsync for this. It can use SSH as the transport, so it should be as secure as SSH. Why would someone need to involve a third party for such a simple feature?

Because they are lazy, ignorant, or just too distracted by teh shiny. A friend of mine (a Mac user) tried to convince me to use dropbox, and was flabbergasted when I told him I already synced my personal files on my phone (N900), laptop (Debian) and web/email server (Debian again) via git. Personally, I use git for the same thing you use rsync for; gives me versioning and pretty damn good merging; uses ssh by default.

Re:Full Article (site is /.'ed) (2)

hoggoth (414195) | about 3 years ago | (#35762812)

Ignore all those other replies that say, basically, "because they are too stupid to use leet things like rsync."

Dropbox offers a few advantages over rsync:
It runs in real time and detects changed files, syncing them instantly without polling the filesystem. (using services like inotify).
It has iPhone and Android clients.
It's easy to install and doesn't carry other requirements like cygwin, and doesn't break in all kinds of odd corner cases like rsync on windows does.
It offers central management of which computers sync which files and folders (well, SugarSync does this much better).
It offers a web based view of your synced files for when you don't have your own computer. (This can be a plus or minus depending on your viewpoint).
It keeps backup copies of your deleted and changed files.

I'm not denigrating rsync here, it is a fantastic program that runs flawlessly and efficiently. It just doesn't get along with Windows very well and not with iPhone or Android at all.
I had set up a great system using Unison (similar to rsync) on multiple machines, running from cron or Scheduled Tasks twice a day so an OpenSolaris system with ZFS that made snapshots of the filesystems twice a day. I dare you to have your grandmother set that up.

Surprised? (1)

Lord Ender (156273) | about 3 years ago | (#35761754)

If you're surprised by this, you're an idiot. Drop box saves your password to a file (obviously: you don't type it every time you boot). Files can be copied. By the rules of logic, then, your password can be copied. Quite simple, and not at all surprising.

Re:Surprised? (2)

Rebelgecko (893016) | about 3 years ago | (#35761804)

For me, the surprising part is that someone can access your dropbox after you've changed your password. I guess I'm an idiot then.

Re:Surprised? (1)

Hatta (162192) | about 3 years ago | (#35762052)

Saving passwords to a file is only a problem if your permissions are fucked up. I can keep my SSH credentials in a file, and no one else can copy it because it's set to mode 700.

Re:Surprised? (1)

HomelessInLaJolla (1026842) | about 3 years ago | (#35762118)

If you're surprised by this then you must be new. Enormous service built from an amalgamation of tools with a history of obscure insecurities on top of transport technologies riddled with obscure insecurities is found to have obscure insecurities. This has been going on since before the registry.

Truecrypt (1)

JerLasVegas (791093) | about 3 years ago | (#35761760)

Truecrypt works really nicely with dropbox, even if an attacker gets your Truecrypt file, they would still need the password to get the files inside of it.

Re:Truecrypt (1)

Binestar (28861) | about 3 years ago | (#35761832)

I prefer individual file encryption for my dropbox files. I use AxCrypt http://www.axantum.com/axcrypt/ [axantum.com] which has right click integration to encrypt files.

Re:Truecrypt (0)

Anonymous Coward | about 3 years ago | (#35762458)

Do you also prefer entering the password every time you open a file, rather than once per session? Not to mention giving away information to an attacker for doing nothing: file names, sizes, and directory structure... I can't imagine how this is more convenient or offers any practical security benefit over Truecrypt. Please enlighten me?

Re:Truecrypt (1)

breakfastpirate (925130) | about 3 years ago | (#35761888)

If the attacker has access to your computer (as is the case in this article), your TrueCrypt keys stored in memory are already hosed. The only way TrueCrypt will help you in this case is if the attacker is accessing the files remotely somehow and has no access to RAM.

Re:Truecrypt (0)

Anonymous Coward | about 3 years ago | (#35762112)

Yes, if you are not concerned enough about security to remember to un-mount your volumes when you are away from the computer, then you should not be using Truecrypt in the first place. The reason putting your sensitive files in a truecrypt volume is a good idea, especially in a cloud storage system, is that it protects your *DATA* from this kind of bone-headed security leak.

Re:Truecrypt (1)

JerLasVegas (791093) | about 3 years ago | (#35762204)

Especially considering dropbox is in the cloud. I have a Truecrypt container in dropbox but i always unmount it when not in use otherwise i can't really open it somewhere else and preserve the integrity.

Re:Truecrypt (0)

Anonymous Coward | about 3 years ago | (#35762130)

If the attacker has access to your computer, why would you care about a dropbox security flaw? All of your information is already hosed.

Re:Truecrypt (0)

Anonymous Coward | about 3 years ago | (#35762314)

No, it's not. That's the whole point of Truecrypt. As long as you didn't do anything stupid like write the password down anywhere, nobody can access your data regardless of what they have access to. You can send out a truecrypt volume with free AOL CDs and nobody will ever have a clue what is inside.

Re:Truecrypt (1)

maxume (22995) | about 3 years ago | (#35762268)

TrueCrypt would help in the event that physical access was gained by stealing the hardware (assuming some exercise of diligence. i.e., the volume was not left open while the hardware was unattended).

Re:Truecrypt (1)

JerLasVegas (791093) | about 3 years ago | (#35762600)

How many home burglars know how to scan the memory contents of the computer for the information necessary to get the password?

Re:Truecrypt (1)

maxume (22995) | about 3 years ago | (#35762690)

Yeah, that's why I use TrueCrypt, so that the information I store in it isn't available if someone steals my computer.

But we are playing imagine what the attacker is able to do, not guess what the likely attacker will do.

Dropbox is, indeed, useful ... (1)

Tigger's Pet (130655) | about 3 years ago | (#35761812)

... but I would never put anything on there that I wouldn't be just as happy nailing to my local telegraph pole for everybody to read. If it's in the 'cloud' then it cannot possibly be considered to be secure as somebody has physical access to the server holding my data. If I really want to put something 'personal' on DropBox, Ubuntu One or whatever, then I encrypt it, archive it with a password, then upload it as something else innocuous-looking.
Anyone who actually believes there's any level of security to something that's 'out there' then they need their head examining.

Store encrypted data in Dropbox (1)

ixe13 (1060554) | about 3 years ago | (#35761824)

I only store encrypted data (TrueCrypt containers) in my Dropbox. I'm glad the extra work proved usefull...

Re:Store encrypted data in Dropbox (0)

Anonymous Coward | about 3 years ago | (#35762110)

Same here. Get my file, I don't really care.

Additional coverage... (0)

Anonymous Coward | about 3 years ago | (#35761852)

Can be found here: http://thenextweb.com/industry/2011/04/08/dropbox-security-hole-could-let-others-access-your-files/

Well, then (1)

gman003 (1693318) | about 3 years ago | (#35761862)

I guess it's a good thing I only used Dropbox to share a bunch of images that were being deleted by other image hosts. I'd been meaning to use it for actual backups (since I don't have any real backup systems), but maybe I shouldn't. Guess I'll have to RTFA to see how bad this is.

shooting in or near nuclear sub today? (-1)

Anonymous Coward | about 3 years ago | (#35761876)

short clip. probably not up with anything that really matters. odd? very short clip.

What's different? (0)

Anonymous Coward | about 3 years ago | (#35761944)

How is this different than any other service which allows you to store your password locally? Whether it's called host_id or username & password realy doesn't matter....

Note that I am all against using proprietary services like Dropbox, but I fail to see how this has any security implications. If your computer is compromised, all your credentials, saved on disk or not, are compromised anyway. Whether the file is called .netrc or .dropbox.sqlite doesn't matter that much.

Re:What's different? (2)

Desler (1608317) | about 3 years ago | (#35761966)

Because when you change your password on other services the attacker won't continue to be able to access your account?

Not what I think of... (2)

esme (17526) | about 3 years ago | (#35761948)

This isn't what I think of when I think of "insecure by design". This term is usually applied to things like DRM, where it would be impossible, or very very difficult, to fix, and would require completely redesigning how the access control system works.

In this case, dropbox writes a sqlite db after authenticating, and then doesn't check to make sure that it's valid later on. So you can alter the db file to access other people's accounts without having to re-authenticate.

It would be trivial for dropbox to update their app to at least check that the sqlite db is internally-consistent, and require re-auth if not. So there is no giant design issue preventing them from fixing this.

Re:Not what I think of... (1)

Anonymous Coward | about 3 years ago | (#35762106)

Any session based system has this same issue. Dropbox just has insanely long lived sessions. Unlike most places, however, they do provide the ability to de-authorize a session. System compromised? De-authorize your computer and re-login. The fact is you don't have to rotate your password to defeat this problem, just log out (de authorize you computer) from time to time. You should do this with any website really.

Dropbox isn't for secure transfers (1)

greymond (539980) | about 3 years ago | (#35761998)

Dropbox is ideal for transferring large amounts of things like photos, pdfs, artwork and in general non-sensitive information that just needs to get from person A to person B without having to rely/setup/use FTP or email.

At my last job we mostly used it to transfer/archive press releases in Word and PDF format as well as some design files so that our other departments (not always in the same building or city) could grab them easily. Nothing with sensitive information was ever stored on it.

The problem... (1)

0x537461746943 (781157) | about 3 years ago | (#35762224)

"Nothing with sensitive information was ever stored on it"... That you know of. Once people start using it in a business environment they (or others that learn about it) are likely to use it for more sensitive files in a crunch. It is inevitable.

Truecrypt (0)

Anonymous Coward | about 3 years ago | (#35762002)

I use dropbox extensively, and I decided up front to assume that any plaintext file may as well be public (particularly since I share the account with my wife). Anything I'm not comfortable being public I keep in a truecrypt volume.

Too bad! (0)

Anonymous Coward | about 3 years ago | (#35762058)

Too bad they're not using SSL encryption like other well made software is *cough*

Short Version of the Article (0)

Minwee (522556) | about 3 years ago | (#35762166)

(Embriefened or the attention span impaired)

"I have spent the last few minutes investigating the inner workings of Dropbox, and it suddenly occurred to me that if someone else gets hold of your usename and password then they could log in and download all of your files.

"And, like, your login information is all stored on your computer 'n' stuff. So this is bad, right?"

Re:Short Version of the Article (0)

Anonymous Coward | about 3 years ago | (#35762516)

Congrats, you get five stars failing to recognise a single one of the author's points, including:

Additionally, the host_id is still valid even after the user changes their Dropbox password (thus a standard remediation step of changing credentials does not resolve this issue).

Yet another reason for Slashdotters to RTFA.

Re:Short Version of the Article (5, Informative)

Carnildo (712617) | about 3 years ago | (#35762520)

That's a gross oversimplification. A better one-line summary is:

"If someone gets access to your Dropbox credentials, they have permanent access to your files, even if you change your password."

That last bit is what the article is about.

Dropbox Support Forum Thread (1)

monk (1958) | about 3 years ago | (#35762210)

If this is true, then the problem described in the article is a design flaw. Changing your credentials should block access by any box which does not have the new credentials.

Here'st he discusson in the Dropbox Support Forum http://forums.dropbox.com/topic.php?id=36146 [dropbox.com]

Re:Dropbox Support Forum Thread (1)

e9th (652576) | about 3 years ago | (#35762586)

Interesting. The one forum response from a Dropbox guy was not very satisfying.

we don't agree with the assertion that there is a security flaw -- dropbox is a perfectly safe place to store sensitive data. the article claims that an attacker would be able to gain access to a user's dropbox account if they are able to get physical access to the user's computer. in reality, at the point an attacker has physical access to a computer, the security battle is already lost. the research claims dropbox is insecure because it is possible to copy authentication information straight from the user's hard drive. this 'flaw' exists with any service that uses cookies for authentication (practically every web service :) cookies are stored on your hard drive and are susceptible to all the same attacks mentioned by the research (i.e. a virus could steal your cookies and gain access to all your web services).

there are measures that can be taken to make it more difficult (though not impossible) to gain access to the authentication cookie which we'll consider in the future. that said, dropbox isn't any less secure than other web service.

Same issue as copied ~/.ssh (1)

neiras (723124) | about 3 years ago | (#35762256)

The Dropbox issue is the same as what would occur if someone stole your .ssh directory full of un-encrypted private keys.

With Dropbox, unlinking the 'machine' from your account will disable the attacker's access. With SSH, revoking access on any servers the comprimised public key had access to would do the same.

Of course, SSH allows you to encrypt your private keys (you'd have to enter a password before using them). Dropbox doesn't want to inconvenience you with password dialogs, so they just rely on obscurity. How's that for a security mindset?

They could have hashed their token with some hardware-specific values and system configuration details so that the client could force a re-keying if it found itself on a different host. Still not a solution to the hole - a hacked client could still get access, but we might not be reading this if they had taken that step.

Really, they can't close this hole without encrypting their local settings and asking users for a password when Dropbox starts up.

Dropbox users: unlink and relink your machines from your Dropbox account regularly until some future version of Dropbox starts asking you for a password on startup. You should really stop using Dropbox for anything private if other people regularly have access to your machine, or you run an OS that is virus bait...

Virus writers: You now have a nice, easy target: Dropbox settings may give you access you to gold! Or a pile of pr0n!

It is amazing to me that these proprietary storage clients don't just use SSH for their authentication and transport. Really, guys, this is a solved problem. Reinventing the wheel gets you nothing but bad press.

That's not "by design" (1)

bradley13 (1118935) | about 3 years ago | (#35762622)

TFA is surprisingly kind. This isn't "insecure by design" - this is a whopping giant security hole that you can drive a truck through, with no justification whatsoever. Surprising, since Dropbox's implementation seems to be otherwise pretty robust and well-implemented.

I certainly hope and trust that they will fix this idiocy in the next release!

Dropbox IPS sig from EmergingThreats (2)

AgentPhunk (571249) | about 3 years ago | (#35762692)

My IPS sensors went berzerk today after I updated my sigs from Emergingthreats.net:

emerging-all.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET POLICY Dropbox.com Offsite File Backup in Use"; flow:established,to_server; uricontent:"/subscribe?host_int="; uricontent:"&ns_map="; uricontent:"&ts="; content:".dropbox.com|0d 0a|"; classtype:policy-violation; sid:2012647; rev:2;)

I was shocked how many users have this installed and running on their systems. Now I just need to convince management why I should change this rule to BLOCK. TFA and the /. comments will sure come in handy.

Kudos to the folks at ET and the community that writes these sigs. Simply amazing.

Re:Dropbox IPS sig from EmergingThreats (3, Insightful)

slyborg (524607) | about 3 years ago | (#35762924)

Maybe you should find out what people are using the DB access for first...at my company, we use it as a working drop for communicating external documents with outside vendors, more convenient than shoveling everything around via email.

My old joke about the ideal network for the network admin is a single computer in a bank vault, unplugged. It's unfortunate that the job basically is all downside in terms of incidents, but ultimately the job should still be to *facilitate* employee access to company data, customers, and each other. Otherwise you are actively impeding the profitability of your company.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account