Archive for: July, 2012

Marco Arment on Dropbox: Don’t use it for anything valuable

If you haven’t heard of Marco Arment–creator of Instapaper, co-founder of Tumblr, and
Internet-famous software developer–go follow him on Twitter…now.

Not only is Marco an amazingly successful entrepreneur, but his blog ( and weekly podcast (Build and Analyze) are consistently packed with unique and thoughtful insights on technology and, on occasion, coffee.

Build and AnalyzeOn episode 85 of Build and Analyze, Marco responds to a listener question about the (in)security of Dropbox.  In a nutshell, the listener asked whether Marco felt comfortable storing his data in Dropbox given that they hold the encryption keys.

Marco’s response echoes my personal feelings about Dropbox and other public cloud services – treat Dropbox as though it’s nearly public. Marco’s rule of thumb is that he doesn’t put anything in Dropbox that could potentially be harmful or embarrassing if it were leaked.

Arment says:

“Anything that is really sensitive or extremely valuable or needs to be kept very secret, I wouldn’t store on anybody else’s servers. That, to me, seems ridiculous unless I held the encryption keys like with the online backup service that I use.”

Marco makes some salient points worth repeating here for users who may not be fully aware of how services like Dropbox typically work and the ramifications of storing your data off-premise.

In case you didn’t realize, Dropbox holds the keys to encrypt and decrypt your data on their servers.

This means that a Dropbox employee could theoretically view (or steal) your data. Why do they hold the keys?  Dropbox isn’t just online backup, it’s a collaboration tool.  In order to offer public file sharing features, they have to be able to decrypt data that is stored on their servers.

They also need to be able to decrypt data for legal reasons – if they get a DMCA takedown notice or a subpoena from the US government requesting certain files, servers, or even racks of servers [1].  And because Dropbox hosts data for 25,000,000+ users, some of which are undoubtedly doing very bad things, the likelihood of being served with a subpoena is far greater for them than for an individual person or organization.

For similar reasons, public cloud services are more likely to be hit by hackers because they are high value targets and, by definition, accessible over the Internet.  Also worth noting – you don’t get to decide who Dropbox hires and which employees have access to encryption keys.

Marco and co-host Dan Benjamin briefly discussed Dropbox’s most recent (at the time) security snafu which allowed anyone to login to any account without a password. Coincidentally, a little more than a week after the show aired, Dropbox is involved in another security investigation.

Marco concludes by saying that there are ways to use public cloud services responsibly, but you can’t use them for everything.

I’m with Marco on this.  Any time I store something in the cloud–be it Dropbox or Twitter or Facebook–I ask myself, “How would I feel if this data were on the front page of the New York Times tomorrow?”

Listen to episode 85 of Build and Analyze to hear Marco talk about this topic in detail (it starts around 57:36). He also has a really interesting viewpoint on how leaked source code usually has no meaningful consequences.

[1] Marco experienced this first-hand with Instapaper when his hosting provider DigitalOne was raided by the FBI and one of his servers was confiscated:

The Difference Between Everyone and Authenticated Users

access controls

In order to maintain proper access controls, it’s crucial to understand what every entity on an access control list (ACL) represents, including the implicit identities that are built into a Windows environment.

There are a lot of built-in accounts with obscure names and vague descriptions, so it can be confusing. One question I often get is: “What is the difference between the Everyone group and Authenticated Users?”

The Bottom Line

Authenticated Users encompasses all users who have logged in with a username and password.

Everyone encompasses all users who have logged in with a password as well as built-in, non-password protected accounts such as Guest and LOCAL_SERVICE.

A Bit More Detail

If the above descriptions were a tad oversimplified for you, here is some more detail.

The Authenticated Users group includes all users whose identities were authenticated when they logged on. This includes local user accounts as well as all domain user accounts from trusted domains.

The Everyone group includes all members of the Authenticated Users group as well as the built-in Guest account, and several other built-in security accounts like SERVICE, LOCAL_SERVICE, NETWORK_SERVICE, and others.

A Guest account is a built-in account on a Windows system that is disabled by default. If enabled, it allows anyone to login without a password.

Contrary to popular belief, anyone who is logged in anonymously—that is, they did not authenticate—will NOT be included in the Everyone group. This used to be the case, but was changed as of Windows 2003 and Windows XP (SP2).

Who Has Access To What?

When it comes to permissions, one critical question we need to be able to answer is: which humans have access to a particular resource?

Most of the time when you’re inspecting permissions on a given resource in Windows you’re not dealing with humans (this is actually a best practice); rather, you’re dealing with groups, some of which are built-in implicit identities with ambiguous names. As a result, we often have to do quite a bit of digging to get what we need.

With Varonis DatAdvantage, you’re only ever one click away from seeing which humans have access to a given resource. So when your CEO says, “Who has access to ‘Trade Secrets.doc’?” you can respond with a meaningful, actionable answer instead of going on a scavenger hunt.

What’s the Difference Between…

Looking for more helpful differentiators? We’ve written several!