1Password X automatically logins to 1Password web application

mhofstetter

Hi there

Being logged in to the 1Password X Extension opens the 1Password web application when trying to edit an item. As far as I understand it automatically logins into the 1Password web application without having to authenticate again.

I do understand that from a usability point of view this is expected.

But from a security point of view i would expect that the 1Password X extension and the web application are respected as two separate "clients" where a re-authentication needs to be performed (with 2FA / Security Key).

This gets especially problematic when a user can navigate from the edit form in the web application to any other page he likes - whether this is a "hidden" vault during travel (which gets downloaded to the device / browser storage ?) or the profile settings where he could change the travel mode, view other clients or even change billing information. Of course as long as there's an active internet connection.

I would expect that a full re-authentication needs to be performed when accessing the web application - or that only editing is allowed.

I know that the beta provides integration with the native macos/windows app which might prevents this. But i'd like to stay with the 1Password X extension which runs on all platforms.

---

1Password Version: Not Provided
Extension Version: 1.22.3
OS Version: Not Provided
Sync Type: Not Provided

[Deleted User]

Hi

2FA isn't repeated once your 1Password database has been downloaded to your device. The database on your device is protected by encryption, not authentication.
I think 1Password X is just autofilling the 1Password website login in the same way that it autofills others. Have you tried moving the 1Password Account login entry to trash? Does it still login automatically?

mhofstetter

Hi missingbits

From reading the documentation and some entries in this forum i would expect (and still hope) otherwise. That they are treated as separate clients with their separate local database - although in the same browser local storage (e.g. https://1password.community/discussion/comment/573888#Comment_573888).

It's just that instead of the automatic login I would expect a dedicated authentication (with 2FA) towards the 1Password web app because this might download some vaults which aren't in the 1Password X extension (e.g. during travel). As mentioned the problem is that the edit view feels very naturally embedded but might download additional vaults and grants access to account settings which shouldn't be allowed and which leads to states where the additional vaults aren't deleted locally because one doesn't expect to have to perform an explicit logout in the web app (which deletes the local database?) because the "login" was automatically performed.

PS: I deleted the 1Password Account credentials which have been created with the starter pack during account creation right at the beginning. Therefore, it can't be a autofill - it needs to be some logic in the extension / web app.

It would be great to have this "verified" so I know whether this is a bug or a "feature" of 1Password.

Thanks in advance

ag_yaron

Hey @mhofstetter ,

1Password X and 1Password.com are two different clients indeed. 1Password X is locally stored in your browser, but 1Password.com is a cloud service and is not stored locally on your computer.

When you install one of our apps or extensions, a local copy of your database is being created from your 1Password.com cloud account. However, if you have vaults that are in travel mode or such, they are not being copied locally and will remain on 1Password.com only. Visiting 1Password.com will not add anything to 1Password X unless you create a new item/vault (that is not in travel mode) which will trigger a sync between the two.

As for authentication, once a device is authorized, which occurs once with your 2FA code, it remains in your authorized devices list, which you can see and control in your 1Password.com account's profile settings. When a device is authorized, it won't require your Secret Key or 2FA when logging into 1Password.

When you unlock 1Password X, it can then launch the 1Password.com web app with your encrypted Master Password and Secret Key, thus bypassing the login page of 1Password.com while still keeping you authenticated and secured. Nothing is being transmitted unencrypted and the process is quite straightforward (security-wise). We do a lot more encryption than authentication, which are two different things, and encryption is a great way to keep data safe :)

Here's more info on the matter, in case you are interested:

• 1Password X's security: https://support.1password.com/1password-x-security/
• Our security models in general: https://support.1password.com/1password-security/
• Security audits we've passed: https://support.1password.com/security-assessments/
• 1Password's security design white paper: https://1password.com/files/1Password-White-Paper.pdf

mhofstetter

Hi @ag_yaron

Thank you for your fast and valuable feedback! Great to experience the active 1password community and support!

1password.com web application:

Since the master password and secret key are never transferred to your servers the vault needs to be decrypted at client side (in this case in the browser). I assume that even though for this the vault needs transferred to the browser it doesn't get stored on disk / browser local storage and is kept in memory only?

1Password X

It seems that even though 1Password X and 1password.com are treated as separate clients they are listed as the same authorized device in the account overview - because their origin is the same browser instance. This way the 1Password X client is the "only client" which doesn't have a proper boundary between the "client" and "1password.com". Therefore travel mode doesn't work as expected (when having an internet connection during travel), because the vaults can be accessed and travel mode switched off without further authentication.

It just feels weird this way. Especially the point with accessing the vaults and the account details.

This is intended this way?

Thanks again - also for your interesting links!

rickfillion

Hi @mhofstetter,

I assume that even though for this the vault needs transferred to the browser it doesn't get stored on disk / browser local storage and is kept in memory only?

Correct, the 1Password.com webapp currently does no local caching of vault data. That might change one day as there are options for local caching these days in webapps. Should we ever change that, we'd be storing encrypted data, the same encrypted data we store locally in our other apps.

It seems that even though 1Password X and 1password.com are treated as separate clients they are listed as the same authorized device in the account overview - because their origin is the same browser instance

Correct, and I'm mostly the one to blame for that. Sometimes you make a design decision and come to regret it, and this is one of those cases. The intention wasn't to have one device behave as another the way that you're seeing, that was just an unintended side-effect. The "problem" I was trying to solve was that it's sometimes useful to have one 1Password app create an authenticated server session that can then be handed to another app. We use that mechanism in a few places, but originally it was designed for our Mac app. In our Mac app you can access your Billing settings in the Preferences window. Doing so opens a new window where we actually load up our webapp in a webview. It'd feel silly to have the user sign in again, especially since we have all of the keys needed to do the work for them. So the Mac app creates a new session with our server and hands that over to the webapp so that it can sign in. Part of the handshaking with the server to create that session is a device registration. It'd feel weird if when you were looking at the Billing settings in your Mac app you got an email from 1Password saying that there was a new signin from the web. The session that the Mac app creates is a Mac app session, and it's given to the webapp. In effect the webapp is now masquerading as the Mac app. This works rather well in the case of the Mac app and the Billing screen. But we've since used that mechanism in places that the original design didn't really take into consideration like the one you mentioned. And sadly it has the outcomes that you mention.

It's something that I'd personally love to make much better. I have some ideas for how we could tackle this in a way to still get the benefits we're looking for without the side effects we don't want. It'd require a few new things to be built on our end. The tough part is finding the time to build those things. Too few hours in a day.

Rick

Lars

@mhofstetter - I’m not sure what you mean specifically when you say “a proper boundary between the client and 1password.com,” but this is indeed working as designed.

If you turn on Travel Mode from any browser (which is the only way to do it; Travel Mode must be enabled in the 1password.com web interface, not in the 1Password clients themselves), then on any device where you have installed 1Password X in a browser, you can verify for yourself that any vaults not marked "Safe for Travel" will indeed have been removed from 1Password X.

However, that browser - the one with 1Password X installed - has already authenticated itself to the 1password.com server, when you initially set up 1Password X. You provided:

1. Your Master Password
2. Your Secret Key
3. Your MFA code, if you had that enabled

When you unlock 1Password X in future visits, you're required to enter your Master Password once more, but -- just as with the native 1Password applications -- your Secret Key is not required. When you click "Edit," you have authenticated with the server - by providing your Master Password (entered) and your Secret Key (stored).

If you had a native 1Password app installed, clicking "Edit" would edit the local copy of the data, but as soon as you switched vaults, or locked and unlocked again, if you had an internet connection, the first thing that would happen is a sync which would pull your changes from the local app to the server. And if you had an internet connection while traveling (say, airplane wi-fi), you would be just as easily able to open any browser in which you'd previously signed in, visit https://my.1password.com and provide your Master Password to authenticate, same as what happens behind the scenes with 1Password X.

mhofstetter

Hi

@rickfillion @Lars

Thank you for the verification and the insights into the design decisions.

I'm glad to hear that the web application doesn't store anything to the local storage. Of course I do understand the trade-off between usability and proper separation of the clients even though I hope that you find the time to re-design this in the future. Embedding the web page in a native client (e.g. macos) without the possibility to navigate around in the web page and leave the intended site is very different from having the possibility to access the full-fledged 1password.com web app without any further re-authentication and restrictions. And as you mentioned probably also not the initial idea behind the design.

Without this I have to live with the fact that travel mode doesn't work in the 1Password X client as intended - because even though the non-travel vaults aren't in the local storage of the extension and therefore not accessible via the browser extension, the user still has the possibility to view this vaults and can even change the travel mode by editing any entry and navigate to the given pages. That's what i meant with "proper boundary".

Some background regarding my motivation: It's not only about the original intention of the travel mode at the border control. My idea was to "use" the travel mode functionality to define some vaults which should never be stored and accessible (e.g. 2FA recovery codes) on the clients (mobile & macbook), by just having the travel mode "always ON". They should only be accessible in emergencies by accessing the web application which (in my dreams) then would always ask for the second factor (in my case a security key) - and not only the master password (& secret key) which is enough to decrypt the local vaults. Of course this would only be possible as online functionality.

It would be great to see such a functionality in the future.

I hope i was able to explain my idea good enough - maybe it helps you in upcoming decisions.

Thanks again!

[Deleted User]

This is a really interesting thread and thank you everyone for your contributions.

@mhofstetter if I've understood your need correctly then I achieve the same by storing a Keepass database of 2FA recovery codes, secret keys, security questions, etc at a cloud provider. The database is sync'd across devices with the cloud provider's password held in 1Password and their 2FA code stored in Authy. It is secured with a master password shared with my family via 1Password and a key file which is not stored on any device.
This is not as convenient as storing everything in 1Password, but I needed somewhere to store the secret key and to provide a means for my family to gain access to my Private vault in the event of my untimely demise! We hopefully won't need to access it very often!

ag_yaron

We're glad we were able to help and clarify the situation.

Thanks for all the thoughts and feedback, much appreciated! Hopefully we will be able to address it in the future after our current roadmap.