Passkeys

So…we got this new thing coming we found out today…and from what I’ve seen so far it’s not real clear exactly what it is. On one hand…it’s going to “do away with passwords” according to Apple but actually it will never do that since whatever cross platform standard thing that all the companies agree on will probably never be adopted by all the web sites one might use…and that means we’ll still need passwords for those.

In the interim…those sites that currently use passwords only will continue to do so even after Ventura ships and we have Passkey…and from what I can gather there will be a Passkey app that (hopefully) all be more user friendly than Keychain Access…that Passkey will operate on the iCloud Keychain and sync back and forth between devices…and that Passkey will use your biometric authenticator (face or touch) to open and automatically send either the regular userid/password or the new and improved Passkey authenticator to the site…and I guess that will be better than the current Safari passwords that it remembers and enters but only for Safari and may or may not sync between devices…I’ve been a long time password manager user so don’t really use either Safari or Keychain for things like that. In addition…iCloud Keychain currently AFAIK doesn’t allow attachments which means it can’t replace a password manager for me…yet…anyway.

ZDNet claims that Passkey is better than a password (and presumable a password manager) because they’re encrypted while password aren’t encrypted (except they are in the password manager and in Safari although its encryption might be less than adequate…don’t know.

Did anybody get a better idea from the keynote or from reading sites or quick takes or whatever on how actually useful Passkey might be? I know that Apple will say it’s the best thing since sliced bread…but a lot of the time especially early like this they’re pretty light on details of implementation and talk about things in the best light while ignoring things that it might not do. I also don’t fully understand how if they never leave your device what exactly gets transmitted to the web site for authentication. Perhaps this is similar to or incorporates the SQRL identifier that Steve Given of grc.com invented and I believe made open source for others to use…essentially it identifies you as user 1234567j9qtx with no actual identification to you as a person…which I would think websites won’t like because they like to profile you so that their advertisers (or them) can serve you more targeted as, sell your info to google or whoever, and get more per click because of the targeted ads. Identity-less authenticators sound like a good thing in theory from the user side but from the web site side they leave a lot to be desired monetarily I would think.

Anyway…thoughts? Or is this one of those things that nobody really has figured out yet whether it’s actually going to be useful or not?
\

Did you miss the article below?

4 Likes

As I understand it, Apple’s Passkey is at least partially based on the WebAuthn standard plus integration with iCloud syncing and probably some other Apple tools, and presumably APIs to make it work smoothly for apps that aren’t related to websites.

WebAuthn uses asymmetric/public keys, where one half of the key is kept private, but the other half is “public”—it can be given out to relatively-untrusted 3rd parties. When the 3rd party wants to authenticate a user, it sends their computer a random bit of data and asks the user’s computer to use the private key to “sign” the random data (ie: do some non-reversible operations to it) and return the result. The 3rd party can then easily verify that the signature is correct, by using the public part of the user’s key. Basically, given a public key, you can’t derive the private half of the key, but it’s easy for someone with the key to mathematically prove they have the private portion without actually sharing the private key.

It’s the same set of ideas underlying PGP encryption, RSA, ssh keys, SSL, and more, but wrapped up with standard support for automatically setting up the key pairs, specifications for pinning key pairs to specific sites (which renders phishing attacks non-viable), standards for tying into cryptographic hardware (eg: ensure the private key data is stored in the Secure Enclave, and require biometric authentication to use that data), etc. Beyond syncing and multi-device control, I’m not sure what secret sauce Apple is adding to this bundle, exactly.

As to whether it will actually be broadly useful, we’ll have to wait and see. Most people don’t like managing separate passwords for everything they use, which is part of why so many sites these days use Facebook, Twitter, or Gmail single-sign-on login systems. Yes, companies do like to have information about who is using their website or software, and they are still likely to require that a signup includes some user information beyond a mere random id. On the plus side for the companies, if they have a data breach, maybe they won’t have to pay for credit monitoring for affected customers now.

I think passwords will still be with us for a long, long time, alongside whatever better systems we build. It’s going to take a few years, at least (Apple Pay was broadly supported within around 5 years, I think; I’d guess this will be slower). WebAuthn has been around for a little while and hasn’t totally taken off because until recently, most people didn’t have a hardware device they could use for authentication with it. But now more and more people do have a device that can be used as a reliable authentication token—their phone or computer with a fingerprint sensor (or FaceID).

I can already use the TouchID on my MacBook Pro to log into the Stripe and Github websites—I’d love for more to let me do it (without syncing, I would currently have to establish separate TouchID authentication for each computer I use to access those sites; I think this is one of the areas where Passkey may offer an improvement).

WebAuthn is discussed here—even if Passkey isn’t building on WebAuthn, most of the concepts are pretty similar: https://webauthn.guide

Apple Passkey is discussed here: Passkeys Overview - Apple Developer

3 Likes

Also see “Apple, Google, and Microsoft want to kill the password with “Passkey” standard” (short):

and “How Apple, Google, and Microsoft will kill passwords and phishing in one stroke” (longish)

Fair amount of detail for how it works, and some interesting discussion in the comments.

2 Likes

Thanks Conrad…not sure if it was out or not when I googled and posted. Found more later and also checked out the FIDO site. Since this system requires revamp of the login process at a website…and it’s unlikely to gain widespread acceptance anytime soon it looks like a maybe long term solution to part of the problem…it’s got some issues just like Steve Gibson’s SQRL thing. Work for the website along with loss of more detailed user data which the website gets more ad revenue from due to targeted ads…makes it seem to me to have a lot of inertia against widespread adoption. It is good for personal privacy but not for website economics…and smaller sites are less likely to want to completely redo their process and revenue model if the6 have one. And we will still need a regular old password manager for all the non updated sites and for all of the other things we store in our password managers besides passwords. Much like the CSAM stuff that was placed on hold…this seems like one of those it sounded like a good idea at the time but wasn’t completely thought through. I’m not suggesting CSAM isn’t a problem…it clearly is…but the solution developed as it was presented had a lot of issues that commentary brought up that had clearly not been fully thought through. We users would love anonymous login…which is what this and SQRL do…although calling it ‘not a password’ seems like a bit of a stretch…but there are reasons that websites won’t like it and those will cause…now that I’ve read a bit more on it…IMO some reluctance on their part for a lot of sites designed to make money.

It is an interesting concept but needs more amplification before we can figure out how useful it will actually be.

I’m not sure where you got the idea that it’s anonymous. The website still knows who’s logging in and from where.

In many ways it’s better; web sites no longer need to worry about securing passwords from attacks, etc., which will lower exposure to lawsuits if account data is exposed, etc. It will also remove some friction from creating accounts on web sites - users don’t need to worry about choosing a password, making sure that they are stored, etc.

It’s early days on this, though.

But we’ve discussed all these pros and cons recently.

3 Likes

Passkey is a key discussion at WWDC 2022 sessions this week. Apple already has API’s available for developers to use across new OSs to make use of them.

I didn’t read the FiDO site in detail…but GRCs SQRL is an anonymous login to the extent that all a site k owns about user yvbrjdhy is that they authenticated themselves and unless they filled out the user profile somehow the site doesn’t know who they are. Could still be tracked by other means though. My admittedly brief reading on FIDO site made it sound similar…but since FiDO is based on public key encryption it’s still a password and doesn’t eliminate passwords…albeit it is probably a more secure password than most due to length.

Some things the website can still figure out obviously…maybe my wording was unclear…sorry ‘bout that.

In this week’s Security Now show notes Steve points out the major problem with Passkeys vs SQRL - portability.

Right, though as the developer of a competing system, Steve Gibson is not exactly unbiased. And Steve missed the obvious point that he can authenticate to any FIDO web site on a windows browser using his phone. Microsoft is part of the FIDO alliance, so they will have the ability to store the passkey once you have authenticated to the site using a device that already has the authentication pairing (eg, your phone.)

I’m not quite sure what Steve’s point was in this week’s discussion regarding Windows. Perhaps the issue is how will you transfer passkey from an iPhone to a new Android phone if you decide to switch phone platforms? I have seen people from FIDO have recognized this as a short-coming and that they are looking into some sort of solution. Right now it sounds like you’d need to keep the old device, log in to all of the passkeys on the new one, authenticating with the old one, but that’s not a good solution for anybody. So here’s hoping that before this is live that the alliance has an answer to this issue.

My concern here is lock-in. How simple will it be on typical websites to stop using passkeys and instead revert back to using user/pass? Will it be as simple as these days ‘set new password’?

The reason I ask is because of the major players involved in the initiative. People seem to consider that Apple, Google, and MS working together on a standard is a good thing because it means interoperability. And while that might be correct, to me those players also stand for a cartel of global mega-corps who love to lock customers into their “ecosystem”. So before eating from the forbidden tree, I’d like to know I have a ‘break glass in case of emergency’ box close by.

1 Like

Well, SQRL may have a similar purpose, but I don’t know if it’s really “competing” if he’s giving it away for free, open source, and with tested implementations for a very large number of platforms.

Well…it is a drawback although since FIDO is a much larger thing than SQRL is…and since Steve is a one man band essentially…it’s not really surprising that FIDO and Passkey will have more developer money and support. I still think it’s a long way to actually being broadly useful as it requires work on the web site ends to do the public/private key exchange thing and while it does free the site from having to worry about losing the security on their password database…if the only thing that is passed is the authentication after the crypto happens…then the site potentially uses all the other info on the user that might allow the site to get more ad revenue. As I said in another reply though…I know essentially nothing about FIDO but since their site does talk about public/private key authentication does Safari…or whatever browser the user is using…do anything beyond exchange of the appropriate crypto related authentication stuff? If that’s all it does then in the absence of a username…all the site gets is a random anonymous user…unless the username is still used so the site profile info is there but instead of a password the crypto does that with no password needed on the site side.

Still a long way from being actually useful though on anything like a ‘most of the time’ basis…but we gotta start somewhere and because of the crappy passwords people typically use and re-use starting the journey is a good thing.

I’m also not real sure that SQRL is a competing system…IIRC he released it as open source after developing it and has no plans to make any money off of it…so while theoretically being a competitor he’s really mostly interested in making everyone’s web use more secure…and while SQRL is his baby would he really be unhappy with the widespread acceptance of FIDO? Probably not IMO…and as I indicated his really is an anonymous system as I understand it…and from the user’s standpoint anonymous is probably going to be better than a user profile on the site for privacy purposes.

I just went and read Steve’s show notes from this week’s Security Now…and it doesn’t sound like sour grapes at all to me…it sounds like he has identified a key issue with cross platform compatibility and sync…and stating that SQRL doesn’t have this problem because of the way the keys are developed…and that from a multiple garden user’s perspective not having cross platform compatibility and sync would definitely be an issue. That sounds to me like Steve’s typical tell it like it is focus on the podcast…and not anything like being biased. Sure…he thinks his solution is better because it’s cross platform capable…but just because he developed his system doesn’t mean that it isn’t better than a non cross platform compatible system. I’ve…and we I reckon for a lot of people here…have trusted his insights and recommendations for a long time and from the show notes it looks like he has a point.

I don’t mean commercially competing. I mean he’s designed a similar system that is not being implemented and he’s got an obvious bias (probably deserved) toward his own design. As for the podcast, though, I don’t want to hear him talk about why his system is better - just tell me if FIDO/passkeys is designed well enough. It’s clear that this is going to be what’s implemented, not SQRL. (And, because SQRL derives it’s key pairs from the user’s private key and the domain name, it had its own problem of multiple accounts on the same domain. I have several Google accounts, a couple of Amazon accounts, and IIRC the SQRL solution to this was a little kludgy. The FIDO system of separate key pairs for each user account has its own issue, but it won’t be as kludgy.)

It’s not so much that these three companies are working together on a standard. It’s that they all committed to supporting the FIDO standard instead of coming up with their own system. The FIDO Alliance describes itself as “driven by the hundreds of global tech leaders across enterprise, payments, telecom, government and healthcare that have come together in support of the organization’s mission to reduce the world’s reliance on passwords.”

I don’t doubt that. By I question if for example Apple could implement this in such a way as to make it more difficult for me to use non-Apple devices. Frankly, I’ve seen them throw around their weight in an attempt to lock people in and I’m curious if here they could be able to do that again.

They’ve been introducing this with declarations that it will not happen. From Apple killed passwords with new passkeys on iPhone, iPad, Mac, & Apple TV | iMore

Browsing in Safari is even safer with passkeys, next-generation credentials that are more secure, easy to use, and designed to replace passwords. Passkeys are unique digital keys that stay on device and are never stored on a web server, so hackers can’t leak them or trick users into sharing them. Passkeys make it simple to sign in securely, using Touch ID or Face ID for biometric verification, and iCloud Keychain to sync across Mac, iPhone, iPad, and Apple TV with end-to-end encryption. They will also work across apps and the web, and users can even sign in to websites or apps on non-Apple devices using their iPhone.

Or, right from the FIDO web site

But, again, we discussed all this a month or so ago on “world password day”.

and users can even sign in to websites or apps on non-Apple devices using their iPhone .

Of course they can with an iPhone. :laughing:

But what if you don’t want to have to use an iPhone or any other Apple device at all? Say because you’ve decided to throw out all your Apple gear and instead buy from another company. How difficult will Apple make it for folks to switch all that auth from passkeys used with Apple kit to user/pass so that they can once again log on from anything with a KB? Or how difficult will they make it to export those passkeys such that they can be used on eg. an Android without ever touching another piece of Apple kit again?