Not sure if this is new information or not, but this post mentions that Bitwarden is planning to support passkeys starting in 2023.
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.)
It's easy enough (not to belittle efforts that have done so) to store Passkeys in a password manager. The part that kills the flow and where it gets nefarious, though, is whether platform and browser players (Apple/Google/Microsoft/Mozilla) will allow 3rd party Passkey implementations to be selected/configured by the user as their preferred WebAuthN backend so that you can use your 3rd party implementation at login time when the website or app the user is using wants to begin a webauthn flow and lookup or create credentials.
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.
Shameless plug to my own passkey manager, which is 100% open source: https://bulwark.id
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.
The problem is that big companies don't want them to be as versatile. They don't trust us to manage our credentials.
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.
> 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.
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.
I really dislike the idea of giving complete access to my digital life to any company, particularly one that needs to grow quickly.
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.
There's still trust there. You're writing the key to decrypt everything into their web interface if you ever use it (vault.bitwarden.com). If they wanted, they could really get access to everything in your bitwarden vault.
Services like 1Password are often more secure than your solution because they need to harden vaults against full leaks. In the case of 1Password, a secret key in addition to the password ensures that brute forcing is (at the moment) not feasible, even if your password is really crappy.
LastPass would have also led their customers to believe that "brute forcing was not possible" and that they were taking extraordinary measures to keep vaults and data safe.
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.
But in the context of a strong master password, the additional benefit of the secret key is of neglible benefit, while the hassle and dangers of having to synchronise the secret key remain.
I'd rather use an extremely high entropy master password by itself.
So is LastPass, but we users changed our passwords in December anyway as a precaution. Bitwarden is still a central entity that needs to be trusted to manage the zero knowledge platform with competence, e.g. not storing unencrypted metadata in a backup.
Bitwarden can be self-hosted, it's fully open source so you can be safe that way, never giving a single byte to the company.
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?
I kind of want to point out the discrepancy in saying "I get syncing without sharing my data with anyone by sending my password database to Apple". If your argument is that the database is encrypted, how is Bitwarden different?
What this highlights in my humble opinion is that many users seek security signals and are less concerned with the actual security implementation. In the password management space, the signals are "local vault", and "not VC backed", at least on HN. It's quite odd since you'd think people would be more concerned with the application architecture, key derivation, key transport backup and recovery, etc. But it seems security is more synonymous with "company doesn't store my vault on their servers" than it is with "company helps me securely encrypt my passwords".
Slightly offtopic, but I really find the Bitwarden Clients to be lacking in the feature department. I switched to Bitwarden a few month ago and the client has evolved (for me) ever since.
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.
I agree, it's a little weird that some very basic quality of life features are missing from such a popular and relatively mature product.
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.
KeepassXC and/or strongbox have a very similar workflow to the older file based 1password one. I switched from 1password once they went to the centralized subscription model and I have been very happy with it for years now.
I tested Bitwarden recently and found the UX really disappointing. Some basic operations are so counter intuitive that I felt completely lost. This is definitely not the application I would recommend to non tech-savvy people. 1Password has much smoother UX.
Adding on to this. I've watched Bitwarden with interest, but I won't be moving to it anytime soon. Nor can I recommend it to others in good conscience since there's a basic UX issue that makes it easy to accidentally lose generated passwords.
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
> 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
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."
I just switched password managers from LastPass, and Bitwarden's lack of multiple accounts on their browser plugin was a dealbreaker for me. Such a basic feature, especially if they want to get widespread adoption. Otherwise, anyone whose work uses Bitwarden basically can't also use it for their personal stuff without jumping through hoops.
Aren’t you supposed to have your personal Bitwarden account and get work passwords shared to your account? I thought that’s how Bitwarden for organisations worked.
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. :-)
Could someone clarify what the relationship between passkeys and WebAuthn is? Is it that Passkey is the Apple, Google, Microsoft implementation (commercialization?) of WebAuthn? If so, does it add anything on top of WebAuthn that makes it differ in some fundamental way? Also, are passkeys how WebAuthn is most commonly actually used in practice? Apologies for the noob questions.
Passkeys is the "normal" name for a FIDO2/WebAuthn credential that basically lives within a phone or password manager. It does add a few things. Namely the ability to store many passkeys per device per app/site, the ability to sync those passkeys (e.g. via iCloud or similar), and the ability to use QR codes and Bluetooth to do a local-only authentication on a device which doesn't have the passkey (which is what often requires some proprietary implementation).
[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".
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).
> 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.
> WebAuthn is the short name for the "FIDO Alliance Web Authentication Protocol".
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.
Are Passkeys exportable and re-importable by another service, site, or system?
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.
Passkeys are effectively software security keys, stored in whatever keychain you're using (Chrome or iCloud Keychain or otherwise); for the major implementations you're hearing about, the goal of their implementation is improving the UX by syncing your passkeys between devices, so as long as you can access your passkey keychain, you won't have to worry about losing your security key for that website.
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.
Passkeys is what Apple decided to call their implementation and the benefits are within their ecosystem, such as storing these in your Keychain to be used on multiple devices.
it's just WebAuthn with an easier to understand name.
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.
Just recently tried to add WebAuthn to an app and was shocked at how complicated the spec is and how quirky the implementation ends up being. The biggest thing I couldn't easily figure out is how to use it properly. It seems like hybrid auth with your phone or FIDO gives you sign in, and local could be used for sessions? It's hard to make heads or tails from it.
The developer UX was also pretty bad, ArrayBuffers was a poor design choice for passing around what ultimately becomes JSON.
A passkey is just web authentication credential registered to have certain pre-existing capabilities so that you can have a particular user experience.
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.
We wrote a long post on Passkeys, in particular how they are implemented by Apple[0] that might be interesting.
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.
That's a great article, thanks. In fact, it's a fantastic article. I read it a couple of weeks ago, and learned a lot. Thanks.
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.
Can't help much but originally webauthn came from Fido2 and old Fido devices, like old yubikeys, which only supported U2F, were de facto compatible with webauthn (as in: webauthn was only an upgrade server side).
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.
Web Authentication works by having devices that provide authentication factors (authenticators), and providing APIs to register some authenticator with a website, or prove presence of a previous authenticator.
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.
Would have preferred to see the cash used for this to be used for things like app QoL improvements, an actual code audit (not just the basic network security assessments they list), or offer actual bounties for their bug 'bounty' program.
Wow this is really cool. I just tried the example on the homepage, that's magic! No email, username or password. Can someone explain what is happening?
On iOS this seems to use the iCloud Keychain which is slick but how would I then login to sites using Firefox or any computer that doesn’t have access to my keychain? The reason I use a 3rd party manager is precisely this reason.
Typically for web authentication the websites rely on the browsers which by default will back into the platform.
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.
Sites should likely let you enroll multiple such passkeys from different vendors (add a Microsoft Account passkey from your PC, a Google one from your Chromebook, etc).
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.
A new private-public key pair is generated, the public key is your user identifier (sort of), and the private key is stored on your device (browser or phone). You're logging in by proving you have the private key for the associated public key. I think the device may also be storing a mapping from key to service or something? Not sure.
From my loose skim, this seems to be more for UX than anything else: no-clicks account creation and no-clicks login, but there's still account creation and login happening, presumably with a key provided by BitWarden. But websites can start removing the login prompt as an entity to be interacted with.
Anyone know how Bitwarden fits into the "passwordless" equation here? I tried to log in to Dogwarden (shown in the video demo on passwordless.dev), but the Bitwarden extension/app doesn't seem to do anything during sign-up.
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?
My current setup uses Krypt.co (deprecated) to forward most U2F/FIDO2 requests to an app on my phone. The app has some keys stored in my phone's secure secret storage and verifies/signs the request (after unlocking my phone with biometrics or my phone's PIN). This signed response is then used to log into the website.
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.
Readit News
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.
[1] https://stytch.com/
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.
[1] https://syncthing.net/
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)
https://www.passwordless.dev/
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. :-)
https://listentothe.cloud/
[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:
https://developer.apple.com/passkeys/
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.
[0]https://www.slashid.dev/blog/passkeys-deepdive/
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?
1. https://www.amazon.com/gp/product/B0773YLSY5/
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.