Can someone explain what is stored and how it is stored.
I see that the OAuth tokens are stored on your servers instead of the local machine. How and when are they encrypted/decrypted? I added a couple accounts and from what can tell the encryption process would have to be on your end so you would also have the keys. Are the keys unique to the user?
What about connection info for things like FTP/SFTP ? Now we’re talking about passwords or ssh keys which is scarier.
I came across this on the odrive forum
If an attacker can successfully penetrate Google’s infrastructure and reach the DataStore instance where we store your OAuth token, and they can decrypt the token before they expire (tokens expire within hours while AES encryption is impossible to break within hours), the attacker can access your data.
While I am not all that familiar with OAuth I’m pretty sure Dropbox does not expire their tokens. Also with it not being zero knowledge for the token store what’s preventing them from stealing the keys?
I’m surprised and concerned by the lack of documentation regarding your security practices.
These are valid concerns. The thread you referenced goes into a lot of this with regards to how the connection info is encrypted and how the exact information differs between integrations types. There is also some other info in a different thread. I will post the relevant pieces here, along with some further clarification:
In short, we use AES (CBC) for encrypting the connection information. We are only storing the bare essential information for facilitating access across our client interfaces (desktop and web client). For OAuth-capable services this means we are only storing the service-supplied tokens and never see your password or other sensitive authentication information.
Generally these tokens expire. Some access tokens actually expire very quickly (after an hour for OneDrive and Amazon Drive, for example). Dropbox has chosen to effectively not expire their tokens, explaining that users can revoke application access at any time. It’s not a practice I am fully supportive of, personally, but it is what they have decided to do.
For legacy protocols (FTP, WebDAV, and SFTP) and utility storage like Amazon S3, which do not make use of auth schemes like OAuth, storing the credentials is required. These are kept in an encrypted state in our database. Again, the encryption keys are kept separate from the data.
I saw that but I struggle with [quote=“Tony, post:2, topic:842”]
This allows you to use multiple clients without having to re-authorize each system separately.
It seems like a weak argument for storing tokens especially considering the security benefit to doing so plus the authorization process is painless. Also I still have to authorize the client on each machine with one of the services anyway
So each client is making direct requests to the cloud service using the same tokens over all the clients?
Just trying to wrap my head around the authentication process etc.
I think my biggest concern here is it’s potentially putting a lot of access in one location.
Was looking back through some posts for reference and realized I didn’t answer this question:
Potentially. Many services expire tokens fairly frequently, some don’t expire them at all, like Dropbox. Some allow a couple tokens to be active, concurrently. This means that separate clients can use the same token or different tokens, depending on the timing and service being used.