I tried searching for this but I can’t find anything.
Just wondering if there is a mechanism, is going to be a mechanism, or could be a mechanism to mass convert passwords to passkeys in bulk?
How it would/could work is that participating websites could offer an API, maybe through an web form made in a particular format, which would let password managers like bitwarden connect onto it, automatically put in the username/password, then respond with the passkey, which would then be saved to the vault and the password invalidated on the server side (maybe kept for reference purpose in the password manager as an option).
There could be various reference implementations to make it easy for web developers to implement or included in popular software.
so if someone suffers from a password breach or just has bad passwords, they can just click a button in bitwarden and it will just go ahead and convert as many passwords to passkeys as possible to make those accounts secured without having to click through every single website and find all the menu options to change the password.
Passwords are user-created strings of characters, whereas passkeys are system-generated cryptographic keys, with public and a private key pair linked to a particular site, and not every site accepts passkeys yet, but they all do accept passwords.
I fail to see but I most be missing something, how do you envision this?
As I understand it, this requires each service to provide a public API that accepts username and password, returning a passkey as the result. However, since most services providing passkeys also support 2FA, those need to be transferred, too.
Exactly, “yet”. This is more of a future proofing for when Passkeys are more widespread.
As websites start moving to passkey more and more, adding an extra .PHP file or (whatever language it is) to enable predictable/API password to passkey transition at the same time, would become more useful as the transition continues.
Presumably, the most security conscious websites will move over first so there is a good bias there that at least most important websites would probably be automatable soon.
(Banks and other big incumbents seem to be in a world of their own)
I fail to see but I most be missing something, how do you envision this?
explained at the end.
As I understand it
Correct
most services providing passkeys also support 2FA, those need to be transferred, to.
That should be considered as well. There should be a provision to pass through a custom sign in page.
The way I’d imagine it working is like:
Extension looks through vault and collect URLs and check to database to see if feature is supported. Say there are 10 migrations possible.
Predictable fields to ensure auto fill works (including default preference to retain password method for that site as well if they want both, or not) across ever site which has implemented it
User signs in and completes extra prompts
Passkey returned to browser and saved to password manager, and synced for safe keeping
Password manager response to website that passkey is saved successfully
Website confirms receiving that response and deletes the password on their end if that was selected and then tells the extension that the process is complete
Extension then loads up the next site starting from Step 2 and repeats until complete.
So even if not fully automated it would be heavily streamlined and mostly using existing technologies.
Caviets:
the site URL might be stored inconsistently between sites. I.e. www.example.com vs example.com might need some smarts to take the root URL and use example.com/passkeymigrate every time and if a website doesn’t use naked domain for some reason then that’s their problem or maybe a TXT record could be used. i.e. _passkeymigrate.example.com to point to the correct URL for their service and being able to set some kind of policy for if logins are handled on a subdomain level.
Security risk of hijacking legitimate websites (DNS poison/hacking/re-registration of lapsed domain) where a malicious website of the correct URL could use the form to take in the real credentials and replace it with a fake passkey. It’s the same risk as it already is really. Password manager should still keep the invalid password just for record keeping just in case. If there was a way to improve SSL certificate checking that is also good but that is really a browser problem. I don’t think it is much risk really
Bigger risk is that a hacker who has managed to steal someone’s password vault or common password is going to have a much easier time to be able to rapidly go through that vault to change all their passwords. I don’t think much can be done. Even other password managers could bypass rate limits and no rate limit across different sites. Maybe recommend a captcha be included on the migrate page for custom auth. But that is the risk of using passwords really and the whole point to upgrade to passkey. If they already upgrade to passkey they would not have this risk and infact making it easier to migrate to passkey in itself will reduce risk
Unexplored problem of potential passkey renewals to a new passkey if vault is compromised but might work similar
And how would this database come together? I think that is the big question, as Bitwarden users are spread all over the world and thus that database must contain millions and millions of sites. A nice plan if it works but the implementation without the help of Google / Microsoft etc etc seems impossible to me.
I am leaning towards the idea of a TXT DNS records doing the heavy lifting in some way.
For example, the extension checks the URLs and then does DNS lookups (existing worldwide distributed system to look up records which is already in the control of the website owner) to see if the feature is supported and if so what the authorised/official passkeymigration url is as well.
I’m not sure of the engineering implications of looking up a heap of dns record directly from an extension is
But it would be relatively simple to look up the DNS records through a trusted web service middleman (i.e. the same vendor as the password manager itself or an existing trusted DOH service like CloudFlare if it supports txt) which could also do caching of results to reduce load on direct DNS queries
Note: I just changed the title fromAutomatic Passkeys Migration?toAutomatic Migration from Passwords to Passkeys? to make it more clear. (as passkey migration itself is mostly associated with migrating passkeys from one passkey provider to another)
PS: Also added “(Bulk)” to the title, as that was OPs suggestion.
User intent and User verification will get in the way. Both are part of the Passkey standard and are very likely be required at registration time.
User intent (also referred to as User Authorization or UA) is requiring some gesture by the human to validate that they are aware that the activity is happening and that they want the activity to happen. “Register for passkey” and “Save passkey in vault” buttons are an example of UA.
User verification (UV) is requiring some level of assurance that the user using the passkey is the same one that registered it. Biometrics and pins are commonly used for this. If a website ever wants to do UV at login, also doing so at signup is a de facto prerequisite.
In short, I suspect the most streamlined passkey signup could be is three steps:
Click “register for passkey” on the website. To demonstrate intent to it.
Click “save passkey” on the vault to demonstrate intent to the vault.
Smile for the camera to enroll in user verification.
There do exist password managers that have attempted to implement bulk-changing of passwords, but due to lack of a formal standard API, my experience was 45% successful change, 45% failure to update credential and 10% loss of credential. That was not good enough for me.
This is a big ask. Currently, it is not even possible for password managers to automate a password change, even though there is a draft standard (not widely adopted) for directing a browser to the password change form for a site.
I have noticed this limitation of bulk changing password to password as well.
But at the same time, this is also a new opportunity:
Websites are already being gradually retrofitted to support Passkeys, it would barely be any more extra work, considering that HTML forms are so basic as it is and if we did it, there would be a heap of reference implementations to quickly integrate wit.
If we could at least get a prototype running, maybe more work could be done to then potentially get it included as part of the Passkey standard itself, as a requirement to be considered fully implemented?
At some point, there is going to be an industry desire to start phasing out passwords altogether anyway. Like the end of Windows XP was such a huge shift. If we get the technology for it out now, then we would not only be ready for it, but bring that shift on sooner by making that option viable. Password breaches will keep happening and at some point the industry will have enough, especially because PassKeys are more viable to replace them completely (with migration method).
Per previous point, unlike Password → Password, Password → Passkey is basically inevitable. It is going to happen one day. An implementation simply has to be made anyway, sooner or later.
Any website which takes security seriously enough to even offer passkeys would do it. They were proactive enough to already implement passkeys, going one little step further to put up a web form and a DNS record isn’t really that much. The hard part is integrating that web form to the same format their website/database already uses. But they already got far enough to do the passkeys themselves, I’m sure they know enough to make one extra form with standardised field labels. (or maybe vibe code it, lol)
What is even the point of a passkey is the password can still be used as well acting as the weakest link
fairly common that despite having access to a password manager which can generate random passwords, users just use the same old password anyway and stick that into the password manager, especially if they have imported from another browser and started recording sites with passwords already manually set, and it is a massive job to change passwords on so many websites. This is a real problem out there, this is a good excuse to solve two problems at once to make up the failure of Password → Password not being done properly previously.
Basically, let’s give it another go with this even better solution, and try even harder this time.
I am open to the possibility that this same implementation could also support Password → Password changeovers at the same time, for websites that don’t want to go to the engineering trouble of fully implementing passkeys. I could tolerate changing to a super secure password which is locked from the user changing it to something weaker and it and is guaranteed to be unique. I think that this is actually called a “Personal Access Token” so technically it would be a Password → Personal Access Token migration. My only concern with this is that it would undermine the use of Passkeys and encourage lazy web developers to take the easy option. So I’d rather not.
And it really is just that. They suggest https://example.com/.well-known/change-password as the URL. No mention of how you prove your identity, no mention of what the field name for the new password should be, etc. The spec is so wide open that a custom function would be needed for pretty much each website, which is not much different from why historical “bullk change” efforts have failed.
But this is exactly the point. If there was a standard to how the login forms would function in a consistent way, then it be predictable to an autofill to be able to work reliably 100% of the time, rather than playing guessing games.
A long, unique (not used elsewhere) and randomly generated password that is never used is not really a weak link.
For those places that I use passkeys, I will not get rid of the password because my trust in passkeys is such that I want a recovery mechanism. A password can serve that role. The trick is that you need to create a new, long-unique-random password and stash it in your vault without ever using it, other than perhaps to test it immediately after change.
Done carefully, the attack vectors against a “never used” password are nearly identical to the attack vectors against the corresponding passkey. I say nearly becuase we can not know how the server protects itself against password-database theft.
This is presumptive that he everyone already has secure passwords (i.e. used the BitWarden password generator, or already changed them all). You probably won’t have a weak link, but others will.
That is fair and I am the same, only because it is so new. Like you, all my passwords have already been made secure. But it was a slog when I did that years ago.
Yes what an excellent idea. rather than it simply being a “Password to Passkey migration” it would be a “Password to Passkey with PAT fallback migration”
The PAT (Personal Access Token) as I mentioned before simply means that it is a system generated password which the user can’t change as not to be able to weaken their own security.
In implementation, it means that it acts just like a password.
So the automatic migration flow should also include doing a “password change” from the old password to the PAT as well as doing the Passkey.
The PAT could be in the format of pat_<6 random dictionary words separated by random special characters between 40 to 90 characters long> which should be secure enough, typable if needed
How it would/could work is that participating websites could offer an API, maybe through an web form made in a particular format, which would let password managers like bitwarden connect onto it, automatically put in the username/password, then respond with the passkey, which would then be saved to the vault and the password invalidated on the server side (maybe kept for reference purpose in the password manager as an option).
I like to add that the RP(website or app) doesn’t respond with the passkey - bitwarden or any credential manager always creates the passkey for security reasons to not send the private key over the internet during registration.
I do like the concept of creating a standard API that allow a credential Manager to automatically probe / ask a web service if it supports passkeys and if it does then ask if it has the username. The web service responds back with a “yes or no - success response”. lets say that the response is yes then the credential manager could send a authentication request to the web service with the users - username and password. Then it gets a token back from the web service to continue the process.
The Credential manager now automatically creates the passkey for the domain and user account and sends it back to the RP (web service) it then gets a response back if it was received and saved. Based on the response is successful or failed the Credential Manager then decides if its going to keep the passkey or delete it to avoid storing a passkey that didn’t successfully get saved on the RP side.
What do you then say to Apple and Google’s implementation of Automatic Passkey Upgrade, clearly it is not a issue for them and then it doesn’t have to be for Bitwarden.