Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
downgrading family account to individual
i've subscribed 1 year family after my 1 year individual one has ended, i was going to share with my friend but things didn't go well so i wanna ask if it's possible to downgrade the subscription to individual ? and if so is it possible to refund the difference of price ? i should mention that i have subscribed through app store (IOS)
1Password 'Environments' and monorepos/collocated deployment configuration
I'm fiddling with Environments today to see how it would work for my workflows, and immediately ran into two fairly significant blockers: ## Multi-environment orchestration The only way I can see to get an environment-ID into an `op run` command is as a flag/env-var pre-dispatch; but for something like Ansible, where an entire inventory of tasks require a complex mapping of projects/apps/secrets/teams, that would require centralizing all of the "environment IDs" into one top-level invocation, irrespective of what actual tasks the given Ansible command might run. (This isn't Ansible-specific, "ansible" here could be any complicated orchestration tool that makes intelligent decisions about what to do for multiple potential environments.) Yes, I'm sure the blessed path, or what would be ideal for 1P, is that each possible orchestration tool in existence use the 1P SDK, have a built-in, or a plugin, or something like that, so that 1P is separately queried for each target/environment - but there will always be *some* tool that doesn't (up to an ad-nauseum target of "all of our deployment is bespoke by scripting.") At the moment, this situation is still better served by the previously-extant `op://` references in static env-files: they're "discoverable" during the process, in that anything/everything present in the environment is substituted at launch-time; but that's also worse in its own way - they're less isolated, and it leaves a similar "collect all the environment for all possible targets first, before executing the orchestrator." I don't necessarily have a specific feature-request or a way I imagine this working, right now; I just wanted to surface the annoyance for you to consider as you're working on the feature. (Related issue, similar vein, but not exactly the same architectural problem - there's only one `OP_ENVIRONMENT_ID` env-var; and while the `op run` can take multiple environment-flags, that's again a single-point-of-invocation issue. Ways to construct partial environment-based assignments pre-invocation is missing here, unless you store them manually and construct some method of passing them to `op run` - i.e. there's no equivalent of `op://` references, where multiple different scripts and wrappers can all happily contribute multiple `op://` references into the environment without coordinating, and one final `op run` can consume/resolve all of them for some sort of commit/apply process.) ## Duplication of secrets This one is the much bigger one, and kinda a dealbreaker, at least for me. For basically any given secret, I *already* have a central, authoritative 1Password entry as the source-of-truth for that - it has version-history, shared notes, access permissions for people, it autofills browsers and logins and CLI invocations ... but at the moment, "1Password Environments" only allows me to put in 'dumb strings' as variable-values. Which means that I need to, say, *duplicate* a database-user password in both 1. a 1Password vault-entry, and 2. a 1Password environment-variable. (... and then document somewhere that it's been duplicated; and establish process to make sure anybody modifying it knows to go modify both; and, and, and ...) I assumed when starting this out that the entire point of 1Password environments would be, effectively, something like a templating system: include, inline in the definitions, the equivalent of `op://` references to other *existing* secrets, such that they're filled in when actualized onto the filesystem or requested from SDK apps. (Think, "username" and "password" are already in a database vault-entry; so the `DATABASE_URL` env-var configures how to construct the database-url from those keys.) Without that functionality, I'm actually a little lost as to the value/purpose of environments (not to criticize anyone's hard work, or anything; I'm sure there's a pictured use-case that makes sense, I'm just not currently managing to see it, haha.) So, the request here is a little more direct: let me configure references to other 1Password items in environment-variables - at a minimum as a 1:1 correlation (i.e. `DB_USER` being configured directly to `op://Team Secrets/Database - Prod/Postgres/username`); but ideally, with some minimal templating, so additional content/simple structure can be hardcoded into the env-vars that are *mostly* derived from secrets (Postgres connection-strings/URLs; or derivation from other env-vars to avoid duplication on that end either, such as configuring `USER_PW` to `op://Team Secrets/${HOSTNAME}/password`.) Hope this is helpful feeback about the issues somebody ran into in the real-world trying to apply this! I *do* love the promise of ditching env-files-full-of-`op://`-references-hardcoded-into-repos, in favour of something more auditable / sited-with-the-secrets-in-question / dynamically-configurable.
1Password can't open your saved data - Desktop (Windows)
Hello! Does anyone know what could be the cause of this? Error message: 1Password can't open your saved data, however, your data is still safe in your account. Contact support@1password.com for help Desktop Windows version running on 8.12.10.0
Feature Request: Display Vault Name on Each Item
Hi 1Password Team, I’d love to suggest a small but very helpful UI improvement: showing the vault name as a subtle label on each login item (for example, in the top-right corner of the item view). When managing multiple vaults, it can become unclear which item belongs to which vault—especially when reviewing or moving logins, passwords, or other entries between vaults, collections, or folders. Having the vault name visible at a glance would make organization and bulk management much faster and less error-prone. A lightweight, unobtrusive label would be enough, just something consistently visible without needing extra clicks. Thanks for considering this improvement!
op.exe considered harmful?
I’d like to raise a point about the current security model of op.exe, and how it affects protection against supply-chain or similar attacks. Consider a scenario where an attacker manages to execute malicious code locally, for example, via a compromised Python package. While this is often considered “game over,” in practice we still want to avoid being the easiest target in such situations. A common behavior of malicious payloads is to harvest local secrets. While 1Password provides some protection against direct file access, an attacker can simply invoke op.exe, which actually centralizes access to clear-text secrets in a very convenient way. Although op.exe prompts the user for permission, my understanding is that this permission applies broadly (e.g., to the entire account for a period such as 10 minutes). As a user, I can see which application is requesting access, but not which vaults or items are being queried. In practice, the application name (e.g., WindowsTerminal) is not very helpful in determining whether the request is legitimate. I’d be interested in others’ perspectives on this. Some potential improvements that seem valuable to me: When requesting permission, op.exe should provide more context (e.g., which vaults and items are being accessed). Users should be able to grant permissions at a finer granularity: not just account-wide, but limited to specific vaults or even individual items. Another useful feature would be the ability to mark certain items or vaults as excluded from programmatic access (via op.exe, and possibly browser extensions). Even better, this could be the default behavior, requiring explicit opt-in at the item level. I understand that such restrictions would be enforced client-side and therefore not fully robust. However, they would still meaningfully increase the effort required for a malicious local process to enumerate and exfiltrate secrets, and thus provide practical security benefits. Finally, it might be worth considering stronger protections at the vault level—for example, requiring explicit user authentication (master password, or even a separate password) before allowing access to secrets. This could apply not only to op.exe, but also to the interactive 1Password client.I would like EPM with my SOC workflow for Oauth. Looking forward to SCIM improvements for SecOps.
Didn't understand half of what the blog post went over b/c i had to remember so many acronymns. https://1password.com/blog/automating-soc-workflows-with-1password-enterprise-password-manager Look at what is happening in society. People are live streaming implementations of openclaw and exposing their tokens. OPENCLAW DEMO THAT YOU NEED TO WATCH. I TIMESTAMPED IT SO U GO TO GOOD PART
