Protect what matters – even after you're gone. Make a plan for your digital legacy today.
device trust
12 Topics1Password deployment on VDI / Citrix environments - best practices and support status?
Hi everyone, We're evaluating 1Password for our organization and need to deploy it in a Citrix Virtual Apps and Desktops environment. I've read through the deployment documentation, but I'd like to get some clarity on a few points from the community or 1Password team. Our scenario: Citrix Virtual Apps and Desktops (mix of persistent and non-persistent VDI) Windows Server-based session hosts User profiles managed via FSLogix / Citrix Profile Management Questions: Non-persistent VDI: What's the recommended approach for non-persistent/pooled desktops where the VM is reset after each session? Is it sufficient to persist the local data folder via FSLogix or Profile Management, or are there additional considerations? Multi-session hosts (RDSH): Is 1Password supported on multi-session Windows Server environments where multiple users share the same server? Are there any known limitations? Browser extension: Does the browser extension work reliably in VDI scenarios, especially when connecting to a locally installed 1Password app on the virtual desktop? Installer choice: The documentation mentions that MSIX is preferred over MSI. Are there specific VDI-related reasons for this recommendation beyond the passkey limitation? Any insights from organizations running 1Password in similar environments would be greatly appreciated. Thanks!80Views0likes0CommentsKolide Custom Checks?
Hi everyone, We have rolled out 1Password XAM and are really liking the Kolide Device checks. However we are running into edge-cases where we need to configure some custom checks and are struggling a bit. For example, we want to allow people with devices owned by other (partner) organisations access to some of our Kolide-protected apps. They have been allowed by their admins to install Kolide but they use a different EDR product that is not covered by the supplied checks. (Ie we use Crowdstrike Falcon, they use Palo Alto Cortex) Has anyone worked out a way to implement this sort of thing? Both in terms of a custom checks for Cortex and an either/or setup for EDR.12Views0likes0CommentsAdmin Being Prompted To Transfer Encryption Key
I'm the sole active Admin in our environment and I've been essentially locked out of my 1Password account the entire day with no response to my submitted ticket from a Solutions Engineer. I'm an admin who is setting up 1Password with Okta for the first time and during the process, my session was kicked out. Upon trying to log back in, I'm being prompted for a Recovery Code but I'm unable to view recovery codes, as I'm the only admin in the system and I can't get to the admin settings to log in. I've searched and searched and the only solution seems to be to contact support. Support can only be contacted via the Chatbot which seems to be very limited in the actual solutions it can provide, as the responses are fairly canned. I'm hoping there's someone out there from 1Password that can help escalate my issue as our entire system is essentially completely locked out for anyone.69Views0likes1CommentHELP! Some of our team member cant access the app within the vault.
I need some help. I’m the admin and password manager, and some team members can’t access the platforms in the vault I shared with them. A few users can log in without issues, but others are getting “incorrect password” errors even though the credentials are correct. I can log in fine on my end, so I’m not sure where the issue is. Because they needed urgent access, we had to share the passwords manually, which defeats the purpose of the vault. I’d really appreciate your help resolving this.33Views0likes1CommentResearch opportunity: Help shape the future of 1Password + gift card for your time
Hey 1Password community 👋 Our team is running 1:1 research interviews with current 1Password Business customers, and we’d love your insights. We’re especially interested in hearing from folks using the 1Password Enterprise Password Manager (with or without 1Password Device Trust or 1Password SaaS Manager), and who are involved in managing access, identity, and device posture at their company. Our goal with this research is to better understand how access is managed in the real world, especially in places where SSO, IdPs, and MDMs may not reach. Your feedback will directly influence how we evolve our products and features going into 2025. Who we’re looking for: Admins, IT, or Security leads at companies with 500–3,000 employees in North America, Europe, or Australia Decision-makers, or those with hands-on experience managing access tools Current users of 1Password Business and/or Extended Access Management What to expect: A 60-minute live interview Flexible scheduling between August 4th and 15th A $100 gift card from popular retailers as a thank-you We only have 10 slots available, so if you’re interested, please fill out this short screener survey. Thanks for being part of the community, we’re excited to learn from you!77Views1like0Commentsdebsig package signing issue for 1password & 1password-cli
Problem: I have already raised this issue by email (no response from 1password yet), and BitBot has given this matter reference CKQ-37366-878. 1Password uses the weak, deprecated algorithm SHA1, with debsig, to sign its Debian packages (this affects both 1password [gui app package], and 1password-cli, each in their deb package form). Way back in Nov-2021, debsig v0.24 deprecated SHA1 as an acceptable way to sign packages. This is because a practical collision attack for SHA1 was first demonstrated in 2017. debsig release announcement: https://lists.debian.org/debian-dpkg/2021/11/msg00006.html#:~:text=*%20reject%20weak%20ripemd160%20and%20sha1%20algorithms Any Ubuntu or Debian distro using debsig >= v0.24 will by default not verify 1password or 1password-cli packages, due to the use of weak SHA1 packages. To further prove it is use of weak SHA1 algo for signing that is root cause of debsig-verify failing, and nothing else, you can put "allow-weak-digest-algos" (without quotes) into /etc/gnupg/gpg.conf and then debsig-verify command will confirm that latest 1password or 1password-gui deb package was signed appropriately in "_gpgorigin" file. Yes, an SHA1 collision is still hard, and so SHA1 signing is still better than nothing, and Debian packages is a smaller subset of an already small linux user base for 1password, but it still disappoints me that 1password appears not on top of ensuring all of it crypto algorithm use, are strong, secure, not depricated ones! It makes me wonder and worry where else depricated crypto cyphers are in use, and should I switch to something with more open source code that I can check for myself, like Proton or Bitwarden. Fix required: Please restore my faith in 1password by switching your signing algorithm for all Debian packages, from using SHA 1 (digest algo 2) to SHA 256 (digest algo 8), or even better, SHA 512 (digest algo 10), for debsig. This does not need to change the keys you use, and changes nothing about the underlying packages for 1password or 1password-cli. It is just a change to the deb packages. Steps to reproduce and analyse the issue: (1) Fire up an Ubuntu or Debian instance with debsig >= v0.24 (I used Debian 13 Trixie) (2) wget -O "1password-latest.deb" https://downloads.1password.com/linux/debian/amd64/stable/1password-latest.deb This gets you a suitable package to test the problem on. (3) debsig-verify -d 1password-latest.deb This runs debsig-verify, with debug output visible, on the just downloaded deb package. You can see the signature failure message on the final output line. Higher you can see complaints about an invalid digest algorithm as the root cause (4) Add "allow-weak-digest-algos" (without quotes) into /etc/gnupg/gpg.conf and then re-run the debsig-verify command from step 3 above. Now that we move away from default secure config to reject old, weak depriecated algorithms, such as SHA1, the 1password deb package successfully shows as signed. You could keep all the same keys, and just switch the signing algorithm used by debsig, to SHA256 or even better SHA512 (SHA512 is 64-bit words, so no slower on 64-bit architectures than SHA256, but larger and more secure), and you would fix this problem. If you are still using SHA1 here, and had not noticed until user pointed it out, you should probably (re-)audit where else you are using weak, old, deprecated cyphers in your codebase too, as a good step to continuously improve 1password security!70Views0likes1CommentRequest for Zen Browser communication to app Support in 1Password (linux)
The 1Password browser extension cannot connect to the 1Password desktop application when using Zen Browser, despite native messaging being correctly configured. This results in fingerprint and other quality of life not working on Zen. The connection fails because 1Password's BrowserSupport binary rejects Zen as an "UnknownBrowser". - OS: Linux (Arch-based) - 1Password: Version 8.x (Linux desktop app) - Zen Browser: Version 1.16.3b (Firefox-based, using Gecko 143.0.4) - Extension ID: `{d634138d-c276-4fc8-924b-40a0ea21d284}` (1Password extension version 8.11.12.27) 1. : The native messaging host configuration (`com.1password.1password.json`) is correctly placed in all standard locations: - `~/.mozilla/native-messaging-hosts/` - `/usr/lib/mozilla/native-messaging-hosts/` - `~/.zen/native-messaging-hosts/` 2. When the 1Password extension in Zen attempts to connect, the BrowserSupport binary IS successfully invoked with the correct parameters. 3. **Failure Point**: The BrowserSupport binary immediately returns: ```json {"type":"Notification","content":{"type":"BrowserVerificationFailed","content":"UnknownBrowser"}} ``` Exit code: 1 4. The BrowserSupport binary appears to have a whitelist of supported browsers and doesn't recognize Zen Browser's identity, despite Zen being a Firefox-based browser. Please consider adding Zen Browser to the list of supported browsers in 1Password's BrowserSupport binary. The browser's application identifier is: - **Name**: Zen - **RemotingName**: zen - **Application ID**: `{ec8030f7-c20a-464f-9b0e-13a3a9e97384}` If you need any additional technical details or testing assistance for Zen Browser support, I'd be happy to help provide that information. NB! Fingerprint works fine on Firefox on the same machine. Just not on Zen, because apparently "unknown browser" on your side. Also I am not sure, but its possible same issue occurs on MacOS(too lazy to test)Solved92Views0likes4CommentsHelp with 1Password SSO Unlock Across Multiple Desktops
Hi, I’m looking for some assistance with 1Password in a small office environment (around 45–50 desktops) that runs Hybrid AD. We’ve enabled Unlock with SSO, and it works fine on a user’s first workstation. However, when the same user signs in on another workstation, 1Password prompts them to transfer their encryption key. The challenge is that our users often move between desktops throughout the day depending on their work schedule. This constant key transfer prompt is disruptive. Is there a way to disable this key transfer requirement or a recommended best practice to allow seamless use of SSO across multiple desktops? Thanks in advance for any guidance!162Views0likes5CommentsIssue re-instating employee
Hello, We provision 1Password from AD. We had a user resign and return shortly after. We had not wiped their device so we returned it to them. They were removed and re-added to the group we use to control who gets invited and their account and profile look normal on the 1Password admin console. We initiated a recovery which they completed. Upon trying to sign-in they are prompted with the message: This device was deauthorized. You will need to re-enter your Secret Key and sign in again. We have not encountered this before nor can we figure out how to re-authorize the device. The used does not have their original Secret Key.67Views0likes3Comments1Password for Windows app keeps requiring encryption key transfer
I have a business account that uses SSO for authentication. I am able to authenticate in the browser just fine and use the browser extension with no issues. When I sign in to the Windows app via SSO, I am asked to transfer the encryption key from my browser. I am able to do this successfully, but I keep having to transfer the key every day or two. Is there a way to prevent the encryption key transfer from happening or to get it to stop repeating?550Views1like8Comments