That's great, since AFAIK all existing passkey implementations are tied to a specific browser or OS, and have no way to export the keys, which isn't great for a program designed to own the keys to your digital life. I'm hopeful Bitwarden will solve that problem, and that their example will encourage other popular password managers to do the same.
(...or at least, I think "passkey support" means they plan to support storing passkeys in Bitwarden itself. I hope it doesn't just mean they want to let you use a passkey to log in to Bitwarden. That'd be really disappointing, and probably a poor choice strategically given that passkeys aim to eventually render traditional password managers obsolete.)
Google said they plan to play nice and support 3rd party implementations. When I asked Apple during their Slack Q&A event on Passkeys they said that have no plans to support 3rd party implementations at the moment. I don't know how Microsoft and Mozilla feel. I would be a lot more optimistic about the whole thing if platform players would come out and commit to allowing 3rd party Passkey managers. Otherwise you'll never be an option in the system "choose which credential to use" dialog when some website/app wants to actually do webauthn.
One of the big challenges to passkeys right now is that they aren’t as versatile as passwords, but this doesn’t have to be the case. Passkeys should be able to be exported and stored anywhere you want (ideally in an open source solution). Bulwark Passkey supports that right now, but I’m glad that other products are also providing solutions to users for the same problem.
Hence FIDO2 and Passkeys feature 'attestation' that allows them to only accept 'trusted' implementations. This accreditation is a crypto process so it can't be faked.
So, you can't just put your keys in any app you wish, like you can with TOTP. There will be strong pressure to just 'go with the flow' eg mainstream OS implementations and us with niche OS or cross platform requirements will be ever more marginalized.
Any complaints will be simply rebuked with "For security reasons" or "We only certify implementation X, Y and Z".
My work is already doing this, they only support Yubikey and one other brand through their Identity Provider, if you have one of the open source tokens you're straight out of luck. Passkeys don't work yet either but I'm sure they will only 'certify' Apple and Microsoft and leave the rest hanging. They love quoting the pareto principle / 80/20 rule as an excuse.
It’s shaping up to be a cool year for password management!
1Password and Dashlane have both announced support for generating/using passkeys via their browser extensions.
It is a good thing that bitwarden is looking at this too.
Something that we're looking to solve at Stytch[1] from the developer's perspective. We're finding that the different platforms have their own twist on Passkeys implementation and all have different UX suggestions.
The tech for password vaults is so simple, I use keepass + icloud syncing and get free end-to-end encrypted password syncing, without sharing any data with anyone.
Outlined in more detail here: https://magoop.substack.com/p/how-to-manage-500-passwords-se...
It's not materially different than storing your KeePass vault in the cloud.
I think one distinction between services like KeePass and 1Password is end user perception of how easy it is for an attacker to acquire an encrypted vault to begin with. For many, they consider a KDBX database sitting in their Dropbox account to be less likely to be stolen than an encrypted vault being held by a company like 1Password, a high value target to the most sophisticated attackers including state actors.
On my devices, keyfiles and a KP client are stored locally. The DB rests in the cloud.
I'd rather use an extremely high entropy master password by itself.
https://apps.apple.com/us/app/strongbox-password-manager/id8...
Do you have a browser extension that offers username/password autofill using keepass as datasource or do you alttab copypaste / rely on a program made by someone else to clear your clipboard?
If apple gets too greedy with iCloud, you can sync your kdbx with 1000 other clients.
KeepassXC to be specific: https://keepassxc.org/
There are a few basic features missing, such as that if I search for something I wrote in the notes of password, that the client shows the according password. I get that the open-source model implies that everyone can contribute and fix this issue, but if I look at the repo and see 108 open PRs, I don't even bother to check if that's a feature that would be easy to add.
Folder management in particular seems to have been an afterthought. You create a subfolder by setting its name to its full path in the hierarchy, including all its parents. And thus, in order to rename a folder you have to manually go through every single subfolder and rename the particular parent in its name.
Other annoyances off the top of my head are things like the inability to change the type of a custom field from e.g. text to hidden without deleting it and creating a new field. Or the browser extension forgetting everything you just typed into the new item form (unless you remember to pop out the window) when pasting a generated password on the site you're trying to register to.
After switching from KeepassXC to Bitwarden for its better auto-fill detection and convenient synchronization, I can't help but feel that it's also been a downgrade in more ways than expected.
https://community.bitwarden.com/t/persistent-bitwarden-ui-an...
A recent response to this issue was that "it's a feature, not a bug". I've been waiting to see it added to their roadmap, but it's missing from the 2023 roadmap. So I guess I will have to wait another year
It might be that your search term is a partial of a word. This is fine when searching some fields, but for finding entries with that word in the notes section, the search term needs wildcards. You can read more about it here: https://bitwarden.com/help/searching-vault/
But to paraphrase: "notes: Item's notes. Only full-word matches will be listed unless you use wildcards."
Hope it helps.
1Password does, and is much easier to use (though I use both)
Anders Åberg (@andersaberg) who is the founder behind this is a really enthusiastic and inspiring coder. I've always enjoyed his mashup hackathon ideas and meetup presentations. :-)
[Edit]: An important feature of "Passkeys" is that browsers and operating systems have a special API that allows an app to pre-start a sign in with a known user/email/etc. which if there is a passkey for that user it'll automatically start the FaceID or similar confirmation process. Which Passkeys are checked is controlled by the OS/Password Manager which checks which website is asking and what username it's checking. This is just to make it so it seamlessly logs you in. It does a fall-back to just asking what your user is which is the initial workflow.
This[0] is a good podcast to listen to with Adam Langley from Google about how Chrome supports Passkeys and why they're a good thing. It includes the details of how/where/why there are some proprietary bits needed to implement "Passkeys".
[0]: https://securitycryptographywhatever.buzzsprout.com/1822302/...
FIDO Alliance Press Release https://fidoalliance.org/apple-google-and-microsoft-commit-t...
Chromium Blog on Passkey support (Dec 8, 22) https://blog.chromium.org/2022/12/introducing-passkeys-in-ch...
WebAuthn is the short name for the "FIDO Alliance Web Authentication Protocol".
"Passkey" is the trade name (that Apple tries to own) for the "stuff" that results from using the WebAuthn protocol. At it's root, a passkey is really the private key portion of that "stuff" that is kept. So yes, in practice, a passkey is the result of a WebAuthn implementation.
MS, Apple, and Google don't implement WebAuthn. Companies like mine do. Each website out there that wants to use passkeys needs to employ WebAuthn, whether via build or buy. What the "Big Three" do is leverage their OS's and platforms to enable the storage and migration of passkeys within their eco-system. WebAuthn is implemented in their browsers, and they enable the use of passkeys (which websites make happen via implementing WebAuthn).
One thing to note is that the Big Three also make a small adjustment to the WebAuthn protocol to allow passkeys to shared inside their cloud infrastructure. This every so slightly reduces the security of passkeys (which start out as very, very many orders of magnitude more secure than passwords).
You can read about Passkeys here: https://passage.id/post/a-look-at-passkeys
More on WebAuthn: https://passage.id/post/what-is-webauth
> Here are some guidelines for how to refer to passkeys in your apps and websites. "Passkey" is a generic, user-visible term. This video focuses on Apple's implementation, but as I've just shown you, other major platforms have already started building their own support for passkeys. "Passkey" is also a common noun, like "password." In English, this means it's lowercase and gets pluralized like "password" would. I have a passkey for my account, and I can go to Settings to view all of my accounts with passkeys.
Web Authentication is a standard from the W3C, with original contributions from FIDO Alliance and a lot of collaboration with members. It is very much not a FIDO standard.
FIDO has their own branding, marketing, and certification, as well as the CTAP protocol which builds on top of WebAuthn and describes how to communicate to an externalized authenticator (e.g. a USB or NFC security keyfob). They also work on several standardization efforts in other areas, such as IoT device onboarding and identity verification for documents.
> "Passkey" is the trade name (that Apple tries to own) for the "stuff" that results from using the WebAuthn protocol.
A passkey is a non-trademarked term (at least by Apple/Google/Microsoft) for a Web Authentication credential that has been registered with a site, that provides user verification, discoverability, and (optionally) backup eligibility characteristics.
In layperson terms, it is "a more secure alternative to a password" provided by their password manager. In particular, that security is strong phishing resistance as well as breach-resistance (e.g. greatly limits the impact of a copy of a website credential data dump)
> What the "Big Three" do is leverage their OS's and platforms to enable the storage and migration of passkeys within their eco-system. WebAuthn is implemented in their browsers, and they enable the use of passkeys (which websites make happen via implementing WebAuthn).
That was really helpful, I think that was the bit I was missing.
I am strongly opposed to any authentication system that makes my authorization workflow for unrelated third-party sites dependent on any company whose terms of service allow them to suspend or terminate my use without reasonable recourse or recovery.
Passwords have problems, but I can print them out on a piece of paper in a fire safe.
Or are MS+Google+Apple doing an "embrace, extend and extinguish" on webauthn?
Are the "small adjustements that ever so slightly reduces the security" sufficient to effectively kick security keys hardware vendor out of the game?
As for how "passwordless" plays into this, Passkeys are generally better than passwords simply because it's PGP instead of a shared secret you send to the website, so even if a website is compromised, there's effectively 0 way the compromised database will enable password stuffing attacks on other websites.
Another cool thing is QR codes via caBLE (cloud assisted BLE), you can scan a QR code on a browser (on a bluetooth-enabled computer) to have your phone connect to that computer and present its passkey to the computer, without needing to actually plug in your device to the computer. This is not strictly a passkey thing, it just aids in making them usable.
This page is a good starter:
However passkeys depends on a yet to be published standard for QR codes + bluetooth + websockets for doing WebAuthn from a second device. But that is planned to be published soon.
The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
Passkeys don't rely on this mechanism (although being able to authenticate your desktop using your cellphone is a very valuable user experience!)
This upcoming mechanism is also meant to be used between platforms (or at least, a platform and an extremely robust authenticator). It is not meant to be used by a website or native application which want to just rely upon/consume credentials. If the browser/platform supports this mechanism, it will be presented to the user as a choice of how to authenticate.
Technically a Passkey is just a multi-device FIDO credential that is compatible with WebAuthn (which is an official W3C and FIDO spec).
However, vendors implementations of Passkeys/FIDO credentials differ quite widely. The Apple implementation of Passkeys, as an example, doesn't provide attestation information which reduces the ability to do device verification. Similarly, even though it's not technically part of Passkeys, Apple removed the possibility to create device-bound WebAuthn keys which significantly weakens the security guarantees you'd normally get with WebAuthn.
Apple's changes do degrade security, but I think it is important to note that even with those degradations, Apple passkeys are still many orders of magnitude more secure than passwords.
Now Google killed U2F in Chrome (and hence Chromium etc.) but you can migrate your webserver to use webauthn instead of U2F and your users' old U2F keys shall keep working.
For the "new" webauthn, called passkeys, which is a modified webauthn: I've got no clue.
It's not clear to me if old hardware security keys shall keep working or if we'll all be forced to use software keys protected by Google/Apple/Microsoft.
The authenticators allow for this registration and proof via generated public key pairs. These key pairs along with other configuration are referred to as Web Authentication Credentials.
There are several modes you can request, such as user verification (perform an additional non-possession factor, such as prompting for a PIN or biometric). You can choose between a model where you challenge authenticators based on previous registration handles, or "ask into the void" if any authenticator thinks there's a valid credential registered for the site. That second mode is called a discoverable credential.
A passkey is a discoverable credentials which supports user verification.
The term isn't trademarked, and just is meant to describe 'a more secure alternative to passwords', but there are a minimal set of features supported. The hope is, like passwords, society will get to a point where we don't have to explain what a passkey is. Support is typically provided by the same software and integration as a password manager.
It doesn't require any capability which was not in Web Authentication Level 2, the prior spec. That said, the platform vendors appear to be taking a much more opinionated idea on how things should be used, and what sort of capabilities (and security posture) should be exposed via the authenticators exposed by their browsers/operating systems.
Most particularly, passkeys are expected to be backup-eligible - e.g. that there is some sort of back-end storage and recovery mechanism. This likely is tied to some sync fabric provided by the platform.
This provides a better user experience in many cases, and reduces the burden on websites to do account recovery (say, if you lose your security key or buy a new cellphone). An authenticator like a Yubikey 5 which supports the other features but does not support backups generates credentials called "single device passkeys" to distinguish this behavior.
Web Authentication Level 3 should eventually expose this backup information to websites, as it is likely a relying party will want to know that the user credential is somewhat 'robust' before they take any sort of migration step like offering to delete any password-based credentials previously used on an account.
In terms of how it is most commonly used - there is significant established usage of WebAuthn, which also supports the functionality of old U2F keys as second factors to a password-based login, such as on sites like Google and Github.
In terms of the 'usernameless and passwordless multi-factor' authentication provided by passkeys, it is expected that the commitment by Apple/Google/Microsoft to support this system will drive adoption, and that it will become the dominant mode of operation. This is all relatively new though - Apple and Google launched toward the end of last year with new backup-capable passkey implementations and new platform-level UX.
That said, the backup eligibility concerns more traditional organizations who are concerned about having Apple/Google/Microsoft clouds as part of their attack surface. The cloud synchronization means that it is debatable whether it meets their needs of considering the phone as a physical factor. And Apple at least offers the ability to 'share' passkeys with contacts over proximity wireless, which interferes with some regulatory requirements. A certain amount of evolution may be needed for them to accept a credential from an authenticator with these characteristics as a sole factor.
But any level of that may take responsibility - for instance, 1Password and Dashlane replace the browser/platform support by default by altering the implementation of the javascript API via their Web Extensions.
There are ramifications to this approach, such as having to fall back to the browser/platform UX to support hardware security keyfobs.
The platforms (and browsers using their API) also support or plan to support a cross-device option, where you should be able authenticate within a desktop browser using your cellphone via QR code and radio proximity checks. The vision is that some websites will see that the location browser _could_ have supported authentication directly, and offer to help the user register it as a second (more convenient) option.
Apple already supports Keychain sync with Edge on Windows and I believe that already supports Passkey access.
Also, I believe I heard rumor that "Sign in with Apple" (their existing OpenID Connect account system) will also eventually support helping you enroll non-Apple devices to Passkeys in apps that support both Passkeys and "Sign in with Apple", though I don't know if there is yet a timeframe on that sort of support.
Please correct me if I'm wrong on any of this.
Also wondering if anyone knows why this device [1] doesn't work during the "passwordless" sign-up/sign-in process on dogwarden1.passwordless.dev. Am I going to have to buy yet another hardware key if I want passwordless logins?
I believe the goal for Bitwarden would be the same, to allow for seamless login through a secondary device using WebAuthn and friends. Apple and Google are already working on cross-device FIDO2 login support, but for Firefox I haven't seen much announced as of yet. Bitwarden filling in for Apple's/Google's proprietary services would be a way to log in securely without giving up even more security features to browser companies.
However, I'm curious what y'all think about the cost. A digitalocean droplet for the recommended specs (4 GiB memory) is $24/month. This is hard to stomach when you compare with Bitwarden Premium which is <$1/month. I guess it depends on how much you value your own data.
DO inflates prices for their systems, sometimes I guess it’s worth it but you can get a great dedi with FAR better performance from Hetzner auctions for $32/mo. 64GB RAM, proper CPU, large HDD, could probably host a thousand Vaultwarden instances. Definitely don’t use that for just Vaultwarden, it’s just an example, but yeah.
discussed when it was announced: https://news.ycombinator.com/item?id=31098608
Pedantry aside, yeah that seems expensive given the amount of convenience offered. But much more convenient than setting up a server in your basement with a UPS and external backup drives and such.
It also seems like a way companies like Google would lock people into their browser.
The current legal climate is mixed but we have court cases that claim biometrics are not covered by the 4th and 5th. We also have the opposite. The reasoning being that producing biometrics is not testimonial. Until decided by the Supreme Court, I'll assume that anything that can be produced without my mind is not covered and that includes this.
I am not a lawyer and this is not legal advice.
You should be having third one - backup token stored securely in the safe or vault. That is $150 investment just to do it right.
And then - not all webapps allow to register more that one FIDO2 device, which totally cancels the above best practises.
Unlike TOTP, the base case for passkeys is multiple key enrollment so websites are more likely to support it well whereas with TOTP so many implement it as having one-and-only-one TOTP configured. Even when enrolling just a single device that device generally enrolls a small key-chain, not just a single key, because that's how recovery systems work even for using just a single "owner" account. Plus most people use 2 or more devices regularly and Passkey has to work with that. So much more websites in practice should actually support N passkeys where N > 1 (versus half-baked single-option-only TOTP implementations).
At least in theory, in practice we'll see how well Passkey gets implemented at large, there's always lots of ways for companies to get practice wrong.
Are Passkeys exportable and re-importable by another service, site, or system? As described above, if my Google Account is terminated by Google without recourse (which absolutely happens), do I lose access to all sites that I used solely a Google Account Passkey for once my phone stops working?
Theoretically, your Passkeys should still be on your iPhone/iPad/Mac/iThing, and QR authentication will work. (And then you provision another key on another device, since Passkeys' intention is like SSH keys, allowing multiple on a single account)
This is probably testable as it is. They sync to iCloud Keychain, as is my understanding anyway.
How are the rest of your passwords stored in iCloud Keychain when your account is hosed? Do you lose those or does it just turn off syncing? I'd imagine it turns off syncing but keeps the keychain around unless you delete the iCloud Account from the device. That's a whole different ballgame of potential bad decisions though.
I’d say we’re going to see polished libraries soon that will abstract all the details away, but services like this may help less experienced developers to quickly get secure auth working.
You have really good newer methods of auth. Instead of selling them as good MFA alternatives security vendors decided to replace passwords because that differentiates them more. But in reality, the layer of defense "what you know" should be complemented not replaced. A reduction in security being sold as a feature is dishonest and harmful.
The threat surface of a passkey based solution is like a small puddle after a rain.
How is there a "reduction" in security here?
2FA>1FA
Or more correctly: I got so far but stopped because I prefer to have my keychain locally :)
Currently, if you use an iPhone, you will have the passkey stored in iCloud keychain. Your "account" is a private key held within iCloud keychain, along with some metadata mapping that private key to the site you visited.
Anyway this really needs to be exportable, otherwise its in the ultimate platform lock.
[0] https://github.com/FiloSottile/passage [1] https://passwordstore.org
Granted this is Bitwarden acquiring rather than being acquired, but I still worry it leads to a trend of building "portfolio value" rather than focusing on the product. I sincerely hope I'm wrong.
I do worry about VC pressure on Bitwarden for hypergrowth. However in my personal opinion, the benefits outweigh the cons (for now).
Vaultwarden is much easier to set up and manage, I use it myself, and I heard that the official build is a little bit more tedious to go with.
Vaultwarden is a compatible but 3rd party software.
What's a good OSS alternative that works with iOS and Linux? Anything that's audited? (perhaps that's asking for too much)
I wasn’t aware of this, but I’m glad I am now. If that’s the case it’s time to look elsewhere or self host, VC funds and acquisitions are rarely good for users so I’ll assume the worst.
https://github.com/dani-garcia/vaultwarden
Though I fear it’s only a matter of time before the VC gods demand the client apps remove compatibility and they have to be forked too.
OTOH I wouldn't want to self-host because I know I'm not going to spend the same amount of time and effort a full security staff would, even if my self-hosted box would make a much less attractive target.
It's quite a pickle.
There are decent apps for android and iOS (eg Strongbox)
I’m going to migrate off 1Password to it soon
If someone creates new tech and it fits with Bitwarden then I'm more than happy to see what they can do together.
It is now growth at all costs until an eventual acquisition of Bitwarden. So I won't be surprised to see price increases on some plans soon.
[0] https://bitwarden.com/blog/accelerating-value-for-bitwarden-...
I can say with certainty that I’ve continued to get value out of 1Password both personally and professionally. I can even say with a degree of certainty that I’ve gotten value out of the changes that have come post-acquisition. Were I starting from scratch, I’d still probably pick 1Password. This isn’t me arguing that 1Password is better. More saying that it’s been a…little bit of time now, and I’m still happy with the product and how it’s improved.
I appreciate that acquisitions or taking on funding feels like more of a kick in the teeth because it’s a distinct event, is publicised, and even publicised as a good thing. Having just gone through my first acquisition (as an employee in an entirely bootstrapped small business) I’ve realised that this has to be weighed up against the risks associated with whatever was in the no-funding no-acquisition future, i.e. the thing just going away entirely, which happens slowly (and then all at once) and mostly in private.
I’ve little doubt that over time 1Password will get comparatively worse than whatever else is around. Either because it’s neglected or because it gets juiced and dark patterned by VC incentives. Ignoring the VC bit, I’m just as sure the same will still happen to Bitwarden obviously. But this shifting playing field just feels like an inevitability regardless of which path any product takes.
Some keepass compatible apps even offer full iOS integration (FaceTime unlock, Password AutoFill), so you don't lose these features you're used to with LastPass.
No autocomplete on username, slow initial load, search function is sticky on desktop client but not on the rest. No way to easily add folders or reorganise multiple items.
I won't renew my subscription, not that they care anymore
There are multiple users who, post-breach, are checking the Iteration Count the number of PBKDF2 iterations for their vault, and discovering that even though LastPass had been slowly increasing the number of iterations for new customers in line with industry best practices, they were never going back and upgrading the old users. So if you created a LastPass account in the past few years, your iteration count was 100,000. But if you were an older user, it may have only been 5,000. Or 500. Or, in the case of many old users: 1. One iteration. That's all that was protecting their encrypted vault--now in the hands of attackers--from brute forcing.
Chrome's password manager is pushing it.
Everything else should be considered malware.
I don't understand how such a 'techy' crowd here on HN can be so belligerent with this security vs convenience trade off.
KeePass locally, gmail yourself an encrypted backup. That's it. FFS.
I know my blob is encrypted, because I did it. Did you audit your password manager's source control? No?
That is the difference.
For a technical person I would advise a better solution, but the reason these solutions are being pushed is for widespread adoption of better password practices.
>If
And, if you get infected, it is all moot anyway.
