Security quotes of the week [LWN.net]

This announcement means that Dropbox never had any mechanism to prevent employees from accessing your files, and it means that Dropbox never had the crypto smarts to ensure the privacy of your files and never had the smarts to only decrypt the files for you. It turns out, they keep their keys on their servers, and anyone with clearance at Dropbox or anyone that manages to hack into their servers would be able to get access to your files.

-- Miguel de Icaza

Apple has made it possible for almost anybody — a jealous spouse, a private detective — with access to your phone or computer to get detailed information about where you've been.

-- Pete Warden in the Guardian (via Boing Boing)

Honest Achmed's uncles may invite some of their friends to issue certificates as well, in particular their cousins Refik and Abdi or "RA" as they're known. Honest Achmed's uncles assure us that their RA can be trusted, apart from that one time when they lent them the keys to the car, but that was a one-off that won't happen again. [...] Honest Achmed promises to studiously verify that payment from anyone requesting a certificate clears before issuing it (except for his uncles, who are good for credit). Achmed guarantees that no certificate will be issued without payment having been received, as per the old latin proverb "nil certificati sine lucre".

-- "Honest Achmed" requests addition to Mozilla's root certificate store

Honest Achmed is at least more honest than Comodo.

-- Kyle Hamilton

to post comments

Security quotes of the week

Posted Apr 21, 2011 3:48 UTC (Thu) by felixfix (subscriber, #242) [Link] (5 responses)

I don't quite understand the hubbub over Dropbox's "lack of security". It was obvious right from the start that if they can redistribute the file you uploaded, they must either store it in plaintext or both encrypt and decrypt it. It's as if these alarmists expected that the encryption and decryption would be independent of dropbox so it would be unreadable while it was on their servers.

Security quotes of the week

Posted Apr 21, 2011 7:33 UTC (Thu) by jku (subscriber, #42379) [Link]

As Miguel has said quite a few times already, the problem isn't the security measures they take (whatever they are), but the way these security measures are advertized.

People who understand computer security basics all know that when they say "Dropbox employees aren't able to access user files" they really mean "Many Dropbox employees aren't able to access user files and the rest have promised not to do it". Should we not call Dropbox out for that, just because "people should know better"?

Security quotes of the week

Posted Apr 22, 2011 3:02 UTC (Fri) by raven667 (subscriber, #5198) [Link] (3 responses)

Encryption and decryption can be done on the client side which would make them the storer of opaque blobs only. They could store and replicate the data fine under that model but you'd need to separately transfer the keys should you wish to read the files on another host. They could mediate that by transferring the keys through their servers or facilitating peer-to-peer connections. They could also just potentially request the keys be uploaded if dropbox requires a vendor-supplied client software.

There could be some authentication system between data storage and I/O but without technical details and independent auditing it would be hard to know how much of a barrier that provides given that they would have access to both the keys and the data in that circumstance and are only fireawalling between themselves.

Security quotes of the week

Posted Apr 24, 2011 0:04 UTC (Sun) by ringerc (subscriber, #3071) [Link] (2 responses)

Client-side crypto is how Firefox Browser Sync does it, and I agree that it's the only genuinely secure way to do such things.

Unfortunately, there are some real downsides to that approach from a user perspective:

- The user needs to remember a crypto key passphrase or carry the key its self, in addition to knowing their credentials for the service. They need to understand the difference between the key passphrase and the service password and realize that they shouldn't be the same.

- The user needs to understand that losing the key is a non-recoverable error. Their data is gone. Full stop, no recovery. People aren't good at this kind of personal responsibility (any more) and while I think it should be encouraged, experience as a sysadmin says most people expect someone to save them when they screw up and don't deal well when you can't. There's no "forgot password" link here, folks.

- The service can't de-duplicate stored data, so one file stored by multiple users is stored only once on the backend.

- The service cannot do intelligent merging. Compare Google Chrome's sync, which is continuous and which merges changes from multiple browser instances cleanly, to Firefox Sync. Firefox sync runs at browser exit or manually, and has a much harder time doing any kind of state merging because the server cannot see what's in the synced data.

Security quotes of the week

Posted Apr 24, 2011 19:42 UTC (Sun) by khc (guest, #45209) [Link]

> - The service can't de-duplicate stored data, so one file stored by
> multiple users is stored only once on the backend.

I'd imagine that media files is the bulk of what users are storing, and those aren't very de-duplicable. Browser sync data is probably so small that plain old compression is just as effective.

Security quotes of the week

Posted Apr 26, 2011 16:52 UTC (Tue) by njs (subscriber, #40338) [Link]

> - The service cannot do intelligent merging. Compare Google Chrome's sync, which is continuous and which merges changes from multiple browser instances cleanly, to Firefox Sync. Firefox sync runs at browser exit or manually, and has a much harder time doing any kind of state merging because the server cannot see what's in the synced data.

This just sounds like an implementation limitation to me. There's no reason you couldn't do continuous merging at the client ends. The only real loss is that in the Firefox Sync encryption model, you can't really do delta compression to reduce bandwidth usage (or at least, you can only do it at a fairly coarse grain, i.e., the bandwidth savings are less). But I doubt that's a huge loss for the kinds of tiny files that we're talking about here -- sending 1000 bytes is not much more expensive than sending 100 bytes, once you take into account TCP overhead and all that.

Security quotes of the week

Posted Apr 28, 2011 3:07 UTC (Thu) by Hausvib6 (guest, #70606) [Link]

Mozilla should approve Honest Ahmed's request or perhaps we've become accustomed to lies, lies, lies, lies, lies, and lies.

As said in 1 of the comment in the bug report, at least Honest Achmed is more honest than Comodo. I don't understand why Mozilla rejected such an honest request.