1Password's company blog covers product news on passkeys, virtual cards, SSH integration, and the security design of its password manager.
HN commenters link it for explanations of the Secret Key, NIST password guidelines, and FIDO and passkey plans, often with 1Password staff replying.
I use and generally recommend 1password. I've used it on every major mobile and desktop OS browser. (I've had some issues on Android, but it was not a standard Android OS.) The UX is generally nice.
First, they encrypt with the secret key AND the master password. This is the most important thing, and I was shocked to learn Lastpass doesn't do it.
Second, the master password runs through PBKDF2 with 100000 rounds, but a precursory Google search suggests the very earliest versions used around 10000. Lastpass's problem was a low 5000 rounds, and did not update the number of rounds. I don't know if 1password updates the number of rounds.
Third, they use a zero-knowledge proof protocol called "secure remote password". When I was sharp in cryptography, this is what made me choose 1password over the others. I don't understand all the details anymore, and I don't know if it is "post-quantum secure."
Fourth, the UX is nice and I can recommend it to anybody who is literate. (This is not a cynical take-- I don't know how good the UX is for someone who is not fluent in a language 1password uses.) (Also, 1password recently released "1password 8", a new UI. I have not tried it and cannot speak to it.)
Fifth, 1password's biggest (only?) controversy was moving to a subscription model. I actually prefer this. (I want devs to be paid in perpetuity to keep this secure! I assume 1password has security holes somewhere, and I want 1password to pay their folks to find them…
I love 1password's "Show in Large Type" feature, which shows your password in a large monospace font with symbols and numbers clearly differentiated. Makes it super easy to see and type on another device (like when you have it open on your phone and use it to log in on another computer). https://blog.1password.com/posts/2018/b5x1.10/large-type.png
Small touches like that are awesome, and why I'm happy to pay for 1password over the OS or browser password managers or competitors like Bitwarden.
-----
For my company's support team, they often had to reset customer passwords over the phone (I know, how archaic). I copied that 1password look and then added the NATO phonetic alphabet below each letter / number so they can easily read the entire password out loud (like "whiskey tango foxtrot delta zero zero delta"). Last I heard, that one tiny tweak (which took twenty minutes to add) ended up saving them hours on the phone each day just by preventing a bunch of misspoken/misheard passwords.
> The only way passkeys make sense is in terms of vendor lock in.
This is what I've figured as well, and even if my password manager claims "eventually we'll support it, once it's available" (https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/), I've been putting it off until the implementation is actually in place.
But the question is when that'll be. Last I've heard about the whole "Risk of lock-in from export blocking" is:
> The general vibe is supportive and language has been added to this effect, though it looks like we haven't done a public working draft in some time so I don't think that's externally visible yet. Also usual caveats about in-progress work subject to change.
https://github.com/fido-alliance/credential-exchange-feedback/issues/24#issuecomment-2905416990
I guess time will tell. But for now, considering the history of lock-in on the web, it's best to stay away from Passkeys for now, until they figure out a proper way of avoiding it.
Not just "most passkey stores". The spec has nothing about export/sync, so they've been working around it by hand.
There is a process of drafting a decision to put before the committee to change this ~now[1], but tbh I think the omission from v1 is a strong sign that the omission is literally intentional. I'm sure spec authors will disagree, as I am sure that many are well-meaning... but there are very strong incentives for the current giga-corps to impede and complicate it during design phases, as they are now doing to the UX. If backups and device-loss considerations for such intensely personal data is not baked in, simply, and mandated from day 1, it's intentional by someone.
[1]: https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/
Import and export of passkeys is coming "soon" to 1Password (as of October): https://blog.1password.com/fido-alliance-import-export-passkeys-draft-specs/
I think some vendors do have intentions of locking in users with passkeys (*cough* Apple *cough*), but I also think it's also not the only explanation for why import and export isn't supported by most managers.
A more charitable explanation would be that since passkeys are 'new', there's less people demanding import/export since they have very few passkeys to move around, and at least some vendors wanted to take time to develop a good solution for it / focus resources on actually getting the daily usage of passkeys working.
> And Apple does the same with Safari and their password manager.
No, they don't. Apple vends an API to allow third party password managers to hook into Safari and other apps to save and provide passkeys.
I use 1Password on Windows and iPhone to use my passkeys between Firefox, Chrome, and Safari.
https://developer.apple.com/passkeys/
https://developer.apple.com/documentation/authenticationservices
Looks like Chrome on Android has flagged support for this (not enabled by default) so presumably thats coming soon as well.
https://blog.1password.com/save-use-passkeys-android/
https://1password.community/discussion/143903/how-do-i-use-passkeys-in-google-chrome-on-android