Odrive security (passwords, connection info, OAuth, etc)

[tommyent]

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.

[Tony]

Hi @tommyent,
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:

Does ODrive store data on its own servers or simply display it?

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 w…

Does ODrive store data on its own servers or simply display it?

@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 …

Odrive security and update concerns

@Midasx @jared Thanks for the input. I really appreciate it and I completely understand your points. These are topics that we have discussed at great length internally, as well. odrive was actually born from an enterprise storage product with the entire range of enterprise-level features: on-prem storage with encryption at rest, client encryption at rest, AD/LDAP auth, auditing, multi-level ACLs, device whitelisting, remote-wipe, etc. An IT dream. As you guys probably know, though, there is alw…

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.

We also offer zero-knowledge data encryption features within odrive: Zero-knowledge encryption for Dropbox, Google Drive, OneDrive, Box, S3, WebDAV, FTP, and more

[tommyent]

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.
[/quote]
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

@AsifNisarr

When you utilize the odrive desktop client it then can make requests directly to the storage sources you are linked to.

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.

[Tony]

Was looking back through some posts for reference and realized I didn’t answer this question:

@tommyent

So each client is making direct requests to the cloud service using the same tokens over all the clients?

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.