Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Do you want to always have access to the user's drop box account or only when they are loged in to your system ? I assume the former since you want to store the o-auth token. In that case see the encryption discussion below for why you can't really encrypt it. I'd suggest however, that you take the safer route and only access drop box either when the user is loged in or shortly their after (i.e. don't store persistent auth tokens )</p> <h2>The secure approach</h2> <p>When the user logs in, get an oauth token from the dropbox, use it to perform whatever actions they want and if necessary keep it around after the log out to keep doing tasks ( background sync or something). However, once that last task finishes, delete the token. This means that if your server is compromised only the loged in users or those that recently loged out are exposed. Its a mitigation, but its the best you can get.</p> <p>I believe you can do this with o-auth without explicitly prompting the user for a new token every time. If not, I know you can do it with opendID, though I could see drop box not allowing that.</p> <p>Finally, if neither of those works, you could store the o-auth key persistently encrypted under a key derived from the users password with say PBKDF2(with like 5000 iterations). When they log in, you decrypt it, use it, and then delete the cleartext copy. The downside to this is 1) password resets require a fresh o-auth token since you no longer have their key and 2) the user must log into your site itself and give you a password so you can derive the key. They cannot use openid. </p> <h2>Encryption</h2> <p>If you want continual access to the oauth tokem you can't really do meaningful encryption. As you said, where would you store the key ? For a web service, there is no good answer. For an end user system, the answer is derive the key from the user's password which you the must not store(this is what lastpass does). You can't do this because you want to have access to the data even when the end (wepapp) users are not loged in.</p> <p>Ok, what about the sysadmin's password? Well since the server is running all the time, this is worthless since a compromise would still reveal the keys. Worse, reboots would take down your app because it needs the sys admin's password to decrypt its data and they are not likely their when the system crashes at 3am.</p> <p>They make <a href="http://en.wikipedia.org/wiki/Hardware_security_module" rel="nofollow">Hardware Security Modules</a> that store keys and perform crypto operations with them, so an attacker could get the key because it never leaves the HSM. However, an attacker could just ask the TPM to decrypt the o-auth string. The best you could do was rate limit this so an attack could only get like 1000 tokens an hour (obviously that rate needs to be larger that legit usage). Given that HSMs are expensive and make hosting expensive because you need a dedicated system, this is not worth it.</p> <p>In an ideal world, you'd use a <a href="http://en.wikipedia.org/wiki/Trusted_Platform_Module" rel="nofollow">TPM</a> to hold the keys and have it only release the data if the system is not compromised. Unfortunately, TPM's currently only support verifying that the correct program (e.g. the boot-loader,then kernel, then user land program) was loaded. They do nothing if that program is compromised after it is loaded, which is the threat vector here. This might change in the next 5 to 10 years, but that does not help you now.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COThanks for the reply... that gives me a lot to think about. The project i am working on needs permissions to a dropbox folder (not the full site) and needs to be able to write to it using a Windows Service... storing the password for only a small amount of time would not work for me. Hardware Encryption is not an option either, since, even though this is on a Dedicated Server, its actually a VM hosting the site... I am wondering though, how do sites like "if this then that" do it? they have permissions to put stuff in my dropbox... Am i over thinking?
      singulars
    2. COFor this kind of thing the answer usually is don't get owned. Data at rest encryption, which is what you wisely want to use, isn't widely used in cloud services and for the most part thats for a good reason: you have no where to store the key material that is any more secure than where you store the data in the first place. Can dropbox give you granular permissions to a specific folder ? I recall reading that google drive could and figured they cloned the feature from dropbox. If so, that at least mitigates the risk
      singulars
    3. COyea, dropbox can give granular permissions, which is what i am using currently (only accessing one folder, app specific). I suppose the only thing i can do is encrypt to the best of my abilities and just lock down as much as possible... Unless someone from IFTTT or another place using dropbox auth comes back with how they are working in the next few days, i will be accepting this answer. Thanks!
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload