Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Enable DNSSEC
1Password domain names are not signed with DNSSEC (at least 1password.com and 1password.eu). Customers are therefore potentially vulnerable to MITM attack. This means that when attempting to access the password manager's online services, an attacker could falsify DNS resolution responses and redirect the client to a fake server. https://internet.nl/site/my.1password.com/3801661 https://internet.nl/site/my.1password.eu/3801663 In addition to the absence of DNSSEC, these links will inform you that certain best practices are missing from your web server configuration.
1password dpkg package should stop creating 1password.list
When installing the 1password .deb file, the post-install script automatically creates a file at /etc/apt/sources.list.d/1password.list. This is irritating and is bad behaviour. Point one: the user did not ask for this file to be created. If you're going to create it, at least ask users if they want it. Point two: I create and manage my sources files centrally; I do this for my personal systems, and I've always done this when I'm managing a fleet of computers. I create names that make sense to me and have the correct details. Unfortunately, every time I update 1password it re-creates `1password.list` and then apt breaks because I now have two files pointing at the same apt repository - yours and mine. Point three: I use the new deb822 .sources file format, because this allows me to keep the Apt configuration and the GPG key in the same file, meaning I only have one file to manage. This makes it easier to manage things centrally, and helps keep from scattering GPG keys all over the servers. 1password needs to either: Just stop doing it (give people instructions like every other website does) Make it optional via e.g. a debconf setting (which the application could theoretically have a UI for, even, if you wanted to get crazy with it) Make the file part of the actual package contents so that admins can dpkg-divert it In the meantime, I created a symlink pointing 1password.list to /dev/null; apt still complains about it but at least nothing breaks.Bi-Directional item linking
Hey, Any updates on bi-directional item linking? Eg, if you link Item A to Item B, then Item B is automatically linked to Item A? It's perfect for a Passport item, you have all the details in there, then you have an attached item with the photo image, you link one to the other, you expect a link back. A login to the NHS, would be nice to link it to a GHIC card item, and to a Patient Access item and to another medical item etc so you can easily jump to similar items that you may need when using one of those. I've suggested this many many years ago (on the old forum). Any sign of it? I do recall a dev saying way back then that it was in the works. Surely it can't take this long? If it's not in the works then why was I told?Android browser whitelisting?
I currently use the Waterfox browser on Android because mainline Firefox is moving in a direction that I don't like (to put it mildly) and while it's mostly fine 1Password doesn't like autofilling in it. Is there a possibility to add the ability of whitelisting custom browsers on Android like on desktops? Or is it possible for Waterfox to be whitelisted?
Fastmail Masked Email feature request
Hello 1Password Team - Could you please add the ability to specify a custom prefix when creating a masked email address in Fastmail? Their API supports it. I like to use prefixes on my aliases since it helps group the type of sender or service (financial, shopping, apps, etc.) to have rules that can label, archive, forward, etc. and would love to specify a prefix during masked email creation. This could alleviate the alternative of using catch all aliases. It would also be a big time saver if you could add creating the masked email addresses to the iOS app. Thank you!
Feature Request: GeneratorRecipe for Memorable Passwords
Currently in the API options for 1P Connect there is an ability to specify a "GeneratorRecipe" when creating a password for a record: https://developer.1password.com/docs/connect/api-reference/#item-generatorrecipe-object This is great for super-high-entropy random passwords but in some instances we would like to have the ability to specify that the generator create a "Memorable Password", as can be done in the 1P apps: Ideally this would then allow for specifying criteria similar to: "generate": true, "memorableRecipe": { "memorableRequirements": [ "HYPHENS", "CAPITALIZE", "FULLWORDS" ], "words": 4 } While this isn't needed all the time as the default 'generate' option is suitable in most scenarios, this would provide some extra flexibility. PS - In the same vein, it would nice to have this capability for the CLI's '--generate-password' option as well!! https://developer.1password.com/docs/cli/item-create/#create-an-item
Password generator when exporting ssh keys
It would be nice to integrate the password generator when exporting ssh keys to create a random passphrase saved in the key entry in 1Password. The workflow for this is clunky currently as I create a new password field in the entry with a randomly generated password and then use that as the passphrase when exporting the key. Now, when the key is exported 1 password saves an entry of the passphrase used to export the key. Now I’ve got two entries for the same phrase. it would be a much simpler flow if the passphrase could be randomly generated inside the export key dialogue instead.What is an Agent Chassis?
Jeff Malnick’s post is confident. It’s also detached from how developers actually ship code today and made me furious.“Agent chassis” boils down to: the script that runs your agent. Fine. But the security layer argument collapses when the tooling underneath is fragmented.Right now you pick between CLI, shell plugins, service accounts, connectors, environments — each with different auth models, rate limits, edge cases, and silent failures. None cleanly support a headless agent workflow. I’ve built workarounds for my workarounds.Agentic coding made this obvious. Agents need real credentials at runtime. Not desktop popups. Not biometric prompts in a terminal.The community built unofficial MCP servers. Anthropic shipped 50+ connectors. 1Password isn’t there.The spec is public. It’s buildable. So—who’s shipping it?
Automated bi-directional sync between 1Password and AWS Secrets Manager — is this actually possible?
Hey everyone, SRE at a small startup here. We've been using 1Password for a while and overall love it, but we're running into a friction point with our AWS setup that I'm hoping someone has solved. What we're trying to achieve: We want a proper bidirectional sync between 1Password vaults and AWS Secrets Manager. Specifically: 1Password → AWS SM: When someone on the team updates a credential in 1Password, it should automatically propagate to AWS Secrets Manager so our workloads pick it up without anyone having to manually copy-paste things. AWS SM → 1Password: We use AWS Secrets Manager's native auto-rotation for some credentials (RDS passwords, API keys, etc.). When AWS rotates a secret automatically, we'd want that updated value to flow back into 1Password so our employees can always go to 1Password as the single source of truth and get the current credential. On the new "Environments" feature (beta): We noticed the new Environments feature and got excited — it looked like exactly what we needed. But after digging in, it seems pretty limited right now. From what we can tell: There's no SDK support for managing environments programmatically There's no CLI support either (`op` doesn't seem to have environment management commands yet) Everything has to be done through the UI wizard This makes it really hard to automate. We provision new environments dynamically as part of our infrastructure-as-code workflows (Terraform), so we need to be able to create and configure environments programmatically. Is this on the roadmap? Are there any workarounds people are using? The SAML IdP requirement in Environments: Related to the above — the Environments setup wizard seems to require a SAML Identity Provider to be configured for each environment. We use Azure Entra ID as our IdP (federated through AWS Cognito), and we have a single IdP setup that covers all our environments. Is it actually required to have a separate SAML IdP per environment, or is there a way to reuse a single IdP across multiple environments? The wizard flow makes it seem like each environment needs its own IdP configuration, which would be a significant blocker for us — we can't dynamically spin up new IdP configurations every time someone creates a new environment in our platform. If this is a hard requirement, it basically rules out Environments for our use case entirely, since we'd need to automate IdP provisioning as part of environment creation, which is a whole other can of worms. Summary of questions: Has anyone built a reliable bidirectional 1Password ↔ AWS Secrets Manager sync? Especially the AWS SM → 1Password direction for auto-rotated secrets? Is there any programmatic/API access for Environments (SDK, CLI, REST API) that isn't documented yet, or is it genuinely UI-only right now? Is a separate SAML IdP per environment actually required, or can you reuse one IdP across environments? Thanks!
