e.g. when I authorise ODrive to access my Google Drive, does it pull the data from Google (and push to it to keep it in sync) or is it simply an interface?
Hi @Noffica,
Authorizing a linked storage source allows us to send it requests on your behalf, triggered by your actions. When you utilize the odrive desktop client it then can make requests directly to the storage sources you are linked to.
Communication and transfers to those sources are direct between the odrive desktop client (your computer) and the storage.
We do not store any of your files on our servers.
2 Likes
Can you clarify where the OAuth token is stored? Does odrive ever store the token on odrive owned servers? Or is it stored on the client computer (with the odrive sync client)?
1 Like
OAuth tokens are stored in the odrive service layer encrypted (AES in CBC mode). This allows you to use multiple clients without having to re-authorize each system separately.
As the authorizing user, you have direct control over this information. The encrypted tokens are deleted when unlinking a source from odrive. They are rendered useless if odrive access is revoked on the storage source. In either case, odrive will no longer have the ability to access your previously linked account in any way.
1 Like
Tony, thanks for your response.
When you say “multiple clients”, are you referring to the odrive desktop client software on multiple computers? Or something else?
My concern is that if odrive’s servers were to be compromised, the intruder would have access to all customer data until tokens are revoked. If the intrusion were undetected, then the user would be none the wiser to their data being accessed. Is my assumption correct, that even if the tokens are encrypted on the server-side, an intruder could decrypt them using the private keys stored on the server itself?
I work for a business for which many users would benefit from odrive’s placeholder technique of saving space. But it seems like granting yet another 3rd-party token access to potentially sensitive business data is risky. Having the oauth token only stored on the user’s own computer would get around this.
1 Like
Hi Jared
That’s a good question.
As Tony stated, odrive stores OAuth tokens in the cloud to simplify access. If you sign in from another machine or if you sign into the web, you don’t have to sign in again to all your links.
Odrive protects the OAuth tokens by encrypting them with AES before storing them. More specifically, odrive runs on Google App Engine, and it stores the encrypted OAuth token in Google DataStore.
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.
Does that help? Let us know if you have any more questions.
-peter
1 Like
This makes me realize a whole different security issue. This allows users to unwittingly provide a “backdoor” to sensitive business data that would otherwise require two-factor authentication.
For example, if a user connects their Facebook account and employer provided Google account (which for arguments sake requires 2-factor auth) to odrive, then any attacker only needs to compromise the user’s single factor Facebook account in order to access sensitive Google Drive data, (without ever providing a 2nd factor).
I can see the convenience, but I wonder how many users realize that if they use one account with out 2FA, they are putting all the accounts that do require 2FA at risk.
I don’t know the ins and outs of how OAuth tokens work, so forgive me for any misunderstanding. With Google OAuth tokens, I seem to recall there are two types. Access tokens and refresh tokens. I assume that odrive is storing an encrypted refresh token. The refresh token does not expire (unless revoked by the client).
So to gain access to client cloud data (on Google Drive for example), if an attacker were to breach an odrive server, they could decrypt the refresh token using the keys stored on the odrive server.
This would not be an issue if the oauth token was stored on client computer. This would require the odrive user to grant access to each cloud service on every device. But it would make things make considerably more secure.
Unless I’m missing something, which is quite possible, if a hacker were to gain access to an odrive server, and use that access to decrypt tokens, it would give them access to all user data.
1 Like
@jared You are definitely thinking about the right things here and your understanding of OAuth2 basics is correct.
There is certainly a responsibility put on the user to determine what method of auth is right for them. Interestingly enough, Facebook actually offers additional security layers for auth, but I think most people aren’t aware of them (or don’t care 
)
Our backend is hosted on Google infrastructure, which sets a very high bar for both platform and physical security. We do not keep any keys alongside the encrypted data, which means that an intruder would need to compromise multiple pieces of the infrastructure to have a chance at compromising the data.
For those who want even more security, we also offer zero-knowledge encryption. You can encrypt the data within your storage with your own key, ensuring that only you can decrypt and access the data. https://www.odrive.com/features/encryption
2 Likes