Sync frequency

mrpaul

• How frequently does the 1Password client sync with 1Password cloud?

• Do you need to be logged in for the sync to occur. That is, I set 1Password to start when I log in to Windows. It starts, but I don't necessarily log in to 1Password until I need it. Does 1Password sync during that time that it is running but I'm not logged in to 1Password? Why do I care? I need to understand this scenario:

  • A coworker creates a new password

  • I log in to Windows while connected to a network - does 1Password sync now?

  • I move to an isolated network with no external access

  • Will I be able to log into 1Password and access that password my coworker created?

---

1Password Version: 7.2.581
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: 1Password
Referrer: forum-search:sync

Jacob

Hey @mrpaul! I replied to your email about this and wanted to comment here as well. So long as the Internet connection is stable, the 1Password apps will sync when they're unlocked and the server notifies them that there's something to sync. They will also sync when you add or change an item, which tells the server something is new. The apps have to be unlocked for this to work since the data in your account is encrypted and requires your Master Password to decrypt, so you'll need to addd to your workflow that unlocking the app is necessary for it to sync.

ref: NPJ-18443-641

mrpaul

Thanks.

When you log in to the command line app (op), does that sync your local data store to the cloud? Or does it interact directly with the cloud?

Meek

Hey @mrpaul, the command line app does not trigger a sync with your main 1Password app - it is a separate tool and interacts directly with the cloud. Let us know if you have any more questions!

mrpaul

Thanks. so it seems to me 1Password does not really have a backup process for those of us who want to maintain our own backups, in case 1Password is ever offline. I see two options:
1. Use the client application, and log in regularly. This is only as good as your last login. So if a teammate updates something overnight, and when you start in the morning 1Password is experiencing an outage, you won't get that update (and won't even know about it), unless your teammate communicates out-of-band.
2. Use a scheduled script to loop through all your data and export it. This has risks associated with that scheduled script needing full read-access to 1Password.

I'm really surprised that you have to authenticate to 1Password in order for the data to sync. I thought that the encrypted data would still get sync'ed to your machine even when you're not authenticated, and authentication would only be necessary to decrypt the data.

Ben

@mrpaul,

I think it is fairly sensible to require authentication before the encrypted data can be downloaded, but I will pass the feedback along to our team for further consideration. Thanks for the feedback. :)

Ben

mrpaul

I agree - somewhat. I agree that I should not just be able to point my 1Password installation at some other company's vault and download the data, but it shouldn't need to be a full authentication either. I would be fine with my 1Password installation having access to a key that authenticates it to 1Password in order to get my encrypted data. It would be great for that to be able to be scheduled and not require whatever secret is used to decrypt the data. Then, when I log in, it wouldn't matter as much if 1Password were unavailable.

rob

That's a very interesting idea. I'm not sure if you're familiar with the way 1Password authenticates with the server, @mrpaul. We're using the Secure Remote Password protocol, which means we derive a secret, x, that is used to authenticate you without transmitting your Master Password or Secret Key over the Internet. To do what you're suggesting, I believe we would need to store x unencrypted on your local device. That would mean that any attacker who could access your device could sign in as you and perform any tasks (potentially administrative) that do not require the ability to decrypt your encrypted data.

The only alternative I see would be to have a separate "key" as you mention that initiates a lower trust-level of authentication which only allows sync to occur. I don't see that happening because of the complexity it would add to our security model for what seems to be very little gain.

That said, if @jpgoldberg wants to chime in here, I'm sure we'll all be the better for it. :)

mrpaul

Interesting. So it sounds like X authenticates you for everything you do within 1Password except the decryption itself.

It sounds like we could get close to my request by setting up a separate read-only account. Storing that value of X locally should be relatively harmless.

rob

So it sounds like X authenticates you for everything you do within 1Password except the decryption itself.

Yes.

It sounds like we could get close to my request by setting up a separate read-only account. Storing that value of X locally should be relatively harmless.

That's true, but...

• The account would need to be given read access to every vault in the organization, or there would have to be a separate account for each user with read access that matches that user's access.
• It would still require a change on our end to read that value of x and use it to request and merge the data into the database, scoped to your actual account. Right now a 1Password installation can only have one user signed in per account.

jpgoldberg

This is a very interesting discussion, @mrpaul. So yes, having just the SRP-x would allow a client to authenticate to the server and fetch the data that that user is entitled to fetch. But being able to authenticate doesn't perfectly match up with what you want, although it comes close in the most common cases.

I'm not sure that you would be able to get new vaults that you have been added to this way, as you will not be able to decrypt the vault key, which may be required to get some metadata needed to fetch the vault for the first time. Pushing locally cached changes up to the server might also run into some weird cases, but I can't think of any off of the top of my head.

There are mismatches in the other direction. There are some administrative actions you can take which only require authentication, such as removing someone from a vault that you manage, but you would not be able to add someone to a vault (as that requires having the key to the vault decrypted).

Most importantly, the results are unpredictable. We've not built the server to separate out these cases. If by policy (that is trough being authenticated) you can initiate a process that will also require you to be able to decrypt or encrypt something, the service won't stop you from trying, and so will fail have way through. In some cases, such a sequence of events will be perceived of as an attack, and the server may drop your session entirely.

So while we do separate this notion of authentication and encryption, we do not separate them in a way that would make what you are after reliable. And we are always looking for ways to shift to more cryptographically enforced controls from server policy enforced controls. What works today for a proposed set up like yours may not work tomorrow.

So yeah. It is a cool idea, but I think that even if you were to have a client that did the right thing, this wouldn't actually work out well in practice.

mrpaul

Thanks for the super thoughtful responses.

I should state what my goal is, and we can explore what the right way to achieve such a goal is. What I suggested above might not be it! The example I gave in my first message was a bit contrived, and also simplified. I'll try to be more explicit here:

I am looking for an on-premise encrypted backup of one or more vaults (but not necessarily all) for my organization that is always up-to-date within some allowable timeframe (eg, 5 minutes or 1 hour) and doesn't require a person to manually connect to 1Password to create the backup. Ideally, the data should never be decrypted during the backup process. If individual vaults were backed up separately, that would be fine. The backup does not necessarily need to run on an end-user's machine. A user with a valid account should be able to decrypt any data they have the decryption key for. The process of getting the data from the backup location to a user's machine can be complicated (as long as it is well documented and tested), because recovering data from the backup should be a rare event. In the event of using the backup, reading the data is the primary need; any data maintenance such as creating new data, updating data, or deleting data is not required.

Reason for such a backup: to mitigate the risk of 1Password cloud data being unavailable. It could become unavailable due to an attack, a BGP leak, DNS failures, network provider failures, business failure, etc.

Is this currently possible? If not, would it be a feasible Request For Enhancement given your architecture?

Thanks!

Paul

mrpaul

One more requirement: Ideally, the account performing the backup would be unable to decrypt any of the data in the backup.

rob

Hey, Paul.

That should all be technically feasible using our current architecture, but not using any of our currently available first party clients. You would need to be intimately familiar with the authentication and vault item APIs, which are not documented publicly, and essentially write your own basic client. Disclaimer aside, it's an interesting question, so here goes...

You could have some user on your account named BackupBot or something and in the admin console give it read access to the vaults you want to back up. Then you'd have some sort of scheduled script that has access to BackupBot's credentials and can authenticate and download data. You'd have to write your own code here instead of using the CLI, which doesn't provide the raw encrypted data. Since our API is private, that would probably require reverse engineering our JavaScript in the web client.

Say you were able to figure out how to save the encrypted data locally. Restoring such a backup would be very painful and is not documented either. But it would be feasible assuming that you also saved the decryption keys, encrypted for the BackupBot user. Of course if you have the encrypted keys and the BackupBot's credentials saved on disk, the encryption isn't doing much for you.

Regarding your final comment, it is not possible in our architecture to grant a user read access to encrypted data without giving them the keys to decrypt the data. However, if you are already doing the stuff above and working directly with our private API, you could theoretically remove the bot's access to its Master Password and Secret Key and simply give it the SRP x value for authentication. In that way, the bot would be able to authenticate and download the data but not be able to derive the key to decrypt the vault keys. Note that in that case, you would need to save a copy of BackupBot's credentials somewhere else so that should you need to restore the backup, you will be able to derive the key that decrypts the vault keys.

In short, this sounds like something we would have to build in to our system unless you or your people are determined enough to do all of the above. None of it is documented or tested, and since the APIs are private, it could break easily.

As for whether we would ever build this in, my guess is that it would be more likely for us to provide full on-premise hosting of the 1Password service, which would solve your case (I assume) as well as many other use cases and requirements.

mrpaul

Thanks! Super interesting. I suspect you'll be quietly building this just for fun... Anyway, I'll wait for 1P to build it for me.

An on-premise 1Password would potentially solve our case, but at the expense of having to host it. I prefer letting you folks host it and be responsible for 100% uptime, patching, upgrades, etc, and us just backing up the data on-prem for the hopefully rare occasions when the data is not available online.

Its been a fun and interesting discussion. Thanks for all the detailed responses.

rob

I prefer letting you folks host it and be responsible for 100% uptime, patching, upgrades, etc, and us just backing up the data on-prem for the hopefully rare occasions when the data is not available online.

Interesting perspective, thanks for sharing!