Access Tokens, Fiddler, Security

Don't they now have access to my Dropbox through the API? 

Yup.

I read some of the other posts about this subject and it appears to not be a major concern.

Is that really the case?

If the API is used as intended, its not really a major concern - the *intention* is that people connect to their own Dropbox accounts in your app, not you connecting other people to yours.  Yeah, it does work that way round, but you then get these issues where you are exposing tokens which were never supposed to be exposed to a non-trusted party (as in the 'intended' use, both you and the user trust each other - but in your use, you dont trust the user).

Am I missing something? I want to present a Dropbox based solution to my team for a project and I don't know if this is going to fly. My company is pretty tight about security.

If security is a concern, then you can always do your own API and hook into Dropbox from the server - then the client never sees your token.  But I'm guessing you want to avoid this, hence looking at Dropbox in the first place.

You could always set your app to have "folder" permissions rather than "account" permissions, but it still doesnt mitigate the issue if users shouldn't have access to everything in the shared folder.

Thanks Richard

We'll see how it goes.

Ted

My dogs don't know nothing about nothing. Sometimes I am like them.

All Dropbox traffic is https - right. Doesn't that mean someone cannot get the Access Token from a sniffer. With a temporary untrusted certificate, Fiddler can decode some SSL but from what I see, you can make it so your stream cannot be decoded this way and I was unable to use this technique to view, say an upload of files, the plain text.

So it appears that my initial concern is moot. Agreed?

Thanks Again,

Ted

So it appears that my initial concern is moot. Agreed?

I can decompile your app, or attach a debugger at run time, and sniff the key that way.

With a temporary untrusted certificate, Fiddler can decode some SSL but from what I see, you can make it so your stream cannot be decoded this way and I was unable to use this technique to view, say an upload of files, the plain text.

With a temporary, untrusted certificate, Fiddler can decode *all* SSL unless the app is specifically looking for a pinned certificate.  Which means you need to do a lot more in your app than simply opening a connection.

See the following thread for info on cert pinning, and what certs to pin and what not to pin.

https://www.dropboxforum.com/hc/en-us/community/posts/203833895-Dropbox-Certificate-Chain-for-Certificate-Pinning-single-or-multiple-chains-

But pinning still doesnt get you around my first point.

Thanks again Richard,

I remember hacking binaries with DDT in 8-bit CPM days. And if someone were going to go to that trouble - they would steal our IP and not an access token :--)

We are just looking to close the easy doors and SSL does that for us.

I'll read up on your links. 

Thanks

Ted

That "trouble" is two or three clicks at most with a modern IDE.  Remember that these days we often aren't dealing with a "binary", but rather something that is interpreted or requires a runtime to operate in...

SSL doesnt close all the doors in this case - it simply closes one door.  Don't pretend otherwise.

Thanks for posting Ted. Richard's right, fundamentally, client-side apps can't keep secrets, so we don't recommend embedding your own access tokens like this in client-side apps.

We'll consider this a feature request for short-lived access tokens, as well as more specific permissions, such as upload-only.