How is data protected that is synced with 1Password.com
While I was reproducing a problem, I had both 1P 6 for Windows and the web app open and unlocked. I saw that syncing is happening very fast, I would say almost instantly.
But I was wondering, how this data is protected when it is synced "live"? I've read in the security whitepaper about the protection of data at rest, but I did not see much concerning sync (or maybe this is worded differently and I missed it. In this case my apologies).
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: 1Password.com
Comments
-
I believe that is covered in the Transport Security section of the white paper you refer to. Specifically the TLS and Our transport security bits.
0 -
Hi @manaburner,
That's an interesting question. The fact that you're seeing it as "live" is really just because modern computers and networks are really really fast. Let's take a look at how it all happens.
As you've read, data is encrypted at rest using your Master Password and Secret Key. When you make an edit to an item in a client with a local cache (the most complex case) here's what happens:
- The edited item is saved locally in the cache database, and is marked as having local edits
- The sync process is triggered
- Sync establishes a secure connection with the server via SRP if such a connection isn't already established. This is likely what @Penelope Pitstop is referring to
- Part of this connection handshake results in the server providing the client a push notification socket URL that it can connect to in order to be notified of changes from other clients. It connects to it.
- Sync finds any items that have local edits
- Sync takes the encrypted item and sends it to the server. It's encrypted once by the Master Password + Secret Key, and then again by the SRP session key, and then a third time by TLS.
- The server writes the encrypted item into its database (after unwrapping TLS and SRP)
- The server broadcasts a message on the push notification socket to announce that things have changed. This message contains only information like "User 123 with session 456 performed a change that you might care about", so nothing sensitive gets transmitted.
Now the other clients that are just sitting there very likely have an established connection to the server, and they connected to that notification channel. So here's what they do:
- They get the notified that another user/session performed a change
- They start up their own sync process
- Sync sees that there's a vault with an updated item so it pulls down the encrypted data from the server
- Sync will decrypt the data and merge it with its own changes if present, or simply write the encrypted data to its local cache
- The app realizes that the item you're looking at was modified, so it re-loads it from the database, decrypts it, and shows it to you.
So as you can see, there's only encrypted blobs being sent around. Computers and networks are so fast these days that it all feels instantaneous. We did put a lot of thought into our sync protocol in order to make it feel as fast as possible, but unless you've got a large vault with many many changes, the credit for the speeds you're seeing aren't related to those design choices.
I hope that helps.
Rick
0 -
Hi @rickfillion thank you, it does help :) I think you can copy that 1:1 to the security whitepaper
0 -
@Manaburner : i'll let @jpgoldberg know that he should steal that. :)
0 -
That just might work it's way into the white paper. Hey, @rickfillion, wanna learn LaTeX?
0 -
@rickfillion It’s a Trap!!!
0 -
/me pretends he didn't get any of those notifications. :P
0
