Will passkeys ever replace passwords? Can they?

With regards to losing them, unless you're comparing a memorized password versus a passkey I don't see how it's any different. My passwords and passkeys are stored securely on my laptop. Since I have hundreds of passwords I have no hope of memorizing them all and use a password vault with random passwords. I'm using KeePass installed on my laptop.

If I lose my laptop, how is it any different if I'm using a password or passkey. Note, I have multiple backups of my KeePass database (.kdbx file).

Passkeys are basically how SSH pubkey authentication has worked for many years (except that sane people have the private key password-protected in addition). It is a great idea and well tested in practice. Sorry to inform you.

Sure, they may not the best match for everything. But why the scaremongering? People lose and reset passwords all the time. With passkeys it would be similar, just the split between situations when you keep and when you lose (and have to recover) access being along different lines.

Also, pubkey authentication should support multiple different keys for the same user & service (e.g. from different devices) out of the box. In other words, you can have redundancy – safely. In principle, you can have it with passwords too, but it is a mess and rarely done.

And you can at least dream of things which are just impossible with passwords, like mass revocation of all keys corresponding to a specific device. (Seeing how well revocation works elsewhere, this one would probably remain a dream.)

Solution: change how browsers work

Browsers nowadays are de facto failed authenticators: they verify HTTPS certificates, but do not go a step further proposed below. The base problem is that majority of users have no idea what URL is, or how important it is. Many still think Internet is a desktop icon. Or judge about web-site authenticity from its visual presentation.

Solution: Majority of web-sites visited daily have no business asking for a password whatsoever. So within a browser only a few trusted URL/domains should allow logins. Each user must explicitly whitelist specific URLs to ever ask for a password later. The browser must show a big warning during initial URL approval and keep a whitelist locally or OS-account-based. That's it.

Scenario: A user accidentally clicks on a phishing URL. Browser shows a big red warning telling the URL was not given permissions to handle logins, so it is likely fake and dangerous, then optionally sends user to the whitelist settings. The whitelisting process should be somewhat time consuming to guarantee that a user does not simply click OK-button as it happens with cookie warnings. For example require typing a longer numeric checksum, thus giving some time to think.

Notes: OS-level or in-app browsers should do the same. A special login handling protocol may be needed within HTML. Or it should be always the browser to handle logins - not a web page. Bonus - browsers can quickly spot and block phishing domains, as many users deny access to a specific URL. Banks etc must clearly indicate how to whitelist their URLs when opening an account.

And, of course, you'll need a passkey to protect the passkey. And a passkey to protect that. And. . . so on until an infinite number of monkeys in an infinite amount of time produce all the works of Jane Goodall.

"Passwords are flawed. Passkeys are worse."

If you have a password that protects the entirety of the kingdom, that's a problem. A gold depository has physical locks, biometric locks, card access AND guards. Even somebody with credentials and is known to the guards might not have access at 2am. Their access might be limited to certain areas and might require an escort.

The same sort of layered approach can be useful for personal banking. You can log on, provide a password and view the balance of your retirement account, but can't move funds remotely. Another account can be set up with a limit by the transaction, day, week, etc. To bypass that, you might have to visit a branch of the bank, identify yourself to a staff member and use a terminal there. I've never needed to make a huge shift of funds with no notice. If I'm going to make a big purchase, let's say a car, I'll have a cashier's check for the purchase or down payment ready to take with me or I'll get one after making a final decision and any negotiations are done. Different limits for different people.

Re: Lose your device, lose your access

I've never "put my life" -- passwords, or apps, in my smartphone. I've had one phone pickpocketed, and left another one on a commuter train. (The phone was never turned in to lost+found.)

The "How do I regain access to my accounts and data when my passkey-storing device is stolen/broken/disabled -- without allowing miscreants to use that recovery mechanism to access/steal my data/money/access?" question is a primary showstopper.

Re: Lose your device, lose your access

Surely your passkeys would be saved along with the rest of your phone's content in backups/syncs. Then if you lose your phone, it is stolen, or it breaks you can buy a new phone and restore with the passkeys as part of restoring from backup. There's an asterisk here though because on iPhone (dunno how Android works) you can only use iCloud to back up security critical information like that which lives on the iCloud keyring if you have advanced data protection enabled, and it isn't the default (for good reasons I won't go into here) and the only other alternative is an iTunes backup to a Mac or PC.

Now the hitch is that during that time without your phone you are without access to any sites using passkeys for login. It would also complicate stuff like switching from Android to iPhone as you'd need to copy that data from one to the other, and unless/until there is something specified in the passkeys standard I would not expect that to be a smooth process at all.

Passkeys are in their infancy, it is in that sort of raw bleeding edge phase where you have to deal with a lot of discomfort to be an early adopter. I'm very much looking forward to using passkeys, but very much letting others endure that discomfort and waiting for the whole process to be a bit more polished.

I kind of have to wait anyway because I run Firefox on Linux as my desktop browser, but would like to use Face ID on my iPhone to authenticate and have that communication take place between my PC and phone via bluetooth. Is all this even possible today? Maybe, but I doubt it, and it would certainly be a giant pain in the ass to try to set up. I might play with it some next year on to at least determine if all the pieces have that support, and see where things are at. I'm not even 100% sure Firefox supports passkeys, let alone having the pieces in place to allow it to use Linux's bluetooth software to talk to my iPhone!

Re: Lose your device, lose your access

Another potential issue is that you can't always assume that the passkey device will be able to receive the request from the requesting device, or send the response back to it.

Re: Lose your device, lose your access

"- your phone/key dies/is factory reset?"

Yes, you take your phone in to be serviced and find out when you get it back that the tech did a hard reset or the handset was swapped for a working one (that was reset).

You would have backed up your data before taking it in, but you know, it was broken and you couldn't.

A physical dongle you'd plug in didn't make it out of your pocket before going in the wash.

Re: Count me out

This. I don't understand why people still think this is a good idea. The whole point of 2FA is something I know and something I have - I was sure passkeys would give people an alternative to a hardware token, not replace passwords. While a passkey can't be phished, making it replace the password makes unauthorized physical access so much worse.

It's like having an SSH or GPG key without a password.

Though the "I lose the device and I lose access" part is already solved - put the passkey in a password manager that's synced (or in case of hardware keys have a second one).

Re: Count me out

Actually... Passkeys on their own have three factors. The first is what is known, that is your username/email, the second is what you have, your hardware, the third is physical presence, touching your key. If you worry a lot about devices getting stolen, all hardware keys have the option of a fourth known which can be a mandatory pin after touching.

Re: Passkeys have been destroyed by Google

Several of the points raised in that blog post are good, but there are a few that I think are missing the point.

For example, one objection in the post is that Google decided not to implement restrictions on providers of passkeys. The point that Google can effectively change the standard by not bothering to implement things they don't like is certainly valid, though it's not like they actually changed the standard and anyone else could also just ignore parts they don't like. However, the specific thing they didn't implement was so bad that I'm glad, and a bit surprised, that they didn't do it. Effectively, it was a way for sites to block key generators, meaning that they could easily restrict you to using one of their choice. That is a terrible thing. For example, if one site gets you to use their key system because it's the only one they accept, it's likely to get users who use that key system to store everything else. Privacy lost in ten lines of code. The argument for why you need that is "a business where we have policy around what devices may be acceptable". To me, this sounds like every other business who thinks that everyone's computer should be locked down so that their preferences are easy to enforce. I don't like it. Businesses can implement their own filter. For instance, they could not let me install software-based key managers other than the ones they like and could block hardware-based ones so only authorized ones work if connected, or they could just tell people that other ones are not allowed and that there will be consequences if you ignore that. Google did a lot of bad things with these, notably the comments about Android's treatment of them, but blocking the Authenticator Selection bit is welcome to me.

Most of the challenges I see with passkeys are not due to deliberate messing about by tech companies. They're challenges inherent in the model. I use a hardware token to access things. I know that, in order not to be locked out, I need to have a backup something, in my case another token. I have to pull it out and enroll it any time I enroll the first one. I have to keep it safe in the meantime. If I should ever lose both of these, there will be a bunch of annoying problems to get around. If I want to access something on a different computer, there will be friction. Maybe I left mine at home. Maybe the computer I'm connecting to doesn't have USB-C ports and I don't routinely carry a USB converter. None of that is Google's fault, and none of it is simple to explain to users. Passkeys were sold as a panacea to the problems of passwords, and they can be a massive improvement, but they aren't an improvement for every user or every use case.

Re: Passkeys have been destroyed by Google

Jesus H. Christ on a pogo stick.

Whatever happened to making your website READABLE?

Re: Passkeys have been destroyed by Google

From that article

Users should be able to use any device they choose without penalty.

Because, presumably, it would be so much neater to have every site specify its own authentication device. Just how many devices would I be expected to carry around with me?

Re: Might be a blast furnace for users who give remote access to scammers

"Passkeys seem more like a protection for websites than users: sure gullible users can’t recite or type their passkeys for scammers, but once scammers control a victim’s computer (mac or pc), the victim has lept from the frying pan to the blast furnace."

The average user is already in the blast furnace. They will have let their browser remember their passwords, and they will have let websites remember their credit card details.

Re: Might be a blast furnace for users who give remote access to scammers

Oh, yes, just like Chip and Pin. Who's main purpose is to shift liability onto the customer.

if you lose your mobile

You need to have the keys stored in another location, either a 2nd phone with the same app installed, or with the setup codes stored securely. I had all of mine stored both ways, in a password manager and on a 2nd device...which is a good thing because i dropped my 2nd authenticator device last week and it no longer works.

There are cross-platform 2FA apps that will sync across multiple devices such as Authy or Microsoft Authenticator. Don't use Google Authenticator lol

Re: Just promote the sensible use of passwords, teaching it in schools.

"Some can't cope with anything more complicated than passwords." Passwords are the most difficult to use. The user has to determine if the entity they are talking to is the same as who they talked to last time. HTTPS sort of provides this via a third party, but it is not easy. A system that does not require one to do this should be easier. The dark web manages it with PGP, how can the rest of the world make it so hard?

Even better, just GIVE all your money and information to criminals and then you won't need passwords at all!

Just use the equivalent for PASSW0RD in some other language, like Faroese. But then if you are Faroese then English is a foreign language so that's ok then.

As an alternative websites could just stop demanding you create an account unless its actually needed, and delete the needed information once its used.

I'm OK with it being an option but for a website where I may want to buy something again next decade why do I want an account and have to remember which email account and password I used last time and, if I try and create a new account because I can't remember but have the misfortune to pick the same email address, oh dear - you MUST login.

Re: Authentication is hard

"require a PIN to activate a given credential" that would be fun for me with my dyslexia/dyscalucalia. I don't even use PINs with my credit/debit cards as I can't remember numbers in the right order.

Anything that requires a PIN means either I can't use it, or I need it written down.

Re: Authentication is hard

I notice that PayPal will let my PC login using a Passkey on my phone... and I have to type in a TOTP as well (with the authenticator also on my phone).

Whilst still having MFA, this feels more convoluted than just using a password manager to me - which I guess is the main thrust of this article.

Re: I solved it

Any intention of releasing this as an independent product?

Re: I solved it

"The entire system is completely PII-less."

Except, presumably, for the payment method you use to charge them for account-related actions, which is either the PII-rich payment card or the will-drive-away-most-users cryptocurrency wallet with mandatory minimum holding so you can charge these fees.

Re: Count me in, please.

"I can’t get my work done now.". That's your failure, not theirs.

Re: Count me in, please.

I take it your users are provided with some SPF on which to store their public keys.

Re: Count me in, please.

A non-unique user ID is not a fault of passwords. Passkeys will still do that. There are advantages to them, but don't give them credit for things they don't fix or would be fixed regardless of the authentication mechanism.

Similarly, passwords can be a pain, but passkeys can be even more of one. For work-created accounts, it is often less of a problem. IT can manage a lot of the work, they already figured out where they're stored, and if the laptop is stolen or accidentally smashed to bits by a train, IT probably has processes for revocation and regeneration, or if the keys can be proven destroyed rather than compromised, maybe even restoration from a backup. The average user does not have any of those things. By now, they've mostly figured out how to have a password and write it down. Passkeys are less convenient in every part of the process except the logging in from your computer part. This doesn't mean that we don't use passkeys. It means we have to understand why they will be unpopular so we can fix whichever of those elements we can fix and build up the experience necessary to train users in those parts that can't be improved.

Re: Single point of failure

I came here to say exactly the same thing. It's not so much that the device becomes a target for cracking.

We have now reached a point where it's expected that a mobile phone will be to hand, switched on, charged and receiving a signal at all times. It may be lost, stolen, have a flat battery, be in the car, a different room, whatever. Without that availability there's no guarantee of being able to make an online purchase, manage a bank account or whatever. (Being retired it doesn't actually have any functionality for employment purposes.)

The smartphone is rapidly becoming a single point of failure for life. Have we learned nothing?

Re: Single point of failure

-- if you stuff enough tracking in the app --

DO you mean I can get a banking app on my smartphone - wow!

Re: 2FA can be a Catch-22 when moving countries

"it is a banking site"

All you need is to find and visit a branch of your bank where the staff are empowered to sort it all out for you.

Ah, I see your problem.

Re: 2FA can be a Catch-22 when moving countries

Before you move check that your phone supports roaming.

I think you are correct. Implementation choices are critical to the success or failure.

In your situation, Linux distributions have yet to integrate passkeys so that system would not ask to do the job. The browser is the next possible system that can confuse by offering to do the job. Your browser either has also not yet implemented passkey support or your settings may have disabled passkey support. I use Firefox but an external password manager so I have turned off FF's password storage which may be how it handles passkeys.

I think there are far to many options for implementing passkeys and little guidance. I think the goal was to make passkeys easy to adopt by service providers and many options to help in this goal. The result is to much variation to the end user. Some view them as a secure biometric authentication, others as a secure simple single factor authentication, and the list goes on.

In some implementations, a device's storage is limited so broad adoption will run into a roadblock. Hardware keys storing passkeys as an example, you would need to purchase more hardware keys, but newer ones will have more storage. Passkey loss account recovery suffers from the same problems as forgotten password recovery, the biggest being the weakest link in many implementations. A user does not always get to choose where they can store the passkey in some implementations. Some could be Windows, Mac, Android, iPhone only; sorry penguins and others.

I predict passkeys will be as well accepted as hardware keys, not very.