Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Sort of alarmist, if I understand it.†

The root of his concern is that Dropbox is vulnerable to local attackers. There is little Dropbox could reasonably do to meaningfully change this††. The Dropbox client needs to be able to authenticate itself to the Dropbox server as the price of entry to make Dropbox work. The Dropbox client is usually always running, and is in any case often running. While it's running, anything it did to prevent attackers from stealing authenticators could be circumvented by attacking the running Dropbox process.

If you think about it, this is a problem essentially shared by Google, and your bank. It is fair to critique the application for not making it even easier to revoke access to all but your current authorized machines (in other words, to make rekeying understandable and simple). But it's a UX issue, not a fundamental security problem.

† I may not; I'm going from 'trotsky's mirror.

†† Irony, based on previous comments from me today, noted.

Well, it's a stored authentication token mechanism, which is the same as is used by many other client-side software. However, there are two possible ways to improve the authentication:

- use a second factor in the authentication, such as the MAC address of the primary NIC in the machine

- limit the time that the token is valid by getting the client to periodically get a new token from the server. This prevents two clients using the same token indefinitely without detection.

Both these would be good improvements to the security of the host_id data that Dropbox uses for authentication.

A system can easily be set up to lie about its MAC address, and you can't hide the legitimate MAC address. It's a very bad secret value.

The only thing you can do, without entering the reverse engineering arms race, is to add a real second-factor key to the equation --- meaning, something a user has to remember or read off a fob. And in fact, only the fob helps you here, since malware can (and does, every day, in bank fraud trojans) capture any secret you enter.

I agree that it would be better for security if Dropbox made rekeying happen more, but they can do the cost-benefit better than I can here.

In addition to MAC address use adding no real security it would get in the way of running Dropbox on a flash drive, which works even if not ideally.

Keep in mind here "not ideally" includes "you lose your flashdrive, then whoever finds it has full and ongoing access to your Dropbox account".

That's kind of a worry.

Ongoing? I can still use the website to delete the host whose host ID is on the flash drive.

So long as you realised... From FTA:

"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."

Of course I assume that I eventually notice the theft of a USB stick on which I put enough information for Dropbox to sync my entire tree. Does the article say that I can't revoke a machine's access via the web interface once the config.db for that machine has been copied?

Apple has solved this pretty elegantly using just the machine id. When you purchase an app on the appstore apple creates a receipt that contains a hash of your machine id as well as other meta data. The receipt is then signed with Apples certificate.

When you launch an app you verify the receipt was signed by Apple and that the hash of the current machine id matches the hash of the machine id in the receipt.

Dropbox could generate the same sort of receipt serverside when you first sign in. From then on each time the dropbox client launches it just validates the receipt against the current machine.

This works because Apple is in the reversing arms race. Does it make sense for Dropbox to go down this path? Note that Google and your bank don't.

Banks absolutely do this once they have the ability to talk to the OS. I've built 3 banking apps for iphone/ipad now and client side verification was involved in all of them after first login.

The problem is browsers just don't have a good standard way of accomplishing this.

All my banks do. If they detect a browser/IP that I haven't used before they ask me for another piece of authentication (secret question)

I think we're talking past each other here. I thought we were talking about embedding secrets in machines. If you want a button in the Dropbox UI that tells it to freak out when your IP changes, that's fine; I think there's a good reason Gmail doesn't default that way though.

Blizzard freaks out about changing IP addresses when you sign in to World of Warcraft. I have two internet connections at home and sometimes I switch back and forth, and back when I was playing WoW, it would lock me out after each switch. I had to login to my account via the battle.net website and stell it that everything was ok.

It was extremely annoying. The last few times it happened I just didn't play for a while because I didn't want to bother with reauthenticating; that's when I realized that I didn't enjoy the game that much any more and cancelled my account.

for the sake of counter-example: facebook does. E.g. if you try to log in from a different country than ones it already knows you have to go through a long process of reauthentication by inputting your friends' names based on pictures. At least, it happened to me twice.

Again, the machine ID is easily faked by an attacker.

> The only thing you can do [...]

Or you could build a trusted end point. Otherwise even two factor auth is only palliative. (But yes: cost-benefit, I hear you).

http://www.businesscomputingworld.co.uk/two-factor-authentic...

Yes, systems can definitely fake any ID you attempt to use: MAC addresses, machine IDs, hostnames, etc. Attackers can intercept rekey attempts and clone the new key on their systems. But arguing that these improvements shouldn't be done because they don't totally close every security vulnerability in a system is an example of Perfect Solution fallacy [1]. Just because security cannot be perfect doesn't mean that steps to improve it shouldn't be taken.

The advantage of rekeying or secondary verification of the client is that it addresses the kind of attack where you can simply copy this metadata and have enough information to remotely compromise the Dropbox data later. As you say, whether that is worth fixing is up to Dropbox to do a cost-benefit analysis. But I hope they wouldn't discard the chance to improve their security simply because a perfectly secure system isn't possible.

[1] http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_Solutio...

They could make the token derived from user's password (e.g. Hash(host_id + Hash(password))), so when password changes, all existing tokens are invalidated.

We haven't looked at Dropbox professionally; if tokens are valid after password changes, we'd flag that. I'm don't know enough about Dropbox to say whether they do or don't.

(I have Dropbox on my personal machine but not my work machine).

The article says that changing passwords doesn't help: "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)."

So, if my password is compromised (or I just routinely change it after some self-defined "expiry date"), I have to visit all my devices and reauthenticate them?

I believe this is counter-intuitive and inconvenient. If some of my devices (tokens) are compromised, I'd just go to Dropbox web interface and revoke their tokens.

Normal people assume that if their account is compromised, the appropriate countermeasure is to change their password and get on with your life. Is Dropbox a tool for normal people or for people who geek out on device authentication?

So, in proposed scheme, they change the password and everything goes out of sync.

The proper and perfectly intuitive way is to not think what users'll assume. Just add a checkbox "also, unlink all my devices" on the very password change page.

Another, rather extreme, option would be to support hardware security devices that can store PKI private keys and perform asymmetric encryption within the device (i.e. there is no way to read the private key) e.g.

http://www.safenet-inc.com/products/data-protection/two-fact...

This would provide a pretty good additional "something you have" authentication factor.

Whilst the system software is vulnerable this doesn't gain a lot (you're in Thomas' arms race): malware intercepts the transaction request and requests "please scan your fingerprint to sign transaction of $1"... then quietly presents a $1000 charge to be signed by the PKI token. Even TPM can't help if the software is hacked.

An easier way to detect something fishy would be to allow at most one connection per auth token, and invalidate it and re-request login credentials if a collision occurs. Just ping both connections first to make sure they're both actually alive, and not the same machine logging in again after a reboot-after-crash.

Hypothetically, dropbox could install on the system a second, isolated authentication process, which generates a keypair for that machine, and hides it somewhere with an ACL that does not allow the normal user direct access. Then, upon login, the dropbox client asks the auth process to sign a nonce to login.

This would mitigate the problem to an extent; an attacker then wouldn't be able to succeed with just the user's data, they'd need to get administrative access to extract the authentication keypair as well. It would, however, require administrative access to install the authentication agent program, unless there's a suitable blind keystore in the OS already.

I like the idea from a technical point of view, but I doubt it would make much of a difference in practice, because most home users log in with administrator accounts anyway. So do most developers. Only the rare, security-conscious power user would typically log on with a restricted account and even then.

Only Windows users or developers regularly login with administrator access.

Reply on news.ycombinator.com