Passkeys: The beginning of the end of the password
blog.google
blog.google
What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.
Identity systems aren't too technically difficult, the challenge is properly rolling them out and getting mass adoption. Which means getting vendors/users on board. It's a problem solved by power and politics, not technological innovation.
Part of the difficulty of using secure credentials is sharing them between devices. It's easier to involve a third-party like Google who can do this for you. The big-tech doesn't actually want to solve the problem entirely because they want some form of control: Either locking you into their service, or aggregating the sites you log into, or both.
They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
What does "authority" mean here?
Biometrics are not it. Anyone can forcefully grab your finger and place it onto your phone screen. They can hold the phone up to your face.
Secure keys or passwords (actual authority) are only vulnerable to rubber-hose cryptanalysis, but you can use plausibly deniable measures to reduce the risk.
Both are bits of data stored in the body (including mind and pockets) that suggest the owner is giving consent.
They both have flaws, but what are the alternatives?
The mind provides authority.
Use both!
But don't mix them up. The mind is more secure than the body because information cannot be forcefully extracted from the mind. Yet.
I think a better solution for authentication is a combination of a cryptographic key or seed and a passphrase held in the mind. Keys could be provided by an NFC ring or smartwatch, which should be more difficult to lose or have stolen than a phone.
Bitcoin has a nice solution for cryptographic keys with BIP-32/BIP-39. You use a single master key to deterministically generate all others via a HKDF. The single master key is produced from a 12/24-word phrase plus an optional passphrase.
A good opsec for bitcoin is to have several copies of a phrase (which can be etched into stainless steel), so there is no single point of failure if lost/stolen, and you can use several passphrases for different wallets, which you don't write down anywhere.
You can use a word phrase with no passphrase in a "decoy" wallet and monitor on-chain if any bitcoin are spent in it. This would alert you that your seed phrase has been compromised but would not compromise your passphrased wallets.
To replicate this kind of decoy with passwords, you could store a login for some service which emails you if anybody logs in.
The decoy method also provides plausible deniability. There is no way to prove that there exists any other keyrings with other passphrases, and there is also no way to prove that you have provided every possible passphrase, even if you have provided all of the ones you do use.
How so? I just created two passkeys for my Google account — one for Chrome, and one for my Apple Keychain.
This is the concern, but exporting passkeys to other ecosystems seems like it'll come with time, even if via third-party tools or like how browsers will prompt you to "import your <passwords|passkeys>" upon setup.
"All your base are belong to us"
We have a lot to talk about and exchange information.
greg at the domain qbix.com
I regret to inform you that someone has carelessly or maliciously leaked your deobfuscated email address, on the site
You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true.
Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome instance via QR/Bluetooth.
There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2.
[1] https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-cl...
Android will provide an API for that scenario (i.e. on-device third-party authenticators) in the near future [1].
Hopefully, iOS will do the same.
[1] https://developers.google.com/identity/passkeys/supported-en...
Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs?
As a user, that's sounding a lot like platform lock-in to me.
And as a developer, if I want a way for users to log in without a password, and I don't mind that login mechanism being reliant on the user's account with apple / google / microsoft - wouldn't I just add a 'log in with apple / google / microsoft' button to my login page?
My government e-signature service does that: I can’t even use a Yubikey, ironically, because that’s not "FIDO level 2 certified". I had to buy a more or less completely unknown brand instead (of which a government affiliate is apparently the exclusive reseller in my country…)
Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained?
edit: spelling
If your site insists on the device providing a broad identifying signature (the specification says devices classes identified this way ought to consist of 10k+ devices, and in most cases a manufacturer will just identify particular models, like OK, this the model we made in 2019-2021, now we're re-tooling to make the newer model lets give it a new identifier) and the user agrees (I always refuse if asked, the documentation advises you just don't bother asking) to provide this, then you can see OK, it's a Yubikey Model 6J, I think that's (delete as appropriate) fine / not fine. This is obviously a large piece of extra maintenance work, hence it's advised you should not do it.
Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone.
There's also nothing in the spec that forces any provider to allow transfer, so I don't expect that to change any time soon. And even if you can transfer your keys (which you can't) there's also nothing in the spec other than "please don't do this" language that stops a site from using attestation to restrict sign-in from other devices that you've transferred your keys to.
It is very locked down right now.
The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices.
In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop.
There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
This is really misleading -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement.
There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwo...
That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned.
I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup.
> They are on all devices.
They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually adding it site-by-site is not the same as backup).
> There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API and sync format to the requirements for being a certified provider.
I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
> And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
There also hasn't been anyone yet who has tried to define what that interchange format should be.
> And again, nothing in the spec requires it. This is asking for vendor lock-in.
There are a broad range of passkey providers, from open source hardware to FIPS certified solutions to solve government compliance requirements. Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
But those government agencies are specifically investing in that hardware because it _doesn't_ lock them into one vendor. Any other vendor who can meet their security requirements can sell into that space.
Do you really not see the difference here? Passwords are inherently resistant to vendor lock-in in a way that passkeys aren't. And honestly, not to call you out but we're back on this again:
> of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
This is not representative of what the ecosystem actually looks like.
Apple and Google have announced zero plans beyond "we're looking into it" to allow open interchange with arbitrary 3rd-party clients. Chrome on Linux doesn't even support native passkeys at all. The most hopeful development I've seen in this space is Bitwarden. 1Password was billed as the solution, but I don't see any plans from 1Password to support porting to other password managers.
And any of these platforms blocking 3rd-party syncing is a big deal. If even just iOS decides "no, we won't allow that", that alone is a huge vendor lock-in that needs to be acknowledged.
So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up? And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
> Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
My worry is that most of them won't, and that hardware attestation will get rid of the rest. Let's say there is a client that supports moving passkeys around. That still doesn't change the lock-in potential for all of the clients that don't, it doesn't mean users will be able to migrate to that client once they've been locked in. It doesn't mean that services won't block authentication using that client. A good standard should block this all off at the source; it should (to borrow from the Chromium dev team) encourage developers to fall into a "pit of success."
We already ran into this problem with 2FA codes on mobile devices. How long did it take Google Authenticator to support backup? That has impacts on the ecosystem beyond just "is it possible for someone who knows about the issue in advance to choose a client that's more open?"
> There also hasn't been anyone yet who has tried to define what that interchange format should be.
Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
I mean, they're the ones that want me to get rid of passwords. If they want me to adopt their solution, they need to have an interchange format. It's kind of their problem more than it's mine.
> Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
Again, going back to this philosophy of the "pit of success" it should be harder to lock a customer out of backup than it is support portability. Portability should be the default, and it should be work to make that go away. And that's a key difference with passwords. It is work to make a password unportable.
----
At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
I would be more amenable to these kinds of conversations about the challenges of supporting arbitrary sync/export/import if I didn't have to start each of these conversations by calling out that arbitrary sync/export/import doesn't already exist. Because you're right, there hasn't been anyone who "has tried to define what that interchange format should be." That interchange format doesn't exist right now.
I don't think it's accurate or helpful if someone asks, "is this portable yet" to say "yes" when there is no interchange format and 3rd-party sync is an entirely theoretical future capability that companies are looking into, and there's outright resistance to building 3rd-party sync into the spec. Give reasons why that portability doesn't exist yet, sure. Promise about what will exist in the future, sure. But don't just say, "yeah, we're portable, you can sync keys" when both Safari and Android have huge limitations on when and where keys can be synced.
I'm not privy to their priorities or timelines, no.
> And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
But other companies with a history of being open here also do not have the feature yet. I am equally non-privy to their priorities or timelines.
If you want to say "passkey implementations do not have a bulk export/import feature, which makes it time consuming to switch between implementations", that is 100% factual.
I would not qualify this as a "lock-in", any more a phone that needs to get its software reinstalled is "bricked". And I wouldn't take current state to imply some inherent permanent ecosystem-wide rejection of user backups and data portability, when many vendors have implementations that are still in beta.
> My worry is that most of them won't, and that hardware attestation will get rid of the rest.
There is a great deal of worry about hardware attestation even by the vendors you are likely most concerned about. Apple for example not only removed their attestation, but now anonymizes the authenticator via a zeroed AAGUID.
No matter the vendor, their users (and the overall ecosystem) will suffer if relying parties build allow lists of acceptable authenticators, and deny all others.
That said, I do suspect the ultimate goal is to have sites be able to tell if an authenticator can allow them to shortcut additional authentication checks or not. It could be those websites give a more complicated authentication process to passkeys which do not meet their physical factor requirement.
>> There also hasn't been anyone yet who has tried to define what that interchange format should be.
> Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
Putting aside that I can't speak as to whether there is or is not an effort underway there -
It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
If passkey providers hypothetically want an interoperable interchange format or protocol, they can try to standardize it in a number of places including under FIDO Alliance. Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
> Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
I don't think this fixes your overall concern. There's no technical measure to prevent implementations from limiting backup/restore even if you make all authenticators anonymous.
Likewise, I don't believe websites would choose "friendly" credentials over "strong" ones. They would let the system survive or fail based on the user feedback/complaints of "strong" mode.
> At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
Yes, the process is automated within the same ecosystem, and we (finally) have a way to use a phone to e.g. authenticate to a computer and cross ecosystems. So far there is no process to batch migrate.
There _is_ a manual process to migrate. I get your desires and your concerns about users not understanding that they will have this multi-device process for migration today. I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.
How would they? None of the software involved here is Open Source, I can't open a pull request for any of this. And the backup/restore isn't going to work with any of the major players.
It's kind of striking that there literally isn't an Open Source provider supported on any of the major platforms. Let's say you build an Open Source one for Linux. Is it usable with Chrome? No, Google has no plans to support that. Does Mozilla have a working implementation? Also no.
Is that the FIDO Alliance's problem? Sort of? I mean, they want me to believe this is an Open standard. How many "Open" standards have zero officially sanctioned Open implementations of the standard?
> It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
The FIDO Alliance has more than two members. Microsoft/Apple/Google are already in talks about how to build out passkeys. And they're the players that really matter here. Whatever standard they come up with (or decide not to come up with) is going to dictate how the rest of the ecosystem moves.
But again, they're the companies trying to tell me this is an Open replacement for passwords. I feel like it's kind of on them and their alliance to prove it.
We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.
I guess this is where I'm arriving, too. Passkeys are a nice idea in theory, but the whole thing is too early in development to use or recommend to others at this point.
This is hopelessly naive.
We need to be actively making a lot of noise and sabotaging industry efforts to use passkeys until the respective vendors solve data portability.
I don't see any indication that Google is looking at Passkeys as just a faster way to log in without a password. They want to eventually replace passwords entirely.
My parents are a good example of this, they have recovery options set up so that we can get into their accounts if they die. None of those recovery options are compatible with current passkey implementations, and their phones might be the only computers they have that are capable of storing passkeys right now. I myself have exactly one device that's capable of acting as a passkey authenticator right now (my phone) and I suspect that'll stop working if I De-Google it and then I'll have zero usable authenticators. I'm not sure how I would add redundancy to a passkey login without buying additional hardware. It's not like my password vault where I can sync it to basically any computer or flash drive.
But that's a separate conversation. Regardless, the goal is the elimination of the password, a lot of coverage and advertising has centered around that. Passkey isn't in the long run designed to be supplemental to traditional log-in methods, it's intended to replace them.
The solution is to not use Apple's keychain for passkeys (and really not use Apple's proprietary services for anything at all), but we can't depend on people to have that foresight.
The authenticator is given a lot of leeway in how it does authentication. In the Apple platform case, it is "the user authentication on the device which is on the iCloud account and has set up iCloud Keychain".
So on my Mac I can use TouchID. On my phone I use FaceID. Both allow me to fall back to the device password (such as when I have the lid on my Mac closed).
I can't rely on retaining access to my Google account for logging into things.
1Password has already announced their intention to use this once ready. I really hope iOS will provide something similar soon.
There's many implementations of OTP. I've never used google's and I've been fine.
Disclaimer: I own 2 NFC rings :)
https://developer.apple.com/passkeys/
https://arstechnica.com/information-technology/2022/10/passk...
Now I'm wondering what's the longest class name out there...
The longest class names I remember are in the Java Development Kit (JDK) version 1.6, under the Swing+Nimbus namespace:
com
└─sun
└─java
└─swing
└─plaf
└─nimbus
├─...
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter.java
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonWindowNotFocusedState.java
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter.java
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonWindowNotFocusedState.java
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter.java
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowMaximizedState.java
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter.java
├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonWindowNotFocusedState.java
├─InternalFrameInternalFrameTitlePanePainter.java
├─InternalFrameInternalFrameTitlePaneWindowFocusedState.java
└─...
• https://news.ycombinator.com/item?id=4549685
• https://news.ycombinator.com/item?id=4770861
Someone copied the code in this repository: https://github.com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE...
This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device.
That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.
https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16...
I don’t see any way that passkeys kill account sharing.
In fact, it's important that people do this so that the invalid concerns can be put to rest and (hopefully) the valid concerns can be mitigated.
To limit it to just one defeats the purpose of all this work. You really will only see that where there is a technical limitation (like... why does AWS only allow a single hardware key per user? If you setup SSO then you can have any number of keys)
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you.
There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.
So it should be easy for everyone else to do their own.
There are payment rings a plenty though, for just using them instead of contactless credit cards.
Compare passkeys to traditional authentication factors. What's a password? A secret word or phrase that only you know. What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or retina. What are hardware tokens? They are physical devices that give you codes that verify that the person logging in has the device on their person.
What are passkeys?
Until they develop a way to explain what passkeys really are, I question how quickly they will be adopted.
As far as I can tell: it's a system of private keys stored on devices, in order to transmit a key you also need to unlock a device (e.g. phone) with some other method like a PIN or fingerprint/face scan. Combine those two things and it means a would-be hacker would need both the physical device as well as the local authentication for that device (PIN or biometrics).
What happens if user loses the only device on which passkey was enrolled?
If this is a Google Service, then that means begging, pleading, threatening, crying like a baby, then finally posting a rant on HN to get the service unlocked.
Google is fairly infamous for making it near impossible to recover lost account access, or appeal bans.
I have an account that I’m never getting back. I made an error, when setting it up, that resulted in me losing the password (I saved the wrong one, in 1Password). It’s been a few years, but I remember trying everything to get it back, and was stymied at every turn.
Eventually, I gave up. The reason I registered the account, was because it was the name of one of my corporations, and I didn’t want fraudsters registering it.
Mission accomplished. Ain’t no one using that account.
Yes!
> What about desktop machines with no fingerprint sensor or faceID?
You can use a PIN, your login/screen lock password, or an external device offering a fingerprint sensor.
> What happens if user loses the only device on which passkey was enrolled?
You can either sync passkeys to an online account and across multiple devices, or use multiple passkeys stored in multiple physical authenticators.
But all of that has to be set up in advance, right? What happens if I really only have a single passkey, associated with my phone, and then lose the phone?
Not all authenticators are going to have backups enabled (even ones which are backup capable), so these are really meant as hints so that a website (a la Relying Party in the spec) can guide the user to a proper experience. For instance, if you use a hardware security key fob, they may recommend you keep your password and SMS enabled as options, so you can get in even if you lose it.
But if you have this and the old authentication methods, doesn't that greatly reduce the security gains of this? I mean, the old methods still exist, so what you've done is increase the attack surface.
You don't have to use the latter, you can store your keys wherever you want.
It seems to be smoke and mirrors for you register a bunch of TPM/HSM.
Or if you drop your phone in a lake you’re out of luck too.
The protocol is private key stored on your hardware; public on the service you're authing to. Google doesn't have a way to MITM that, but if you lose the machine storing the private key, best have another way to auth.
(Note: some implementations, including Chrome on Android, do allow sync and sharing of the key, but IIUC even if Google bars you access to your account, the phone will still have the private key and can still do the login).
One of the main gripes people have is about whether or not the user actually has access to the key or not.
ie. Can I save my passkey somewhere that I control, can I login on another device, etc. etc. Or do I need google's sync/account to do that for me.
Google controls the software so it can MITM.
right, so passwords it is then.
You use passkeys as a preferred login method.
If you do not have your passkey, you can tap "Try Another Way" and use your password as usual.
It just becomes much harder to phish out this password.
If you've also lost access to your email, you've got other problems.
Or better still, use a password calculator app such as https://spectre.app/
This kind of approach generates your passwords for different sites based on login information and a single password only you know. No other passwords are stored on any devices or services, not even within the app on the device you are using it on.
Which enables you to have different passwords for each service and solves the problem of "too many passwords to remember" without just having to write them all down in a dozen ways that can also be compromised.
https://www.yubico.com/blog/a-yubico-faq-about-passkeys/ https://nordpass.com/passwordless/ https://www.future.1password.com/passkeys/
* Easy to understand. (A password is just a word/phrase/string of characters only you know.)
* Easy to use. (Using a password only requires remembering and typing it in when prompted.)
* Convenient. (Only your ability to remember and type required. No other tools or gadgets required.)
* Simple. (All of the above.)
If something needs an essay to describe itself, it's not killing off passwords.
Passwords should be easy to retire and change if they are compromised. You can' easily change your fingerprint or iris circle on demand, if somebody makes a good enough copy.
Do you really want your only means of logging into a service identify you because it's also the only way you log into your banking?
And should you want to kill off an identity so you want to have to register everything?!
On the other hand, I don't really know how would that work on desktops, should chrome use a Windows service for that? Would it use its own servers? Apple would probably do it themselves. And how about Linux? Would a cross platform option ever exist? Maybe 1password?
* Easy to understand. Your device will just ask "sign in?"
* Easy to use. Your device will just ask "sign in?"
* Convenient. Nothing to remember, nothing to do
* Simple (all of the above)
Passkeys are/will-be way simpler than passwords for the majority of users
The article is very frustrating, very long on fluff and no substance.
If anyone has a link to a detailed technical description by an unbiased third-party (not google hawking their lock-in), I'd be very thankful if it can be posted.
> Passkeys are easy to set up and let you securely sign in to your Google Account using your fingerprint, face, screen lock, or hardware security key. You can create a passkey on this device, or use another device.
When I press [Continue], Windows Security appears where I can then scan my fingerprint which I already use to sign on.
A single glide of my finger worked as expected and a 'Passkey created' screen appeared with [Done] being my only option to continue.
After a sign out, re-enter of my gmail and these are the next few steps: https://imgur.com/a/heLrUkb
It seems like it just integrates the built-in verification methods depending on what device you are on.
A passkey is a user facing term. Platforms have been working on technology to support that idea for years now.
There may be a difference in terms of how Windows Hello dictates the user experience vs what browsers show on other platforms - I haven't tried it recently.
> Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone.
It looks like a token stored on your phone that will be used instead of your password to authenticate.
Apple did something similar: https://developer.apple.com/passkeys/ that is automatically sync-ed in iCloud Keychain, so on every apple device you own, you can use it.
More information here: https://fidoalliance.org/passkeys/ and this explains finally how it works FIDO in general: https://fidoalliance.org/how-fido-works/
So yeah it's sort of a token, but technically, it's a private key that is used to sign the challenge at login time.
EDIT: from what I understand, while this prevents from "stealing passwords" etc., there is still the risk that someone steals your private key (copy/paste your phone or ... well, steals stuff from iCloud Keychain) and tries to use that to sign the challenge. Did I get it right? Or what mechanism is in place to prevent it? It looks like this time we use biometrics first (to unlock the screen) and passkey later?
They don't need to be rebranded, they need to be taught in high school with the same words we've always used to talk about them.
The answer is that they're being used to pass an authentication challenge. Pass + key is no different.
Could be clearer for the tech folks though I agree.
https://developers.yubico.com/Passkeys/Passkey_concepts/Sing...
I wouldn't be surprised if password managers implement sharing between users tho
Because the word "password" has been in use for a long time, before computers, for the purpose of physically passing from one place to another.
The thing about password wasn't that it is a secret word, it's that it allows you to pass somewhere. Typically, passwords were a shared secret (i.e. not secret).
A digital key is typically different from a password in that it's not a word, i.e. not something people can remember a type. It's more like something you have than something you know.
In the context of cryptography it makes sense to distinguish keys from passwords, and public keys (used to "lock" data) from private keys (to "unlock" data). The word key is used for that concept because of the semantics of how keys are used.
A passkey is an abomination. A key, a-priori, is an object that opens locks; and we already have words for keys that allows you to pass somewhere: e.g. door keys.
A pass, in general, is something you present to pass somewhere, whether it's spoken or written; a key is not something you present to pass somewhere.
We have pass words, pass slips, hall/press/ski pass badges, etc.
We don't have pass keys, because you don't show a key to pass somewhere. You use it.
A password encoded as a QR code that you could show to a sensor would be a passkey.
Whatever Google has is probably something else.
You cannot use the private key within a passkey for general purpose data signing, for example.
this isn't just public key encryption. Think of it as a physical Yubikey but embedded in your ...whatever.
The keys are also per-device, so e.g. if you use your Google account from your phone, your laptop and your workplace PC, there would be three public keys associated with your account.
Because the private key (in principle) doesn't ever need to leave the device, it could be stored in a TPM, Secure Enclave or similar chip. The device itself is also supposed to protect the key with some sort of local authentication, i.e. biometrics or a PIN. That stuff only happens locally on the device though and doesn't involve Google's servers in any way.
Consequently, if you want to log in from a new device, you can't just copy over the key - you have to perform some complicated dance where the new device and an old device that you have already registered work together to generate a new keypair for the new device.
If you don't have an old device, e.g. because you're a non-techie and only ever used your account on your phone and now your phone just broke? Though luck, I guess?
Same goes for blocking a key: In theory, you can block access for each device individually - however, you need to be able to access your account using one working device in order to do so.
(There is also the hilariously useless flow of "delegating" to a device, for when you're really really really want to check emails from your friend's phone but also have your own phone right with you in your pocket. It will not actually help you if you want to check emails from your friend's phone because you have forgotten your's. This feature sounds a lot like they needed something to respond with if someone asks about logging in from 3rd party devices - without making that usecase actually practical.)
So I guess all that does make stealing the private key somewhat hard: Phishing is out of the question as the user can't access the key even if they wanted to. Even if you got hold if the physical device, you'd have to get the key out of the TPM.
The bigger problems I see is that your account is now tied to your devices instead of, well, you: If someone steals your phone and manages to guess the PIN or get through the biometric auth, they have instant access to everything. On the other hand, if you have no registered device left, you're effectively locked out of your account.
(All that assuming if passkeys were the only option for logging in. As of now, they still seem to plan with passwords as fallback, so that's just hypothetical)
I can kind of see the reasoning on why the browser wants to do this. Every one of them has a "generate secure password" feature bolted on, now. And I'm not clear that any of them have a way to port passwords out to another source.
Still feels a bit uneasy to me. Physical keys for property provide the kind of security that just doesn't cut it for virtual assets. Such that I'm having a hard time seeing any model without terrible failure cases. :( Super glad that isn't my day job. Good luck to them.
Pretty close - in fact you can use passkeys for SSH access, a la "ecdsa-sk", and in some cases "ed25519-sk".
> The keys are also per-device, so e.g. if you use your Google account from your phone, your laptop and your workplace PC, there would be three public keys associated with your account.
They are per authenticator. Some authenticators, like a Yubikey, hold their credentials in hardware. Some are backup capable - e.g. the "authenticator" is your iCloud account or Google account's password sync fabric (which are often secured more than the rest of those accounts).
This second class is what is known as backup-capable. Buy a new phone to replace your old one, and within the same ecosystem things just work because the platform authenticator can see all your old passkeys.
Across ecosystems, there is the ability to use your mobile phone as an authenticator for other devices. You can sign into an app on a Mac desktop using an android phone, for example.
Going forward, Android has beta code to support third party passkey providers. Hopefully other platforms support similar schemes, which would allow users to choose a cross-platform product rather than being platform-locked (or requiring them to buy hardware).
Guess that's the price i pay for using the hardware in a slightly different way than what google and the manufacturer wanted me to.
> using the hardware in a slightly different way
Honestly I wouldn’t classify turning a daily driver device into a semi-brick (if it boot loops and has to be hard reset regularly…) as “slightly different”. If you want to experiment that’s fine, but why would you subject your daily driver to that? Or, why not just have a phone for stable use / real world stuff, and a phone for everything else?
To put it bluntly: you’re wildly out of touch with reality for most people. 99% of people who have a phone — even those people who install custom ROMs on their daily driver — either plan around having to deal with this stuff or have an escape hatch. Most people refuse to tolerate such an experience.
My previous phone was a Xiaomi. Part of the reason they're cheaper than competitors with similar hardware is because that thing is filled to the brim with useless ads, extra tracking way beyond just crash analytics for the manufacturer and the regular google stuff and even some useless "phone booster" app embedded in the settings.
After waiting the two weeks so Xiaomi would allow me to unlock the bootloader (which is bullshit, by the way), i installed LineageOS.
The problem is that the regular updates with security patches sometimes would cause a boot loop. Some times is something as simple as a system file becoming read only, sometimes no thread on XDA developers could guide me to the right solution, and then i just do a factory reset and start over.
But aside from flashing lineage and an ad blocker, my usage is the same as anyone else: answer calls, use messaging apps, browse the web, play games and edit some documents when i'm far away from my PC.
My current phone is a motorola, though, and while i think the official ROM is pretty disappointing (too many pop ups nagging me to sign up to motorola or check motorola apps), as long as i can flash magisk and an ad blocker, i'm a happy person.
I don't think 99% of people who have a phone have any kind of extensively worked out plan for what happens if their phone is lost, stolen, or breaks. If we're lucky the number is more like 50%. For most intents and purposes, irrevocably losing access to a phone is equivalent to bricking it in the way OP talks about. Any passkey-esque system needs to have a fallback plan when the phone unexpectedly becomes unavailable.
How convenient!
> Passkeys created on Android are backed up and synced with Android devices that are signed in to the same Google Account, in the same way as passwords are backed up to the password manager.
I don't like this. Time will tell if Google's implementation will be open source, and if third parties can hook into the OS level integration. I certainly don't like the lack of emphasis on interoperability from the get go.
I do not like this future.
Also it seems that Linux is completely out of the picture.
The Android implementation allowing for multiple third part passkey providers (typically, existing password manager that want to support passkeys) is in beta.
Apple does not pre-announce features, so we are all likely in the dark on their timelines, and whether their timelines extend to infinity.
However, I believe a passkey manager can replace the system implementation via the web extension mechanism in mobile Safari today.
It is all user terminology for Web Authentication features, so credentials stored on a current Yubikey are also "passkeys".
There are multiple open source security key hardware implementations that support the published specs.
There are multiple password managers that have started to implement "passkey manager" functionality - 1Password and Dashlane have made announcements here and have published code and Web Extensions for desktop.
Android 14 beta has a system API where software providers such as 1Password and Dashlane can work with this system, not just for Chrome but for installed applications.
I doubt Google's Password Manager will ever be open sourced, but it doesn't need to be for an interoperable ecosystem.
Assuming there is an ecosystem where they can play equally, I suspect they will find all sorts of ways to provide unique value. Their goal shouldn't to be the preferred system across all of Android or iOS, but to offer something a lot of people are willing to pay for.
what you described above doesn't guarantee that the ecosystem is interoperable. With passwords, there is no way for the service provider to hide the cleartext password from you, this is inherent to the way passwords work. With passkey, a service provider could decide to hide the private keys from you, effectively locking you into their ecosystem, and there is nothing you could do to avoid this.
There's no guarantee that they will act in a user-beneficial manner, except they all already exist and already act in a user beneficial manner, and that there is no strategic benefit of acting in a user-hostile manner.
> With passwords, there is no way for the service provider to hide the cleartext password from you
Sure there is. They could refuse to do anything but form fill the passwords on registration and authentication pages, where the field in the browser will not allow you to copy the password back out.
The force that keeps them from doing such user-hostile behavior for lock-in today is that nobody would want to use that system. They would not use that vendor. It would be product suicide.
> effectively locking you into their ecosystem, and there is nothing you could do to avoid this.
Unlike passwords, sites are encouraged to allow you to register multiple passkeys. Some sites may push the user to do this for convenience, such as if they see user utilizing a security key or phone to authenticate into their desktop when the desktop is capable of doing passkeys directly.
This gives a whole new ability to jump ship if you decide you don't like your software vendor.
Now, there is a parallel question of "what if a vendor uses their monopolistic power to prevent an ecosystem from being created, and then acts in a user-malicious manner". I suspect they would quickly get multi-national scrutiny.
You can, but most people won't because they will be locked-in, this is not the case with passwords as it's quite easy to change password manager without having to reset all your passwords.
This is not a remote possibility. It happens to thousands of people every day, for entirely frivolous reasons.
Until there is some authentication system that is genuinely robust to corporate control attacks, I'll keep using the imperfect password manager model.
You can for example use a Yubikey, on a Linux desktop system, to authenticate to services implementing the "passkey" standard. Does Google own my Yubikey in some way that I'm unaware of?
Nothing is owned by Google or Apple or Microsoft, there is no grand conspiracy trying to lock you into a platform.
Try educating yourself before spreading misinformation, and before assuming that everything is an Evil Conspiracy by Big Tech.
I tried to do some research myself, but there's no Wikipedia page for "passkeys" and they aren't mentioned on the Yubikey article.
Edit: this user has a helpful comment: https://news.ycombinator.com/item?id=35810144
> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.
I'd love to know more about how / whether these challenges are enforced as part of an open standard, or whether it's up to individual implementers of passkeys to roll their own.
The list of members of the FIDO alliance is public. It includes several companies that most people refer to as “big tech”.
Also I am not sure that I would consider not being able to access private key material from a enclave vendor lock in, since that's the entire purpose of the device.
I guess the same people arguing that passkey is a conspiracy are the same ones that think secure boot and TPM is a Microsofts conspiracy to prevent you from installing Linux.
They are an improvement for service providers, sure, but not for users, due to vendor lock-in. This was my initial argument from the start.
You kept countering with arguments such as "you can use a FOSS client", "but Google is a contributor to open source" or "Google can't access your Yubikey" - which are irrelevant to my point, which is that the new standard introduces further vendor lock-in.
In addition you resorted to personal attacks - calling me and other users in this thread conspiracists or uneducated - but could not counter any of the points we were making with valid arguments.
My understanding is that the private key is stored on your own device, unless you decide to use something like iCloud Keychain (which should be encrypted).
The public key, on the other hand, is stored on the service providers' servers. That is used to create a "challenge", which I guess on your phone you will need to "decrypt/sign" with the private key to prove that "it's really you".
That's how I understand it.
So, a communication failure straight away. Does not bode well.
Thinking about this some more, maybe we should start calling Yubikey etc. keyrings, rather than keys, given that they can store multiple independent passkeys securely?
It's lowercase "p" - it isn't a Google or Apple brand.
Developers can use terms like "multi-device discoverable user-verifying FIDO/WebAuthn credentials" which have very precise technical meanings with demonstrated interoperability.
And they will be fine with that because they have already been introduced to this because that is the way they authenticate locally with many apps on their smartphone already.
When you register a passkey to access a site, the component that holds the passkey generates a site-specific asymmetric encryption keypair. It then gives the site the (unencrypted) public key, and the private key encrypted with the passkey.
To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in.
A lot of what is interesting about passkeys is the supporting components that are available on popular platforms. Generally speaking, on client devices they store the passkey in special hardware so that the passkey itself is not available to the regular cpu. They also store it in the cloud, probably also in special hardware, and can send it to new client devices.
This all has some nice security properties, namely: * sites don't have any information that would be useful in gaining access to a different site (reduced blast radius when any given site is hacked) * the passkey is not available in the clear to regular programs running on client devices (hard for malware to steal) * The client software ensures that the passkey is very hard to guess. * The client software authenticates the site before signing the challenge. (makes it hard to phish)
https://developers.yubico.com/Passkeys/How_passkeys_work.htm...
Close - it is a signing key, e.g. used for integrity and authentication
> To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in.
This is how non-discoverable WebAuthn credentials (may) work, and is based on the U2F model. These hardware security key fobs did not have sufficient memory to store created credentials and associated metadata for potentially hundreds of sites. So instead, when you registered a credential it would generate a handle, and that handle would be returned to the site. To request authentication, you had to provide a handle which the authenticator understood. Such a model is really meant for second-factor authentication, e.g. after we partially authenticate the user with a knowledge factor, see if they have the physical factor.
A passkey in contrast is meant to indicate a discoverable credential. You don't need to provide those handles to authenticate. Instead, example.com shouts into the void (of browser javascript API) that it would love a previously registered credential. It hasn't authenticated the user at all, so it has no idea which credential that might be. An authentication response includes the handle and a signature, such that it can be correlated with the existing registration on a user account.
Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.
Thanks for this helpful comment, it helped me understand the difference between U2F and passkeys. I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected. (I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys, or would this necessitate buying a new device - if you're not willing to use your phone for the purpose.)
The WebAuthn spec describes a Javascript API, and CTAP describes how to communicate with authenticators over various transports (USB and NFC being the ones with the most implementations).
Actual conformance to these, requirements on behavior, and things like whether the hardware has mechanisms to protect certain types of attack if someone has physical access all fall into certification. The implementations can provide attestations, which allow a third party like FIDO Alliance to assert some level of certification (even if at lower levels the implementation details are self-asserted by the implementer).
Without certification, it is the manufacturer's word to the user that it has proper security and protections. Without attestations, there is no guarantee to the site requesting authentication that any particular process took place or that the credential has any particular form of security.
But the reality is that while we have built sophisticated _models_ for describing authentication and compromise risks, most consumer-facing infrastructure is a hodge hodge of password-backed accounts with email recovery.
The user already has full choice in how they manage passwords - from established to shady software makers, to a printout of an excel spreadsheet in 5 point font they keep in their back pocket. The SMS you sent out to verify the user's account may very well be protected by a carrier account with the same password the user supplied to you at registration.
> I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys
Passkeys are "just" WebAuthn credentials with a couple of features - e.g. discoverability and user verification. With usability caveats (say, limitations around UX with NFC key fobs) I would expect hardware from the last 2-3 years to support passkeys just fine.
Support for new features may be added over time, both in software and hardware. For instance, a 2020 security key fob might only support a dozen passkeys, while a more modern fob might be able to store hundreds.
You're probably right that if an authenticator is supporting discoverability it no longer makes sense to store the encrypted private key with the RP. It's still allowable though[0].
Passkeys are a better alternative to passwords. We don't have to think them up to meet arbitrary password complexity requirements. If a website gets breached it does not risk my account at other websites. It is phishing resistant, so I don't need to worry about accidentally using my passkey on the wrong website.
_We_ need to know more as implementers, but the average person signing into Google does not. It's an extension of the password manager experience, using technologies like public key cryptography and an authentication protocol rather than form-filling of text secrets.
For more technical details as an implementer, there are sites like https://passkeys.dev .
keeping your data secure is google's job, not the user's. if google stops asking for a password, that's going to make people happy and they're not going to ask a lot of questions about why.
The key word being identify, as opposed to authenticate.
Authentication using biometrics is only secure as long as the object being scanned cannot be physically replicated and you can verify that the data source is a physical scanner and not a simulation of one.
How do you implement that without compromising device repairability?
From a practical one it's another way to get people to relly on major comporations for all Auth ises so they yet have another thing anchoring to their ecosystem.
No, a password is a secret word for phrase that both you and the service you want to sign into know.
I don't know how to explain a passkey but at least in this one sense, a passkey is split into a public and private part. The public part is shared, the private part is not. The public part can be verified to match the private part without sharing the private part. Your device stores this private part. When service wants to let you login they ask your device "does this public part match this user's private part?". Your device responds in a way such that the service knows "only someone who has access to the private part could have responded correctly to -should this person be allowed to login'"
That would not be a password, that would be something you share. An actual password must be possible to verify without it being stored on any device. On the service side, it's the same as for certificates, as you describe. The service can't store the password because that would invalidate it's usefulness as a way to prove someone is who they say they are. This is why we store a cryptographically secure hash code instead. It is also why the password hash code must be generated on the user's end, not on the service side. You never want to "transmit" passwords in plain text because transmission across the internet is an act of making copies of the data transmitted in the memory and storage of all the devices it transmits across. The moment you send a password across the internet, it is compromised.
So as the service, you don't know the password, you only know that the hash code you received matches the one for that user, and you are reasonably certain that there is no known way for someone to generate that hash code without knowing the real password. Therefore the person trying to login in must be who they say they are.
Passwords and private keys only work as authentication if no one else knows it, has possession of it, or can get access to it. If there is a flaw in any one of those aspects, then the system doesn't actually prove a person is who they claim to be. It only proves that a person is someone who knows, possesses, or has access to that thing. That might still count as evidence that they are authentic, but more will still be needed to actually prove they are authentic.
At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures.
I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requirement to opt in to it) to the W3C WebAuthN working group, but it seems like the working group itself is strongly pro cloud synchronization as well.
Today, Google has sent me an email about their intention to deprecate their (device-bound) iOS authenticator in favor of (iCloud-synchronized) Passkeys, and I guess I'll begrudgingly have to switch to using an external FIDO authenticator instead.
Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.
Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time.
> Security must be a balance with functionality, and this is a huge improvement over passwords.
Sure, but I'm somewhat disappointed that the WebAuthN WG basically forced this huge change of semantics (it's essentially a security vs. availability tradeoff) into relying parties without explicitly collecting their opt-in beforehand, or even providing an ergonomic way of opting out.
[1] https://support.apple.com/guide/iphone/sign-in-with-passkeys...
It should also be able for relying parties to express that desire (whether opt-in or opt-out by default). As it is, I think it'll just make banks and governments less likely to adopt passkeys.
That's sad, because all in all I think WebAuthN has the potential to have a very positive impact on security globally.
If a platform gave users this option per credential, and there was any visibility to that choice on the relying party side, the replying party would likely just reject the credentials they don't like outright, and tell people 'go figure out how to twiddle this setting if you want to use your phone here'.
Part of the web focus of these APIs mean that they will default to being open and user centric - features that might enable relying parties to block user choice will receive tremendous scrutiny, and proceed very slowly. Sites are expected for now to accept what the user chooses, and do additional steps as necessary to meet their needs. This means passkeys as a whole are not going to be always accepted as a MFA replacement.
Even features like hardware attestation are gated by a prompt by some browsers, because some consumer-facing websites went live with code saying "we will only support this one brand of security key". This led to some of the warnings in the document here: https://www.chromium.org/security-keys/
I can sympathize with the desire of a "footgun mode", which might even lie to the website about whether the credentials are backed up. However, I wouldn't trust something that critical to what is almost going to be a poorly maintained path through the system. Instead, I use (two) Yubikeys for such credentials.
This is what you expect when you buy into the closed Apple ecosystem.
I must be missing something but I do not get all this hand-wringing. Don’t like the passkey options from Google or Apple? Fine! Use the hardware authenticator you absolutely already have if you’re the kind of person who has these sorts of objections.
Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS. There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.
It would encourage competition in both functionality and security, it reduces reliance on a single account your entire digital life, it allows niche products to address special requirements in all kinds of scenarios...
Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.
> There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.
Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.
No, you're literally recommending I use a separate physical device because there is no API to achieve the same functionality that the OS provides via their bundled implementation.
> Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.
On iOS, Passkeys have been available for more than half a year now. I really hope that Apple will eventually follow suit.
A $50 device that I have no doubt you already own, and that does not require you to change or modify any of your existing computing setup or habits.
If your point truly has merit, you shouldn’t need the hyperbole.
Local-only iOS+macOS Codebook sync (open-source encrypted! by SQLCipher) provides password and TOTP convenience, durability, transparency, decentralization and fewer supply chain dependencies with one-time purchase. Founded in 2005.
Passwords and TOTPs are not MITM-safe, WebAuthN/Passkeys implicitly are. (Credentials are bound to a specific RP, i.e. it's impossible to accidentally provide one to the wrong website or a scammer on the phone.)
Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?
Sure, but passwords are still multiple-use, and sometimes auto-fill fails (often due to websites actively messing with it), requiring me to manually copy-paste the password and exposing me to phishing risk, or that of insecure/malicious applications on my system sniffing the clipboard.
> Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?
Unfortunately not at the moment. There is some hope though, given that Apple has recently added a TOTP API for third-party authenticators, but I'm personally not holding my breath.
For those, Safari share sheet -> "Find in Codebook" = dialog with URL-matched credentials appearing first.
> insecure/malicious applications on my system sniffing the clipboard
iOS now requires interactive user consent for apps to Paste from clipboard.
Fortunately it does – a big security win. But unfortunately, macOS does not yet, and I'm copy-paste-ing passwords there more often.
I'm often wondering if drag and drop of text is actually more secure than the pasteboard?
WebAuthn is different:
1. The client (browser) knows which site is requesting credentials, which means a phishing site cannot ask for another legitimate site's credentials
2. Credentials are created as private keys and unique per-site.
3. The authentication protocol does not share secrets; it is based on public/private keys.
4. The authentication protocol involved indicates the requesting origin.
There are still vulnerabilities if you have compromised DNS or javascript on the site, but it is overall significantly stronger against phishing and credential reuse attacks than password managers could provide before - even those with browser integration.
Wonderful. Until every second web service starts to require a signature from such digital identity ("age verification" perhaps?) and that's the end of pseudonymity.
If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere.
This isn’t a theoretical risk. You’ll see lots of people complain about this online.
Also, Passkey providers now get sweet sweet metadata about your accounts around the web.
But yeah, authn is hard to do right. Equally, asking your users to fall into $BIG_PROVIDER’s arms seems wrong.
My personal hope is that various accountable nonprofits will begin to offer passkeys.
That third party account should be treated like your personal property, and them denying you access to it should be treated like their CEO breaking into your house and stealing your stuff.
If they don't want to take on the liability, and it kills the passkey spec, that's fine with me. The current system avoids the issue by allowing people to store credentials in a decentralized way.
“We have concluded the review of the information you’ve submitted. To prevent possible fraud and abuse, your services will remain suspended. It is our policy to not discuss the specific reasons for these suspensions.
Note that in the Google <PRODUCT> Terms of Service, we reserve the right to change, suspend, or discontinue any aspect of our services at any time, including availability of a service or any feature, without notice and without liability. We also reserve the right to impose limits on certain Service features or restrict access to some or all of the Services without notice and without liability.”
Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co. ("roaming authenticators" in WebAuthN/FIDO parlance).
Unfortunately, only Android is planning to offer [1] a first-party Passkey provider API, because that's what I'll probably be using 99% of the time (finding my external authenticator for every login is frustrating).
> Also, Passkey providers now get sweet sweet metadata about your accounts around the web.
To my knowledge, both Google's (for Android) and Apple's sync backends are end-to-end encrypted. I'm not sure if that includes the metadata as well as the private keys, though.
[1] https://developers.google.com/identity/passkeys/supported-en...
That’s good to know.
Although my concern would be, that’s really good for people who use YubiKeys, but regular people won’t, and they can then get bitten by account lockouts.
Is there something regular users can do to use Passkeys (let’s say they use Google) and have some recourse if Google locks them out?
Also, what happens if they use Android, have no other computing device (this is fairly common in some parts of the world), and their phone gets stolen?
With passkeys,the identity of the account is tied to either a BIGTECH account, or to physical devices.
If BIGTECH locks you out or you lose access to all your physcial Yubikeys at the same time, you will never access the account tied to the passkeys again.
Possibly two ways, if you have both Android and iOS devices and you register both? (I assume Android and iOS remain independent.)
A password is in your head. If you lose that, there's not much use for the said password. But otherwise, it's secure. And it's pretty secure from an infosec perspective if it's a passphrase.
There's no perfect solution. Having a printout of backup codes in a fireproof safe is pretty good, but it's of no use while traveling. A Yubikey is good, but it might not work (wrong USB port) and it's a device that could break.
Having multiple ways to log in reduces your risk of lockout, but also makes it more likely that someone unauthorized could get access.
- There-are-three-ducklings3-in-the-lake
- There-are-five-swans5-in-the-lake
- There-are-six-hedgehogs6-in-the-bush
And so on. You only need to remember the latest number and animal, but the entropy of the whole string is much higher unless someone also knows your personal password structure (which is kind of like a second factor).
With a password manager, you only need to remember that one passphrase. If you have to enter it daily, I think it’s very difficult to forget.
You can access your passwords mostly independently from any device and it’s probably about as secure if good generated password hygiene on websites and services is used.
I’m not sure this is better than using a device to log in.
Passwords are good because you remember them in your head, so long as the head works, so do the passwords. This might be an obvious statement, but it's clear passkey providers kind of glance over it.
RP-side, it's true that RPs can't opt out of credential syncing, but I think that would be weak at best, as the authenticator can do what it wants. The RP can use attestation and the DPK extension to effectively bind authentications to the same originating device.
I don't think it's that specific of a threat model, to be honest.
Many people are logged into iCloud on multiple family devices – are they aware that with Passkeys, by default every device they are logged in to has single-factor access to their entire online life?
Additionally, Apple's iCloud security posture has been in the news lately with some quite horrible stories that are very relevant to Passkeys, in my view: https://www.wsj.com/articles/apple-iphone-security-theft-pas...
If they just accept normal Yubikeys (and multiple at a time for redundancy) that'd work for me but this passkey stuff where the vendor gets to decide things and I don't fully own my credentials is just wrong IMO.
I wonder if there's a fully self hosted passkeys option?
I'm also opposed to attestation. With TOTP I can use any app I want and back up my keys however I like. But Fido gives a lot of control to websites, they can choose what kind of authenticators or apps to accept. This can make it too easy to get locked into vendor solutions because they are the only ones every website trusts.
If external authenticators work for you, physical keys (like Yubikey, Solokey etc.) are arguably self-hosted!
For on-device passkeys, at least Android is preparing an API for this [1]. I hope that iOS will follow at some point, as well as Firefox (which unfortunately has been quite slow to adopt all aspects of WebAuthN).
> I'm also opposed to attestation. With TOTP I can use any app I want and back up my keys however I like.
In principle I agree, but some service providers like banks are legally liable for fraud losses (at least in some jurisdictions). I'd say they do have a legitimate interest of being able to verify which authenticators they trust.
Of course, it's being already exploited in a pretty much expected way: My government offers a (free to end-users, tax paid) e-signature solution. They support, among other authentication methods, FIDO – but only a very specific authenticator, of which the e-signature service provider is the exclusive reseller in the country...
[1] https://developers.google.com/identity/passkeys/supported-en...
Yes. And this is what I do with all my personal stuff (though I use the GPG mode on the yubikey, not Fido2). But, because a passkey can be backed up, websites targeting mainly passkeys will be likely to offer only a single authenticator to be enrolled. Of course with hardware authenticators that is not going to work. Lose that one and you're screwed. This is why multi-authenticator support is so important.
> For on-device passkeys, at least Android is preparing an API for this
Thanks, I'll have a look at that. I'd want it on the PC too though (BSD). But anyway, hopefully it will come. I never really looked at it, as for now the website acceptance part is still so low that it didn't matter anyway. For the ones I use regularly, only Office 365 supports it. I'm not interested in the old FIDO MFA mode, only full passwordless will do.
> Firefox (which unfortunately has been quite slow to adopt all aspects of WebAuthN).
Yes, this is really a PITA now. They really don't seem to give a ***, they only offer CTAP2 (full FIDO2 + PIN) mode on Windows. Still not working on Mac, Linux, BSD... It's been in this sorry state for years now.
> In principle I agree, but some service providers like banks are legally liable for fraud losses (at least in some jurisdictions). I'd say they do have a legitimate interest of being able to verify which authenticators they trust.
Banks here already use their own authenticators which they provide anyway, but yeah that's a point. Many other sites shouldn't be able to make such decisions though, IMO.
PS: I'm not sure why you are being downvoted, I really appreciated your insightful comment. Especially about the Android option I wasn't aware of.
I have yet to see a bank use login restrictions to make itself more secure. I've been trying to get my bank to offer actual 2FA for years, and their response is that they moved from offering SMS/Email codes to only offering SMS codes.
A bank should not have control over what authenticator app I'm using. Their authenticator apps that they do have are terrible and my security would be improved if I could just use a simple 2FA app. In practice, this is just a way to make it so that DeGoogled devices, Linux devices, etc... won't be able to interact with normal services because they're "less secure". And the companies saying that will be the same ones asking me for authentication over the phone via my mother's maiden name. They don't need this, they're not technically qualified enough to have this level of control over what devices I use.
I honestly don't think attestation should have been part of the spec at all. There is an extremely narrow range of instances where knowing what client/hardware/OS someone is using is justifiable, and in almost all of those instances you should probably be directly controlling the hardware itself (providing a phone for your employees, installing a kernel module, etc...)
And there's nothing official to discourage companies from using attestation other than some vague "but don't do this if you don't need to" language. It's a bad idea that will be used to restrict people's control over their own devices that they own.
At least today these services all offer websites so I can still log on and use them without installing an app. But with attestation we're moving towards a future where you won't be able to log into your bank unless you own a "supported" Android device or an iPhone, and rooting those devices will mean that you don't have access to online banking services all of the sudden.
Good point. I was at my bank last year to discuss a mortgage. It's already a bank I don't feel so good about because their idea of "authentication" is to type a 2FA code that you get from the bank app into the bank app (so you have to type the code in the same app that just gave the code to you!). This really feels like busywork rather than real security.
But anyway was she sat down I saw her log in from a Windows 10 endpoint into a VDI system that was clearly Windows XP (or 2k3 server) judging by the login screen and window decorations. Sigh... I have serious reservations now about leaving my money there.
Of course VDIs are sometimes considered more secure but at my work we have really come back from that idea. Back when wannacry hit on a friday afternoon most laptops had already left the office for people's homes. But the VDI servers were online 24/7 and constantly kept getting re-infected and spreading malware throughout the network.
> And there's nothing official to discourage companies from using attestation other than some vague "but don't do this if you don't need to" language. It's a bad idea that will be used to restrict people's control over their own devices that they own.
Totally agreed, this is also the problem I have with attestation.
This page has a recent comment from a Mozilla employee on Firefox support:
04-24-2023 04:39 AM
We are actively working on supporting this feature.
Here is our current roadmap (might change):
- WebAuthn Level 1 + CTAP2 is riding the trains for Fx 114
- WebAuthn Level 2 + 3 are planned to ride the Fx 116 train
- Passkeys (though details are still about to figured out) earliest completion is Fx 120
I really hope it will come to all platforms though. Not just Windows or Mac but also Linux and BSD.
Between that and completely removing anonymous attestation (i.e. implicit device binding), it makes me wonder what Apple's motives here really are...
Is this the TOTP authenticator app that Google only started actively maintaining again in the last year or so? If that's the case, that's pretty funny timing.
Are Passkeys, at some level of abstraction, permanently replacing "something you know" (password) with "something you have"?
If I am in some kind of calamity (dropped my phone, got robbed, etc), and I come to a friendly person's house, it sounds to me like I simply would not be able to login to potentially critical services, no matter how much I know, because I don't have anything (the device that passkeys are tied to / on).
Is that true?
And... am I the only person completely dreading this system?
I don't live on my one and only phone; I have two phones, 3-4 tablets, 4-5 computers I use regularly. Of various operating systems, browsers, manufacturers, etc.
I can create a password of arbitrary complexity and security and comfortably use all my devices as well as any new device that comes my way.
Passkeys sound... like a nightmare?
(they also sound AMAZING to my wife and family... woohoo no passwords, I just have to use my phone... until they INEVITABLY lose or break their phone... and then they'll come to me and I have no idea what to tell them anymore -- all your passkeys were on your device and now they're gone forever because Google & Apple decided it was better for you, and you did not follow obscure methods I frankly cannot help or explain to you to maybe possibly back them up, one day, when method exists, to some other device)
If you use a password manager today, then you're already essentially using something you have, because you need to be in possession of your login database to retrieve passwords, and nobody can remember that in their head.
Passkeys is a formalization of the idea that you should be using a password manager where all the passwords are random uncrackable 32 character strings, and if we add this constraint then we can crazy secure things like employ asymmetric crypto to prevent phishing and MITM attacks, so woO!.
You are right to be concerned about the whole device thing though. Apple addresses this by requiring that you use/enable iCloud keychain in order to use passkeys. The generalized solution to this is allowing 3rd parties to be your passkey provider, so that you can choose how your passkeys are stored (cloud synced vs device bound) and e.g. whether you want an implementation where you can unlock them with one strong something you know, something you are, something your have, or any combination thereof, the only limit being the features/options the different 3rd party products will offer, depending on their target market, etc.
The password manager I use has no cloud component (which is why I chose it), and addresses this by allowing me to export my password collection to an encrypted backup file.
Would this be a thing that the passkey folks would be OK with? That would ease a lot of my hesitation.
And you can enroll more than one, so if you lose or wreck one, you’re not locked out.
It also makes setup a lot less convenient than a password manager would be. Every time I set up an account I need to set up two devices? And ideally they should be stored in different places, just having 2 Yubikeys in my pocket isn't really doing much for me, so now every signup is literally a 2-step process that involves going to 2 locations.
"Just" is doing a lot of work here.
Luckily, passkey "syncing" and "backup" means issuing a new key that's signed by an old key, so you can in fact have the convenience of paper-based backups if you want (that's how the QR codes work for syncing between passkey managers).
I trust you can appreciate how this improves security in general, by trading some convenience.
Passkeys don't live only on the device. iOS syncs to the cloud. They're not unphishable. You can lose your iPhone, get a new iPhone and get all of your passkey logins without having access to the old iPhone. If someone tricks you into giving access to your iCloud account, they can get your passkeys. Heck, if someone tricks you into doing an airdrop, they can get a passkey from you.
The whole "these are locked to the device" ship has very much sailed at this point.
That's a conscious compromise to security because Apple has decided (I think correctly) that the security gain from blocking backup to the cloud is not actually high enough to justify how much less accessible passkeys would be without that feature.
So I don't buy that it's security that's blocking them from also allowing syncing to other places other than iCloud.
> You are describing the tradeoff made by passkeys, yes.
More to the point though, I wish people would lead with this and not start out by saying, "oh, they're just as portable and easy to back up as a normal password."
They're not, there's a tradeoff here. You can not just make an encrypted vault of all of your passkeys and stick that on a USB drive. And that's a tradeoff that was so severe that every major OS provider got together and extended the standard to allow cloud sync for keys.
Should they have done that? :shrug: But if someone is asking if they can do the same thing with passkeys that they do with their password manager, the answer is 'no'. You can not export all of your passkeys to an encrypted vault and stick it on a flash drive or sync it to another device using syncthing. Your options are a lot more limited, and the way it's advised to get around that is to authenticate multiple devices for each account.
In theory it's something that might be supported in the future? In practice, it's not supported by anyone right now.
Why do the blessed vendors get to do that but not 3rd parties? Syncing your passkeys is just copying the DB to the cloud and then down to another device. If you made a copy of your icloud db, and icloud let you import passkeys (does it?) then you can absolutely make a copy of your icloud keychain and backup/restore it as needed. I don't really understand your point here (everything else checks out though).
That's exactly what we're all asking :)
I feel like you're possibly arguing that the tech itself doesn't require platform lock-in, and I absolutely agree with that. This is a policy issue, not a tech issue (well, attestation, but that's a different conversation). But it's policy issue that's shared by all of the major companies involved in the FIDO alliance and they're very suspiciously against offering any policy solutions or requirements in the passkey specification itself.
There's no technical reason at all why Apple couldn't support syncing passkeys to a local backup that can be imported by other authenticators. From that perspective you're completely right.
They just don't.
In terms of policy, I am not sure all the players share the sentiment. Google stated they understand the importance of passkeys being cross platform. So at least, if their statement is to be trusted, they’re on the side of consumers.
I'm mostly down on the passkey ecosystem and who's in charge of it. I guess I don't do a good job of clarifying that always.
There is a theoretical alternate world where the FIDO Alliance approached this differently where I would be 100% on board with passkeys and would be encouraging everyone to switch to them. I'm just really worried about the implementations I think we're going to actually end up with.
Am I missing something here?
And if you've preemptively set up your friend's devices as trusted devices and given them access to your accounts or like... purchased a second device from the same company and linked it to your cloud account and then given it to your friend to hold -- in both of those situations you'll be fine (but do you want to do any of that?)
Otherwise, yes, you're out of luck by design. You'll have to go through the recovery options for every single account.
But it doesn't, unless you opt to use something like a Yubikey, right? I mean, you can sync passkeys through the cloud...
My wife recognizes the scream from the home office when I try to move ANYTHING from my iPhone to anything else in the world. I have no doubt that backing up the pass keys from iPhone / ICloud to a thumb drive or my windows pc would lead to even more primeval shrieks.
So I feel those pass keys are pretty stuck to that device in practical ways that matter. Let me know if I'm wrong!
So I genuinely cannot backup my own pass keys?
Like, I cannot say "export to file" and put that on a thumb drive and put that in a safe? Make what copies I want?
What kind of dystopian twilight zone where literally "all your base are belong to Apple" (or google or Ms, pick your poison of "choice") we seem to be sliding into?
You can not export to file or store a passkey on a thumb drive.
There have been a couple of claims from various sources that this is coming sometime(tm), but no official word from any of the larger players. I will believe it when I see it.
In addition, if someone does build an Open Source authenticator app that allows you to export and import your keys, there's a capability called hardware attestation that allows login providers to ban authenticators, so there's no guarantee your Open Source authenticator will actually work with every site you want to make an account on.
Think of that like going to log into your bank and being told you can't log in because you're storing your password in Bitwarden instead of the Apple password manager. The current way the spec deals with this risk is by asking very politely for companies to not do that unless they have a really good reason.
I mean, I don't _like_ it (if I'm a passkey folk) as a widespread feature. I suspect users may be tricked into giving away the keys to the kingdom.
However, these are generally just API, there are open source projects for security keys, and having an option to hold down a button on insertion to have it turned into a filesystem with a CSV file sounds kinda neat as a bit of hackery.
There are several third party software implementations, such as those built on top of existing password managers which have pre-existing password export/import functionality and tend to document their data vault formats (or have them torn apart in reverse engineering). I suspect this will happen if it hasn't already - it would be better as a command-line tool and not a button with a wordy pop-up.
My hope is that we have independent certifications for relying parties to rely upon, but lack of certification won't lead to such a bespoke implementation being rejected by anyone. Instead, some sites may ask for you to continue using additional factors since they don't understand if your passkey meets their requirements.
> Instead, some sites may ask for you to continue using additional factors
On the other hand, if that's the result of doing that, then there'd be no gain. I'll end up going through the whole gauntlet anyway.
Yeah, we'll just have to wait to see. Passkeys are just big enough and different enough that I think they are exposing a lot of the holes in existing modeling of authentication.
For example, a party may not want to rely on a separate piece of software or cloud-backed data for authentication, but that is the reality for password managers today, as well as text messages and TOTP for a lot of people. What are these factors that would always survive an attacker getting access to a user device and to their cloud account? You quickly find yourself in the realm of issued hardware key fobs and in-person identity verification for account recovery.
I don't want to trust a 3rd party to be able to restore access to accounts after losing my phone. I've lost several Google and Yandex accounts that way. Despite knowing the passwords, they refused to let me log in again after loosing my phone.
Which is precisely why I would never use an offline only password manager. In the case outlined above, I would need to connect to my online password manager, using the master password I have in my head; which then would allow me to connect to all my services.
How would that work with passkeys ? So far the only way I could see this working is if every single device on earth comes with a fingerprint/face scanner. Because my face and my fingers will always be there for me (hopefully). Otherwise we are back to secrets (aka: passwords).
As to your other concerns. Registering a passkey from each of your devices should be a trivial exercise. If you want to play with this now, GitHub has good integration (you can keep your password, the passkeys you register are just alternative ways to access).
For your family, your concerns are not warranted because the “cloud backup” is part of the integration. With Apple, as an example, the passkeys are tied to your keychain, and changing devices/disaster recovery is relatively trivial. The passkeys are also accessible from all your Apple devices, so you don’t have to create separate ones.
It's already a bad dream for me. I can't stand all the 6-digit code I have to fetch to do things like: check email, schedule appointments, pay bills, just plain buy stuff. I'm glad we're long past the days of emailing users forgotten passwords in plaintext, but I'd prefer to accept less security for the convenience of being able to log into an account without proving my identity via phone.
Sometimes. The authenticator you choose to use sets the policy of what makes a valid authentication. So if your authenticator is "Google Password Manager", it is whatever steps you need to get into your Google account and enable the password manager.
If you do not have the infrastructure to get into that account (say, you have a SMS fallback and your phone is dead), you'll be locked out.
If your authenticator is say a hardware security key, then most likely losing that key means you have no backups.
Even in this case, you can have more than one mechanism to recover access or to prove who you are (even if it is a second hardware key at home in the safe).
Test your keychain access today, “lose your devices” and see if you can still get all your keys through other methods. This is especially important with 2FA.
It is true that you cannot probably access your password without a new “owned” device though, gone are the days where you can hop onto a fresh device and type in your password of your email provider.
1. what's the backup login mechanism when you lose your mobile device?
2. with Passkeys enabled/used, will this stop google from randomly locking my account because I happen to be a person who travels a lot and they constantly think I'm a fraudster attempting to log into my own account.
3a. can I use my google passkey for logging into non-Google sites?
3b. can I use my google passkey (biometric) to log into sites that don't accept "Sign in with Google"? (meaning, other sites tap into my same enrolled passkey biometric)
4a. is the way to think about Passkey is that, it's basically turning your mobile device into an open-standard Yubikey? (meaning, Yubikey is a hardware biometric that you need to be in possession of to login. Passkeys turns your mobile phone to functionally perform the equivalent of Yubikey)
4b. Or is the way to think about passkeys is that’s it’s effectively just a password manager (like 1Password) that you use your biometric to unlock?
5. is FaceID a "passkey"?
6a. can a Passkey be paired with a mobile Drivers license, to effectively create an eID?
6b. if so, would this be a competitive threat to all the KYC offerings that exist in the world (because now you have a verified biometric login that can be used for new account openings)?
Passkeys are synced to the cloud by default on iOS and Android, which is probably a good idea for many use cases, but might not be what you want in some instances.
> will this stop google from randomly locking my account because I happen to be a person who travels a lot and they constantly think I'm a fraudster attempting to log into my own account.
Probably not, but it will make it much easier to log back in – you won't even need to type your password if you use a 2FA-capable authenticator/passkey.
> 3a. can I use my google passkey for logging into non-Google sites?
No, a Passkey is bound to a website. But you can create as many of these as you want.
> Passkeys are synced to the cloud by default on iOS and Android, which is probably a good idea for many use cases, but might not be what you want in some instances.
OK, so how do I use my cloud synced passkey to log on to my Google account (which no longer has a password or other secret that I can back up locally) after I lose my phone?
> Probably not, but it will make it much easier to log back in – you won't even need to type your password if you use a 2FA-capable authenticator/passkey.
OK, but if the account is locked, that just gets them to display the "you're screwed" screen faster (since they don't need to wait for me to type a password), and the blast radius goes from just my Google account to all my other accounts, right?
You don't, in the same way that you can't store the password to your password manager in your password manager. That's why having another way to log back in to your Passkey sync/backup account is crucial.
> OK, but if the account is locked, that just gets them to display the "you're screwed" screen faster (since they don't need to wait for me to type a password), and the blast radius goes from just my Google account to all my other accounts, right?
If you lose both access to your Google account and all of your devices that have your Passkeys locally synchronized, yes. The same goes for somebody taking over one synchronized device and remotely deleting all of your passkeys before you can take another device offline.
I'm personally pretty skeptical of passkey synchronization by default without a way to opt out, but I can see how availability might be just as big a concern for most non-technical users as security.
Gtfo.
Okay, but Google is suggesting logging into their account with a passkey, so how do I access the cloud if I lose the devices with my Google passkey?
> Passkeys use public key cryptography. Public key cryptography reduces the threat from potential data breaches. When a user creates a passkey with a site or application, this generates a public–private key pair on the user's device. Only the public key is stored by the site, but this alone is useless to an attacker. An attacker can't derive the user's private key from the data stored on the server, which is required to complete authentication. > Because passkeys are bound to a website or app's identity, they're safe from phishing attacks. The browser and operating system ensure that a passkey can only be used with the website or app that created them. This frees users from being responsible for signing in to the genuine website or app.
Two is already handled by a good password manager (which every announcement of passkeys leaves out), so the real benefits are in one. Instead of providing the same password each time, you prove that you have your private key in a way only that website (or whatever holds the public key) can ask.
Among the many issues, I think the biggest is that this functionality is being locked behind these large corporations as gate keepers. Is anyone aware of any open source, self-hostable work to provide passkey functionality?
It seems to me not all of it could be since some implementations will require that you prove your private key is stored by a special chips that can be attested which you necessarily can't muck with or reproduce (at least without a lot of effort and maybe running afoul of laws). And there's nothing that guarantees that your keys can be take elsewhere unlike passwords which you can do whatever you want with.
Something else to keep in mind, when they talk about the guarantees of passkeys, they're talking about several other layers of technology. That's why password managers already offer a lot of the security being touted.
Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.
You enter a pin, the web server sees a public key that only your side has the private key to.
I agree - not secure.
And just a daily reminder that biometrics are usernames, they are not passwords. You can change a password, a lock, a key, you cannot change biometrics, and thus they should not be used for guarding sensitive info.
The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.
Please provide evidence that biometric data has ever been extracted from a major platform (IE Apple/enclave). Absence of evidence != evidence of absence, I know, but you’re selling it as the only use case so surely you have proof.
Why extract it from a platform when it can be extracted easily from the person? Imagine your password was written on every surface you touched (fingerprint) or is prominently displayed on your social media accounts (face).
The biometric doesn't exist until you enter your PIN on restart, which is what unlocks the filesystem (including the biometric profile).
You'll also see that you can change your biometric with just your PIN, but you cannot use your biometric to change your PIN.
If the algorithm is not known, it’s only a matter of time it’d be leaked or reverse engineered. And then suddenly there’d be a massive, difficult to fix security breach. Just like the breaches that we have now, with voice based authentication.
Can someone explain, how this can be mitigated?
Your face geometry is used to allow access to a secure processor (trustzone/Secure Enclave/etc) which then signs the web token.
Which is why the phone is the “something you have” piece of the puzzle here.
But if this is used only to unlock the trust zone/secrets, I guess that works. It seem to be extremely dependent on the device not getting locked up accidentally, lost or damaged. If a damage would lock you out from all of the accounts, this seems rather drastic.
Everything you’ve described can be done whether or not I use biometric to sign into a device, or even own a device?
While I see where you're coming from, they really aren't just usernames. It's not like I can log into your e-mail account by typing VoodooJuJu and pressing Enter.
I think you should stop giving out this daily reminder. This meme has outlived its usefulness.
Using face id to unlock a local key store to enable my device to sign a signed challenge from a site I want to log into with the private key stored on my device is not a 'username' in any meaningful sense.
The problem is, the metaphor about passwords and usernames is not a good, structure-preserving simplification of the actual problem of authentication.
The biometric data and/or pin code are not being used to prove that you are you to Gmail, it's being used to unlock the set of private keys you have on your device. This doesn't fit into the metaphor at all.
If my non-technical parents said they were migrating all their accounts to passkeys, I would be very pleased. I wouldn't be worried about their inability to change their biometrics and that causing a problem following some sort of breach in the future. I am highly worried about their extreme susceptibility to phishing, especially in their inability to distinguish phishing sites from real sites, or real account maintence contacts via email and SMS from phishing contacts, their reuse of very simple passwords that are probably circulating in combolists already, and their general inability to retain username/password pairs. I have a lot of sympathy for them when I try to talk them through something like logging in to an Apple device with their apple id, when their appleid username is their email, which ends with @gmail.com. "But...why would i log in to apple with my gmail?" nevermind how confused they are about 'log in with google', 'log in with facebook', etc.
Moving to a model where their devices store webauthn credentials and guard them with a pin or faceid-style biometric shortcut is a _massive_ improvement in practical resistance to account takeover for my parents, and I don't think continuing to say 'biometrics are usernames in authn' is accurate or helpful.
My 76 yr old dad can't do it. His phone is some shitty android trash that when he's setting up his biometrics, he shakes a bit, and it never stores the finger data correctly. I have to hold his finger and his phone at the same time to even scan it. Then, unlocking is also super unreliable because of the shaking. He refuses to get a better phone cause this one "works well enough."
It's no surprise that the tech industry, which largely employs urban, educated 20-somethings and 30-somethings, tends to produce products aimed at urban, educated 20-somethings and 30-somethings.
Stick your finger inside of a dynamically sizing aperture, or clip a finger reader onto your finger? If both the finger and the reader shake the same there shouldn't be a problem.
That doesn't solve the general touch issue, but it solves this particular case.
But sure, I agree (https://news.ycombinator.com/item?id=35790638 ). I'm just trying to come up with some workable solution. Not trying to make the best of all possible worlds.
Essentially every biometric has a population they won't function well with.
Security is HARD. There's no getting around that. Your data is valuable and protecting it is not an easy task. At some level, security and convenience is a zero-sum game.
As for old people, my dad writes down his passwords on a text file in his laptop and has a printed backup in the house.
And, yes, he does have to bug me sometimes to re-login or change a password, but we've never had a security problem, which is way more than can be said for a lot of people who tried the INHERENTLY unsafe "3rd party manager" thing.
No it's not.
The security triad is "something you are", "something you know", and "something you have". Fingerprints are something you are. Usernames are something you claim to be.
The username is the "claim" you are this person. The password is the "proof" you are.
If I'm fingerprinted by any federal agency today (and my fingerprints have been on file with the government since the 90's for a security clearance), then my fingerprints can serve as absolute proof of my identity. This is helpful to me should my identity ever be stolen and I need to show absolute proof of who I am.
But given the relatively high level of laziness, capriciousness, and general failure all around that is "IT security by means of companies who are rarely held accountable," it's good to point out that this is what makes biometrics worse than usernames and should probably mostly be avoided, or at least optional.
Sure fingerprints, face scans, and iris scans can be stolen as well. But certain things are really hard to fake, including potentially, scans of faces and an iris scan at the same time -- unless you can somehow graft a new iris and grow a new face.
Put it like this: a dead victim is found naked along the side of the road. Which leg(s) of the security triad can the police use to prove the identity of the victim?
Google, who I don't pay and doesn't owe me much, not so much.
My apple touchID never works because I rock climb and I guess that abrades the skin too much
Relying on fingerprints to gain access to things on a regular basis never seemed like a great idea to me.
Bodies are not invulnerable to damage. You can absolutely change your "biometrics", you just probably wouldn't _want_ to.
The three factors of authentication are:
1. Something you have
2. Something you know
3. Something you are
Passkeys are typically 1+2 or 1+3 — you'd need to have physical access to the device either way.
I don’t know what “proper 2FA” means but the gold standard today is U2F, and it has failed to be mass adopted due to requirement to purchase and maintain another device.
Most sites already don't store the password. If you have a sufficiently strong password (i.e. very long, randomly generated, stored in a password manager), it is likely not computationally easier to recover the password from a hash than it is from a public-key. The only improvement here is that you don't have to trust that the site is following best-practices for storing passwords, as you never send them the password.
[edit]
It also prevents phishing attacks for those using some form of entering a password other than autofill from the password-manager.
Thus, even short PINs can provide strong security since the attacker gets, e.g., at most 10 tries to guess it out of 100k possibilities for a 6-digit PIN.
Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)?
I must be missing something, because I can't see how Google would call something e2e encrypted if the keys only have like 30-35 bits of "effective" entropy after a KDF. But that seems like it's the case??
[1] "From the user's point of view, this means that when using
a passkey for the first time on the new device, they will
be asked for an existing device's screen lock in order to
restore the end-to-end encryption keys"
[2] https://www.omnicalculator.com/other/password-entropy?c=SGD&...
The PIN and key derivation wraps the actual encryption key that's stored locally in the device or secure enclave, not the actual secrets that are stored in the provider's cloud. The actual wrapping keys are random 256 bit AES-GCM keys. This approach works because the secure enclave provides measures against bruteforcing and tampering.
There is some controversy that I can't find an explanation for in any whitepaper, specifically here: https://support.apple.com/en-us/HT202303 where it reads "(...) this data remains secure even in the case of a data breach in the cloud. If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key." because that implies off-device use of the PIN, so those measures are lost. There's no further explanation that I could find about that. Some previous discussion about that particular point here: https://news.ycombinator.com/item?id=33897793&p=2#33900540
> This approach works because the secure enclave provides measures against bruteforcing and tampering.
That's interesting!
> because that implies off-device use of the PIN, so those measures are lost
This link from your previous thread is interesting: https://support.apple.com/en-sg/guide/security/sec3e341e75d/...
Uses SRP to let the device prove to iCloud HSMs that the user entered the correct pin, without ever sending it over the wire. The HSMs have similar protections for brute forcing, etc.
From the docs I have a fairly high confidence entropy is 256 bits for iCloud Keychain. I have much less confidence on Android, but I'm still researching... :)
This thread really smells like https://xkcd.com/538/. Three things you have to remember, that are far more important than any of the concerns you have:
1) The effective entropy of the current system (passwords) is "shrugs shoulders fuck it not our problem". Services can enforce password entropy requirements. They cannot effectually require users to use a unique password. They also cannot forbid users from writing the password they use in a .txt file on their desktop or post-it note or throwing it in Apple Notes (EVERYONE does this outside of our bubble. Apple Notes and Excel are the #1 and #2 password managers on the planet). A six digit pin + hardware TPM key derivation is, at best, the same thing that was guarding how most people store their passwords anyway, and in many cases far better than the current state (if a user's device has no E2EE, or if they're syncing their passwords.xlsx file with Dropbox, etc).
2) Passkeys do not and are not designed to protect against nation-state level attackers. Passwords weren't either. They also don't protect well against the "grab a hammer and beat it out of him" threat vector; you're going to give up your password, and tomorrow they'll probably have your iPhone and your passkeys will be disclosed as well. Passkeys are designed to protect against unsophisticated (and even moderately sophisticated) attackers; phishing, data breaches, etc.
3) If you want higher tiers of entropy guarding your passkeys, you can do that. 1Password, as an example, already has this [1]. They store passkeys, and encrypt those passkeys with their two-level account & master password keys. Done! If you don't like 1Password, you can roll your own, and I'm sure OSS password managers like gopass/keepass/etc will eventually add this. Passkeys/WebAuthn don't prescribe to anyone how you store the private keys; Apple will do their thing, Google will do their thing, you don't have to use them, many people will, and they'll be better off (see point 1).
Thank you. 100% agree.
> Passkeys do not and are not designed to protect against nation-state level attackers
I've been mulling over some use-cases where this is important, hence the deep consideration over entropy. 100% not a huge deal for the passkeys case for many 9's of people.
Slightly off-topic: If a website will not let me register and complains that my password is too long, they're still storing that in the underlying database as a properly-salted (modern algo) hash, right?
2FA via SMS is still vulnerable. 2FA with an app like Google Authenticator or VIPAccess is more secure because it is tied to a device.
Tied to a phone (as opposed to some security-specific device like a Yubikey) is a terrible idea.
It ties your authentication to something that is often lost or damages, but more importantly, something that is controlled by a third party (apple or google) and requires an expensive monthly subscription to yet another third party (your cellphone company).
TOTP is not tied to a device which is why it's a beautiful solution. You can store it where you wish under the controls you wish and back it up as you wish. You are fully in control, dependent on nobody.
Your password manager is likely the exact same thing. The underlying implementation of this is typically a system or third party password manager which added a public key-based credential type for sites. For an Android phone, this is Google Password Manager by default. For iOS, it is iCloud Keychain. Third parties like Dashlane and 1Password have indicated support for passkeys.
I would have thought your interpretation would be that this was strictly better. Even if the credential database leaks for a site, the attacker can't do anything with it - all they have is a public key, specific to that one site.
> Or at least just having proper 2FA.
If I use my android phone to log into a website, I have done 2FA. I have physical possession of my phone, and have used a gesture, PIN or biometric to confirm who I am.
The difference is in the password case, the website has no idea that I did that - all they saw is the password. With a passkey, it is possible that a site would recognize that I did a stronger, multi-factor authentication.
This may have varying strengths as a physical factor - say, provisioned database of credentials onto a device using MFA vs a FIPS-certified security key fob, but I would still argue it is "proper" 2FA.
It's a bit disappointing seeing them re-affirm SMS as a a more vulnerable form for 2FA when Google's stance has been to try and force a phone requirement on Google accounts that lack them in order to login—and then using the phone for SMS 2FA.
In the past number of years only after a phone is attached do other 2FA methods like TOTP become accessible as options.
However even when a phone is added Google continues to utilize SMS 2FA over them for what are deemed important actions like Takeaway or auth keys, in my experience.
This is despite known issues like SIM swapping, lock screen messages (viewable by anyone with device access) and due to the prevailing use of SMS for 2FA users have been prepped to accept security codes via messages which is arguably more exploitable than app-based TOTP in scams where fraudulent messages are known to be used alongside calls to mislead users into gaining trust then subsequently requesting a real 2FA message[1].
I do always see these comments on HN and I think "Huh, really?" and I go check and, nope, Google doesn't have my phone number, but they do know I have security keys, so that's all working as intended.
A few years back I was logging into a new machine from a known network. I provided the correct username, password, and TOTP on the first try. Google then forced me to authenticate further by providing my phone number _in the sign in flow_ to receive an SMS. This is pure theatre as I could have provided any number. No security was gained. Google does, however, now have my number. Even if it isn’t displayed on my account.
Theoretically, passkeys could still offer this advantage if they are stored exclusively on my phone which is encrypted and secured with a password.
Which countries?
In the US, the intersection between 5th amendment rights and password disclosure is not complete. You can be forced to disclose a password in certain circumstances here.
With biometric data like FaceId or fingerprint it's easier for them to get access.
Wherein it mentions passwords are considered testimonial and therefore protected by the 5th, but device passcodes were ruled to be exempted under the “forgone conclusion” exception to the 5th (TIL about that).
Is this kind of thing you are referring to?
A ton of people in our bubble have this Mission Impossible-esque view of their security footprint, which simply isn't true in reality. Its XKCD 538 every time this comes up.
A password (at least as I understand the term) is used to authenticate to some third-party entity to get access to your data or services. The (implied or legal) contract here is: "Only give access to my data to anybody that can provide my password."
Government authorities can in most cases just go to the service and demand that access legally; there is no need to get your password through whatever means.
A passphrase, on the other hand, can be used to encrypt your data directly, and the service provider might not be able to hand over your data to the authorities without it.
Oh? Nowhere? Then why you're even talking about the distinction ?
Also passphrase definition is definitely not "a password used for encryption", I dunno where you pulled that from. Original meaning is just "longer, more secure password"
GP was talking about the legal implications of using a hardware authenticator vs. a password.
> Original meaning is just "longer, more secure password"
And where do you usually need a longer, more secure password? Encryption (as opposed to authentication, where you can often rate-limit attempts) immediately comes to mind.
> I dunno where you pulled that from.
From https://en.wikipedia.org/wiki/Passphrase:
[...] , especially those that derive an encryption key from a passphrase [...]
> Passphrases are significantly harder for e.g. Greykey to glitch brute force than PINs.
PINs are their own thing, i.e. neither passwords nor passphrases. They form a hierarchy:
Passphrases: High (enough) entropy; can be stretched into an encryption key using a PBKDF.
Passwords: Medium entropy; long enough to be somewhat brute-force resistant in case of a database breach. Can't really be used to encrypt data by themselves.
PINs: Very low entropy, must be part of a larger, trusted system that can reliably enforce limits on invalid PIN attempts. Practically, this means tamper-resistant hardware, e.g. a HSM, TPM, smartcard, Yubikey...
https://en.wikipedia.org/wiki/Third-party_doctrine
---
You're introducing key stretching for unknown reasons. It's irrelevant for attacks on e.g. iPhones -- they're not cracking encryption, they're doing dictionary attacks.
Passwords are amazing. I loathe many of the attempts at replacing them simply because the _average_ user has proven to be unable to manage them.
The three factors of authentication are a thing because they all protect against somewhat orthogonal threat vectors.
Possession "have" is nice because it binds the authentication to a single thing in the real world (as opposed to some digital thing that can be copied endlessly). Biometrics, if nice, is something that is relatively unique and always carried with you (mostly identification), and bind the factor to a person, secrets like passwords are nice because they essentially bind the factor to the intent, in that a user displays their secret behaviour (of which passwords are one) as opposed to not displaying the behaviour.
Articles that solely focus on the downsides of passwords, often neglect downsides of the other factor types. What are ways the strong personal binding of the "are" factor can be abused if there is no intent? FaceID/TouchID on sleeping or otherwise inattentive persons is a prime one.
All factor-types can work in ways that complement eachother. Removing or at least weakening passwords is not a good way forward, we need to work on fusing all the factor-types jnto a single strong 3-factor auth
Would this not make logging into things three times more painful? Even just using 2FA is a pain right now.
The three factors of auth are categories / types. TOTP, password-entry into a form, biometric presentation, etc are _measures_. Sometimes the first measure is not sufficient, because it only implements one factor-type (e.g. the secret knowledge password), and a second measure that like TOTP is necessary which proves possession of something to a degree.
The time between proving one measure and then the next 2"F"A measure allows many shenanigans (e.g. social engineering to get me to send a TOTP code to my down-on-his-luck "son").
What I am professing is a focus on measures where proof of all three factor types happens at the same time.
PIN codes as entered to unlock a private key on a smartcard, which is then used to sign some other thing, would be one example of a 2-factor measure. Another is FaceID/TouchID (on-device matching).
But 3-factor measures are not impossible - e.g., take also the keystroke dynamics into account of a password being entered on a specific device, apple could implement "KeystrokeID".
Other options can exist, it just takes some creativity to think of how a secret behaviour can be encoded into a biometric modality that is then only understood by a specific device..
multiple factors do not provide perceived user benefit. They benefit the party who is providing service and exposed to risk.
The old Battle.net authenticator made it harder for my account to get hacked, sure. But I had a process, involving real people behind the scenes at Blizzard, to recover from that hack.
They didn't create the authenticator as a measure of altruism to users; they created it because hacks are expensive. This is why they would regularly reward users for enabling the authenticator with various items/DLC.
Now the reality is that if I get hacked multiple times, they may refuse to restore my account. They might not be able to restore my account with available information, or it might take ages due to a large scale attack (such as someone managing to deploy a key logger via zero-day browser exploit, if we are speaking to personal experience).
Services have good reason to not trust users to have good password hygiene - most do not, and breach lists only go so far to help alleviate the problem. SMS is expensive, but even sites with lower security needs use it because the alternative of recovering user accounts is more expensive.
> All factor-types can work in ways that complement eachother. Removing or at least weakening passwords is not a good way forward, we need to work on fusing all the factor-types jnto a single strong 3-factor auth.
This is likely not going to happen for anything outside of government use cases.
Biometrics on most consumer hardware are a "shortcut" for a cached knowledge factor, like a device unlock PIN on boot. They cache the knowledge factor because entering passwords constantly is a lousy experience. Likewise, changing a device biometric to match other people can be done with just the knowledge and device possession factors.
Maybe one day we will have embedded neural hardware which will transparently meet all three factors, or maybe there will be really clever solutions with all-day VR hardware, but today's consumer hardware doesn't support three factors, because the biometric factor is just an extension of the knowledge one.
- syncs to the cloud without E2E encrypted. there's no reason any person should ever put all their private keys somewhere they can be stolen without at least a secret master password protecting them.
- they're not one standard. web apps will use WebAuthN, non-web apps will use a FIDO API. Passkeys are a mix of different technologies that is more complex than needed.
- they aren't interoperable with different software and devices. Currently, if you make a passkey, it can only work with whatever you used to make it. trying to use a passkey on different operating systems or apps etc requires manual workarounds, exporting/importing, etc.
- different providers have different levels of support. some support sign-in, some support MFA, some support both.
- the choice of only being able to use biometrics or a pin to protect the passkey store is stupid. you should be able to enter in text as well, so you can use a long and complex key to protect it, if you want. instead your options are 3 incredibly easy to crack methods.
- there isn't an easy way to back up everything offline in case your devices get lost.
- all this doesn't address attacks on account recovery, which is the most common way to compromise an account (nobody brute-forces passwords anymore, with the exception of giant password compromises which are used for lateral attacks against other services)
Those passkeys are asymmetric cryptographic keypairs where the private key is securely stored on a device, unlockable (for use, not reading) only by convincing your devices security processor to do so by pin/fingerprint/pattern. Which in itself can be secure, given you do trust that magic security processor (which you shouldn't, see yesterday's news for example). However, if that key cannot be read, you cannot make a backup of it, so it will be unrealiable and easy to loose. The recovery process will either be insecure and prone to social engineering, or unreliable because proving your identity will be nigh impossible without that passkey. Now one could allow backups of a passkey, but then that passkey would be as insecure as a password. One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.
In all a bad and dangerous idea.
Which would be easier to use and more effective.
Programs such as Bitwarden already do this, where you send the hash of your password to the server instead of the password itself, because from the password you derive the decryption key and you never want that reaching the server. You then use that hashed password as the authorization password, but the client uses the actual password to decrypt the delivered password vault.
The value the user's browser sends back can't be reversed, so any website prompting from the wrong domain would only ever see an incorrect hash, rather then the cleartext as it does now.
On top of what you mentioned, it also fails really hard when someone has access to you and your trusted device (which will be the smartphone in most cases). It's already an issue allowing easy access to smartphone content, it will extend it to any account using that method of authentication.
FWIW, asymmetric PKI is technically mature and relatively easy to implement in most applications (without "vendor lock-in", I might add to comments upthread), and there are ways to address most of your concerns about key loss and recovery beyond what you describe, as by the ring of trust scheme Apple uses, for example.
The only way through this is forward. I'm confident it really will get better once passwords become a smelly indicator of bad security practice.
If passwords are like playing poker with your cards facing out, Passkeys are like playing with your cards facing in. Your secrets remain under your full control at all times. Nothing sensitive is sent over the wire.
Yes, for everything. Those who've implemented it so far have done a great job at making it /easier/ than handling passwords.
If you've ever used ssh with keys instead of passwords, it's the same thing, and it's so much easier while being more secure. A rare convergence.
The way this typically works is that the keys are stored in an encrypted file, which can be backed up securely as-is. It can also be copied around and sync'd to other devices.
Of course, this means the authenticator app/service that needs to use the private keys to respond to challenges has to be able to decrypt that file, which means logging in to it. Authenticators balance convenience with security in terms of how often you need to fully log in to it. They are also often configured to require a light-weight authentication on each use (fingerprint, face, pin).
With authenticator apps handling the private keys, secure backups should be easy and automatic. Things should improve since the people using passwords now who don't have a secure automatic backup mechanism for them and switch to passkeys will probably end up with an authenticator that does it automatically.
(Recovery processes will still exist and can still be an issue.)
That's literally part of what makes a passkey a passkey (v.s. just a WebAuthn credential), so that's a given.
> as insecure as a password
No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can.
There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".
> One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances.
What? Malware stealing your password is "more secure" than malware registering it's own malicious key to each individual site it wants access to?
Passkeys don't need to be cracked after a data breach of your backup provider, they are just usable, right there.
> There are so many ways passkeys are superior to user-memorized passwords from a security perspective, it's laughable to call them "as insecure as a password".
Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily. That makes the attack surface top copy over some passkey far larger than for sniffing a password.
Let's take Apple's implementation as an example (since that was the one I could most easily find information on). Their implementation stores passkeys in the iCloud keychain[1], which is end-to-end encrypted[2].
[1]: https://support.apple.com/guide/iphone/sign-in-with-passkeys...
[2]: https://support.apple.com/guide/security/secure-keychain-syn...
I think you're mixing up server-side and client/sync-backend-side compromises here.
For the former (i.e. a compromise of hashed passwords and their corresponding salts), you'll need to rotate all passwords since the hashes can be brute-forced. For passkeys, all an attacker gets when compromising a service's database are public keys that can't be brute-forced and key handles that don't give an attacker anything without the corresponding authenticators.
For the latter, the situation is exactly the same for passkeys and passwords in a password manager, i.e. both are as secure as their on-device storage and encryption in transit and rest at a synchronization provider (if any).
This does not make it as "insecure as a password". It does mean you can use root/OS access to exfiltrate keys, but it closes the following security holes that affect passwords:
- keyboard sound-based exfiltration[0]
- visual exfiltration (someone recording you enter your password, or looking over your shoulder and memorizing it)
- credential stuffing, where people who reuse passwords get pwned when the same leaked password is used on other websites
0: https://www.independent.co.uk/tech/cyber-security-passwords-...
Passkeys are just asymmetric key-pairs. There will be a variety of client-side implementations. Some may make export and backup difficult or impossible. Others, such as 1Password's already extant implementation advertise backup and synchronization as a feature! There is nothing about the passkey standard which prescribes the reality you fear.
> Now one could allow backups of a passkey, but then that passkey would be as insecure as a password.
Wrong, absolutely and entirely. Its still more secure, because its an asymmetric keypair, and you're forgetting about the far more common attack vector against password disclosure: service breaches. That's how attackers learn about passwords by-and-large. And this is not just some nice-to-have side-benefit of passkeys: its a core motivation of this standard. With passwords, a service breach compromises not only the accounts of every user on that service, but potentially every other account every user has, globally, because of password sharing. With passkeys, all of that is resolved.
Even if we end up with a system that is the same level of effective client-side security, which is also extremely wrong, the net security of the system will be vastly improved because service providers aren't storing the private key used to authenticate user accounts.
But the client-side security is also substantially improved, because passkeys have much higher phishing resistance.
In comparison to those, Google’s support seems better. It worked, was transparent about what was going on, and gave me the option to create the key on either the device I was using or another one if I wanted. The one hitch was that when I already had a 2FA key on the same platform authenticator, it just said I already had a registered key on this device and didn’t do anything. I would have expected some sort of upgrade flow for people who previously registered their devices for 2FA, or at least to more directly tell me to delete the existing security key on the device (which is what I did, and which worked).
Is this Android? Because, before this change, there was no way to register a real WebAuthn-based passkey with Google, at least when I was trying with chrome (it did not prompt the webauthn popup, just the OS-native security key popup).
At that time, I inspected the registration request Google sent to Chrome and found it was passing a private option that Chrome recognized. According to what I found in web searches for it, the option created a legacy U2F key, and they needed to do that because there were existing Android devices that they could not upgrade and that would not support log-in with WebAuthn keys.
[1]https://security.googleblog.com/2023/05/so-long-passwords-th...
But they may separate into several companies to avoid conflict of interests, if they prefer, this time with proper support and everything. Or they can be forced to do so, if they are too stubborn and will continue running their dystopian playbooks.
So, the situation is not strictly technical, it's much deeper than that. A blog post won't make a dent.
I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built.
What happens if i lost all my devices due to a fire? at least a password let me still access things we these i might need to prove again that i am me, it might even be more easy to steal accounts because i can ask google to change it because i lost my passkey.
A password manager with strong passwords is weaker than a password manager with passkeys, because passkeys use asymmetric crypto and passwords+2fa involve exchanging a shared secret over an insecure channel at some point (yes I'm considering 1-sided TLS an "insecure" channel here).
Trust the security experts when they say passkeys are more secure. Now, solving the UX to make it match that of passwords plus managers today is the problem, agree.
This is in fact the only possible solution you get on iOS, and the default solution on Android.
I trust the security experts when they say passkeys resist various attacks better than current systems...
> Now, solving the UX to make it match that of passwords plus managers today is the problem, agree.
... but poor UX makes it likely the users will end up doing things that are less secure, not adopting them at all, or messing things up themselves in such a way that they lock themselves out of their accounts.
So until the UX issues are fixed, "more secure" only in the narrow definitions that sophisticated security folks worry about. If the folks I support blow it, it doesn't matter that some mostly theoretical MITM attack was prevented.
I also believe that Apple/Google/Microsoft understand the importance of not having a "I lost my device all my stuff is toast" UX, which is why Apple requires iCloud keychain to enable passkeys. They are making a pretty strong statement that the UX they imagine working for the masses is not some rigid "no cloud no syncing not here not ever" stance. So I think they realize it has to be a solution that doesn't have that failure mode. They're okay with soft keys, which is at least a relief.
Either have to prove that m me to my account provider, which essentially is huge security hole since what data it will be required to prove might be more easy to fake (kinda like how people do sim swapping) and stole my passkey or do the "crypto thing", that if you lost your decryption key all your money is gone forever and ever and start fresh.
I mean my point is... password are not going to be deprecated, we had so many attempts to murder them but their convenience outmatch any other solutions, feels like passkey aren't well designed imho if the backup requires a password, then passwords won't be deprecated... maybe passkeys aren't meant to replace password but long-sessions oauth tokens if you ask me why passkeys exists.
TOTP/HOTP solves the first problem by making the credential provided during authentications single-use, but they're still susceptible to phishing/MITMs (since you don't know where you're entering your OTP).
WebAuthN solves both.
> What happens if i lost all my devices due to a fire?
Passkeys are synchronized to your device ecosystem vendor by default (i.e. Google or Apple, and soon also third-party password maangers on Android), for better or worse.
And at that point they make a full circle becoming just passwords with a master password. Essentially what password managers already do. You already can tie a master password to a biometric or another factor.
That's a showstopper for me, personally. Not saying the idea is a bad one (at all!), but I won't be using it for myself.
Even then I would probably not add my bank credentials or other high-sensitivity things there.
Last time I read about this, you could use your phone or a FIDO key to authenticate. Like if the phone was close to the computer you could aithenticate the same way you can unlock your computer with your watch.
So either this new technology is so advanced lesser minds don’t understand it or it jus adds a more cumbersome authentication method instead of passwords and its adoption rate will be in single digits.
Is my understanding correct that if I only used Passkeys that I’d be permanently locking my account to a third party service to the vendor I used to login with in the first place?
I’m also a bit worried that this permanently entrenches these as the platform vendors because no one is going to port to a new platform unless you’re already a major tech company (maybe).
If your desktop/laptop has TPM, TrustZone or other similar devices, it can register Passkey too.
[1] https://9to5google.com/2022/10/12/android-chrome-passkey-sup...
What would be nicer if there’s a way to do this in Chrome on mobile. I’m not always near a computer although I’m reality that’s probably when I’d be adding the passkey via chrome.
Exactly — I just did this, and it's that simple.
I don't know if this will be universally true among sites that support passkeys, but Google allows you to create multiple passkeys per account.
> Using passkeys does not mean that you have to use your phone every time you sign in. If you use multiple devices, e.g. a laptop, a PC or a tablet, you can create a passkey for each one. In addition, some platforms securely back your passkeys up and sync them to other devices you own. For example, if you create a passkey on your iPhone, that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account. This protects you from being locked out of your account in case you lose your devices, and makes it easier for you to upgrade from one device to another.
> If you want to sign in on a new device for the first time, or temporarily use someone else's device, you can use a passkey stored on your phone to do so. On the new device, you’d just select the option to "use a passkey from another device" and follow the prompts. This does not automatically transfer the passkey to the new device, it only uses your phone's screen lock and proximity to approve a one-time sign-in. If the new device supports storing its own passkeys, we will ask separately if you want to create one there.
In addition to this, you can AirDrop a passkey from one device to another, even if they don't belong to the same iCloud account.
However, a sibling commenter mentioned QR code export/import. That would alleviate the concern and be even more elegant, especially if it automatically created a new passkey registration instead of just copying it around.
No lock-in; you have two phone OS vendors to choose from!
I am not sure I like this. Unless the passkeys are only transferred directly device-to-device, each OS vendor's user cloud storage now becomes the keys-to-every-kingdom uber-target.
> Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on.
[1] https://support.apple.com/guide/iphone/sign-in-with-passkeys...
(manages customer IAM for a FinTech)
Hopefully in the future OSs will have better APIs to allow third-party tools like 1Password to leverage hardware components like TPMs and Secure Enclaves to build a sync fabric that's not tied to the hardware vendor, but this does not currently exist and is not trivial to implement without significant consideration about phishing.
I think YubiCo and password managers have a tremendous opportunity here to partner up to build sync fabrics bypassing OS vendors that might not be as incentivized to provide these APIs now, but I don't believe it's moving, currently.
Additionally, when you say you wouldn't trust Google or Apple to be the _only_ place your passkeys are stored, it's likely that even if we can have third-party sync fabrics, that these will never be interoperable. I don't believe you'll be able to "export" a Passkey from your iCloud ecosystem and import it into the 1Password ecosystem as you can do today with passwords. Doing so would break assumptions about the strength of the authenticator as far as WebAuthn is concerned, and would weaken Apple's security posture as well. Instead you'd probably have to maintain _both_ sync fabrics independently with every service you sign up for.
Before, you could just sign in to your password manager on the new platform, and get a 2FA prompt the first time you sign in to any particular site (so you're manually entering one additional factor per site). With passkeys, you have to do account recovery, so you have to manually provide two factors per site. That translates to hours of cumulative extra work.
It's an opportunity to increase platform stickiness, backed by a flimsy security excuse. Nobody using a password manager is getting their accounts hacked unless the vendor is breached or they have malware on their system. Passkeys don't help in either scenario. And the UX isn't materially better than the built-in password manager, though I guess that's a matter of opinion.
What is necessary is a robust, simple-to-integrate standard for authentication, authorization and sessions built into HTTP. Such that all the "hard work" is integrated into common HTTP server software or load balancers, transparently. From an application perspective it should just look like your request getting HTTP_USER=someone HTTP_PERMISSIONS="stuff,foo,bar" HTTP_SESSION="0xdeadbeef", similar to what you get from HTTP basic or negotiate auth, but with a few more necessary features such as session, login/out and a permission model. Browsers would have to provide some proper UI for that, not utter crap like they currently do for HTTP basic or negotiate auth.
Then your centralized auth application can just talk to any old application in a very simple way, no need to deal with huge integration headaches like OAuth or stuff. And the centralized auth application can do all the fancy password killer, 2FA, magic or whatever special auth you need.
Ideally there would just be standarized interface between "credential manager" and applications + some OS-enforced security (so password manager knows which PID sent the question about password or other type of credential).
Then we could have say pub/privkey or cert based authentication implemented there, app just asks for a credential for a site and cred manager asks user whether to allow it once or forever, and which credential to give.
The app then could garnish that with extra metadata so say firefox container feature, or different firefox profile could attach metadata about from which container or profile the request comes from, and credential manager could hand out different credentials based on from where it came.
iOS has an API for password managers and HOTP/TOTP authenticators. Android is planning to introduce one for passkeys.
First is that this changes from 2-factor authentication (something you have plus something you know) to single-factor (just something you have).
Also be sure to notice in the article that they have changed their term there to 2-STEP authentication, not 2-FACTOR authentication, these are not the same thing, and they know that. It's important that you know the difference too if you want any kind of real security. If you use passkeys plus an authentication code app, then you have 2-steps (for whatever that's worth) but not 2-factors since they are both just a piece of code on your device, if they are both on the same device, that's even less secure since they can both be compromised at the same time, and in practice they will be.
Second is that the now single factor authenticator is strictly worse than a password because it is something that can be taken away from you and manipulated without your permission.
Third is that the keys are not private since the passkey provider is storing them for you and/or copying them around. This means they can be spied on, stolen, or demanded by the government, all without you even knowing someone else got access to your stuff.
The last glaring issue I can see for the time being is that it relies on a simple, easily cracked unlock pin, or worse still fingerprint/facial recognition bio-metrics as the only way to keep someone, other than Google, out.
One might be tempted to think facial recognition or fingerprints are pretty good security but it's already been demonstrated that people can break those mechanisms quickly and the cops can and will use your fingerprint and/or mug shot to unlock your phone if it's locked by biometrics only. They are not allowed to force you to give your real password, but the courts do allow them to use any means they like to break into your phone. Even if they damage it in the process, they just have to pay you back for it, they still get to take your data and use it against you.
Just some things to keep in mind before anyone gets too excited about this "new" invention. There's a reason we still have passwords even though we've had Smart ID Cards (such as DoD's CAC system https://www.cac.mil/) and other device driven access controls for decades now.
For the case of passkeys, expect the bad actors currently playing the phishing game to shift from getting you to enter your password on a fake site, to getting you to install an app that either triggers the push notification to send the passkey or has a way to lift the passkey off the device directly. And in order for this tech to be useful, it will have to be expanded to cover nearly all sites and services available on the internet. So phishing will still happen in the form of bogus sites and services getting past whatever app verification equivalent process Google tries to put in place for services that would like to integrate with their passkey provider.
My claim that the passkeys are strictly worse than passwords applies specifically in the sense that, as a form of authentication, passkeys do not prove that the person logging into the site is actually the person they say they are. Passwords prove that only in the case that no one, who is not you, knows your password. Passkeys only prove you are who you say you are in the case that no one, who is not you, can unlock or otherwise get access to your networked and only loosely secured smartphone. It is easier to hack or steal a phone than it is to read your mind.
Though I grant you the point that one doesn't always have to read the mind, only trick it into giving up the goods. Fair enough but that is still the owner of the password DOING something whereas phones can be broken into through the network, through something the user did (like downloading malware), or through something they didn't do or know to do (like downloading updates).
It can also be broken into by way of something the owner had no control over, like a supply chain attack on app or system updates, a compromised third party service for one of the legit apps you have installed, or a zero-day hack for an app or the system itself.
Those situations are exactly why password systems must be designed NOT to store the password on any devices, whether that's a file on a phone or laptop, or a cell in a database. Every time the password is written down, it is effectively already compromised as an authentication tool because it's no longer just something you know.
This isn't theory. Design should be data driven rather than ideologically driven.
> It is easier to hack or steal a phone than it is to read your mind.
Mind reading is observably not the only way to obtain somebody's password. As you say in your next paragraph, this is extremely important when considering passwords. Plenty of things work great if you simply exclude all the cases when they don't work great. Everybody sucks at detecting phishing, even security professionals. This is demonstrated through clear data. "Well, I had to do something to get owned" is not meaningful. We should not care about the ideological purity of practical systems. We should care about their practical outcomes.
> Those situations are exactly why password systems must be designed NOT to store the password on any devices, whether that's a file on a phone or laptop, or a cell in a database. Every time the password is written down, it is effectively already compromised as an authentication tool because it's no longer just something you know.
This is also largely wrong from a practical perspective. Chrome can happily store your saved passwords on disk if you don't want to sync with a backend service. This adds minimal risk, since a rouge program that can read all your files is very likely to be able to fuck you even if the passwords are only ever temporarily stored in memory.
The difference here is you're allowing your phone's enclave to store the magic secret, instead of your human memory.
—If you're authenticating with a PIN instead of biometrics, it's still 2FA.
For example, if your 2fa codes for a service are always sent to an email account that uses the same password as the site for that service, then you do not actually have 2FA in that case since any potential attacker just needs the one password to get into your email account and that automatically gives them access to the other service.
If the passkey is stored on the device, and the device unlocks by bio-metrics only, and there is nothing additional but to tap the yes button on a notification in order to get logged in. Then the site or service you are logging in to, has only one factor authentication. You can also notice this in the fact that the system here does not send the raw bio-metric data to the service, only the passkey. Therefore if someone copies your passkey or finds a way to man-in-the-middle the key exchange, they can unlock the the service without having your phone. Again one factor.
For it to be a true 2-FA system, you would have to send the evidence of what you are and actually hand over what you have. Both would be checked, and only then would you be logged in.
In the case of the usual password plus auth app codes. The codes, and the keys the are generated, from are in the auth app. That's not ideal either, it can still be messed with, but that's why we pair it with something you know, which is not stored anywhere (if it is written down anywhere, even as uncovered text in a database, or a file on your device, then the password is not a password any more, it's just something else you have).
1. "Dear User" -- other emails I've gotten from Google say "Hello" or "Hi <firstname>" or have no salutation at all.
2. The main section begins with "Passkey support will be integrated because they’re easier to use, and safer than most other forms of 2-SV." -- The plural antecedent of "they're" is merely implied (the literal plural antecedent "passkeys" isn't actually written).
3. In that same sentence, the comma before "and" is grammatically incorrect. The comma should not exist, or it should be followed by a complete sentence. The same comma rule is also violated in a later sentence: "You won’t need to enter a password to sign in to your account, or to select only a single phone to use as your built-in security key any longer."
I'm not really a huge stickler for grammar, but I've seen countless "how to spot phishing" guides specifically suggesting that we look for grammatical mistakes, as they're specifically included for purposes of improving the ratio of hooked phish to eaten phish, so it follows that messages which aren't phishing really ought to use correct grammar!
Lily Tomlin & co. could have made this[0] for Google today, instead of for AT&T ~50 years ago.
The dynamics haven't changed, just the corporations involved. And more's the pity.
One of the things you'd see those guides mention a lot is the call to action. The bad guys want you to do something for them, otherwise they wouldn't send you email.
In contrast the Google email you're complaining about says, "No action is required from you" which is my favourite type of letter from every company. Can I forget all about this and take no action? You bet I can.
I say "had been" because 189 lines of garbage entries are in iCloud Keychain and I can't get them out. They look like this:
Title,URL,Username,Password,Notes,OTPAuth www.amazon.com (MEoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECJeL6XzO81KJBCA02+DHVDASQ5Y3hOVrhGjCxV9Mv9qSEOc7uod7iKS3Rw==),https://www.amazon.com/,MEoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZI...,, (repeat for various sites 188 times)
I've tried deleting them multiple times but they always come back. I've filed Feedback with Apple but no acknowledgement of the problem. There's no hint as to whether the problem is with one of my devices or with iCloud.
I've switched over to BitWarden entirely. At some point, I guess I try deleting the keychain and starting over but I really am concerned about using something that allows an error like this.
However! If you have built any product which has gotten traction, you know just how much of a pain auth still is in 2023. It will always be your number one customer service pain point -- either unable to remember the email address your users signed up with so they can't initiate a reset password flow, or not getting an OOB email to start said flow, and so on. Auth in its current state is a complete drain on company time, resources, and money. Extrapolating out, I really wonder what a raw cost of the world's total GDP is taken up by dealing with auth issues.
Any kind of breakthrough here would be such a net benefit to the human race as a whole. Even the half step of OAuth, even with all of its complexity and "did I use Google or Facebook or Apple to sign into this site?", even that reduced friction enough to be such a material benefit to customer service. If we can make signing into a service as easy as unlocking your phone, there would be a huge productivity jump.
I am the admin. Doesn't appear there's any way to help.
> If you have a Google Workspace account through your school or employer, you will not be able to use passkeys to sign in at this time.
Source: https://support.google.com/accounts/answer/13548313?sjid=507...
I also wonder how a lost/broken/replaced device is dealth with, especially given Google's less-than-stellar account lockout history.
edit: I guess this is still MFA since you need both the physical device and a fingerprint and phone unlock code
Or if you really wanted to, you could flip it. You can allow the Passkey to be the "password" and an actual password the second-factor for the user.
So you send me an email today titled "[Update] Google passkey support will replace your built-in security key starting May 3, 2023". It was in my spam folder, but I digress.
This "update" kindly informs me that "Passkey support will be integrated because they're easier to use" [sic], that it's safer than most other forms of 2-SV, that this new method will work on any devices that have registered passkeys, which includes all phones on which I'm signed in, that I'll be able to sign in to my Google account with just a passkey, that no action is required from me to do this, and that you're here to help.
Yes, Google, I'd like some help. For starters, I'd like to know:
- What do you mean by "built-in security key"? Built-in suggests hardware, so my phone presumably has a hardware security chip and now passkey is a new type of hardware chip for authentication?
- What's 2-SV? Two Sievert? Dos El Salvador? Double Support Vector? Second Silicon Valley?
- What the heck is a passkey?
Luckily, you provide a link to your HC article [1], which I click on. It's titled "Sign in with a passkey instead of a password". It helpfully informs me that with a passkey, I can sign in to my Google account with my fingerprint/face scan/device screen lock like a PIN. There's a bunch of other valuable information in that article, like how it won't work in Firefox, won't work in incognito mode, that Bluetooth must be enabled, and that anyone who manages to unlock my device gets full access to my account. Needless to say, sounds totally awesome, I'm sold!!1
What the heck is a passkey?
Is it like the thing that sometimes uses my Android phone as a 2FA device to sign into Google properties, just... somehow different? What's the difference, except that I now need to enable Bluetooth and can't use it in Firefox? How is it more secure than [something I know + something I own] if it removes [something I know] from the equation and only leaves me with one of the two factors? How is it more secure than Dos El Salvador?
Who the heck wrote this email?
(good thing I already started to migrate away from the Google universe)
Is there a solution? Is this being used to push Linux users off the internet? Can I just fire up emulated Android and be ok?
Am I screwed? Googling indicates I am, indeed, screwed. Pretty concerned about this future.
We should try actually understanding and learning about what's going on instead of assuming that it's a Google conspiracy to kill Linux.
(google contributes heavily to linux anyways?)
Definitely! My understanding is that this is where passkey/password managers enter the picture.
My preferred password manager is 1Password, so once it gets passkey support I imagine I'll use that for everything. Until then, I'm depending on the limited sync functionality in iOS/macOS and Chrome.
It’s a pretty straightforward experience and it keeps the full ownership of the credentials to the user.
Private key infra in crypto/web3 tends to promote best practice as offline, paper wallet, airgapped devices, etc.
This is a closed system, with no public standard protocol, where you will have to use the stock closed-source operating system that comes with your phone, and you will need to have your cellphone with you every time you need to login, even if you want to login on a different device, and presumably, that phone also needs to have an Internet connection.
Maybe I misunderstood something, but I would never voluntarily use such an abomination.
[1] https://blog.google/technology/safety-security/one-step-clos...
My understanding is it's 100% impossible to 'prove' I know a password or not as it could be written on a piece of paper somewhere, and it's entirely possible for that paper to be shredded and therefore any proof of that password is gone, forever. I remember hearing you cannot be compelled to hand over a password.
Biometrics et al on the other hand? Could/would a judge compel those to be disclosed? I saw a video of a police officer forcing somebody to use their face to unlock their phone to delete a video. With a password, this would be 100% impossible.
So yeah, think about that BEFORE using.
The part about not being able to be compelled to hand over a password or decrypt something is also not true in many parts of the world. See: https://en.wikipedia.org/wiki/Key_disclosure_law
Here is some simple old-school ammo against it (or perhaps in favor of it, if they were to be so bold) Some good old-fashioned "skin-in-the-game" e.g. Nassim Nicholas Taleb style.
I will gladly use (and pay for!) this, but only with indemnification.
Insure me to the tune of, say, $100,000 in the event of a breach or a problem and not only will I use it, I'll pay for it.
Otherwise, no deal. If e.g. Google wouldn't take this theoretical (or practical) deal, then they are completely full of it.
The dangers of this are quite clear – if you get banned or locked out from your iCloud account or Google account (this is known to happen – with no appeals process), then you lose access to all your passkeys immediately. If you are forced to reveal your Google or iCloud account credentials under threat, you have effectively handed over all your credentials. There is no way to disable cloud syncing of your credentials.
By not allowing 3rdparty apps to speak BLE/NFC CTAP2 protocol on their phones, they are effectively crippling the phone you bought and paid for to be tied to their online platform more deeply.
They have turned a supposedly open standard that is FIDO2 authenticator (as described in the white paper) into a platform-lockin product called Passkey.
One excuse for this could be that there are risks to giving 3rdparty apps permission to speak raw BLE/NFC. But that doesn't need to be the case – CTAP2 authenticator protocol could be a platform component and it could be its own specific permission that can be given to apps that qualify it (there are special privileged api permissions like that today in platform already).
I can't find a single FIDO level 2 (or higher) certified implementation that is open source?
There's multiple references in this documentation to phrases like "To sign in for the first time on any new device, two pieces of information are required—the Apple ID password and a six-digit verification code" or in the no-device-recovery escrow documentation: "users must authenticate with their iCloud account and password"
I can imagine a world where Apple replaces sign-in passwords with passkeys; your devices form a ring of trust which "sponsor" new devices into your end-to-end-encrypted iCloud Keychain. But I'm having a hard time imagining how zero-device escrow recovery can work without a thing-you-know password.
Has Apple spoken specifically on this at all? Do they intend to follow the same route as Google and get rid of passwords entirely, and if so how are they securing zero-device iCloud Keychain recovery? Or will they probably just keep passwords around, if only for this specific use-case; and if so, what are the implications for functional user security? If I have an Apple Password I don't use for ten years, then have to use it that one time to complete zero-device recovery, many users won't remember it.
[1] https://support.apple.com/en-us/HT213305
[2] https://support.apple.com/guide/security/escrow-security-for...
They already force you to do either of those things if you want end-to-end encryption for all content types (which they called increased data protection).
Currently I can just message them the password or even write it down on a post-it note and they'll have everything they need to complete the task as me. How does it work with passkeys? Does the spec allow my passkey HSM to securely share the secret by encrypting it against the recipient's passkey HSM? Can it use the concept of leaf certificates to sign a short-lived certificate allowing access to that credential without sharing the credential's secret itself?
I can't advocate for passkeys until the concerns above are resolved. The push for passkeys seems like yet another attempt to remove control from the user.
And if you both use iOS, you can Airdrop a passkey: https://support.apple.com/guide/iphone/share-passkeys-passwo...
I'm sure we will gain the ability to dump the key to a file or write down onto paper at some point but it seems that we are starting from the wrong end.
I've got to quit commenting, but humans are undeniably the weakest link in security. While I understand the perceptions and even share some of the concerns expressed in this thread about the loss of control, reverting to a human-readable string as a key would only regress the whole scheme to something that is, once again, as easily compromised as a system protected only by any other human readable string.
We just have to cultivate new habits. Enroll multiple keys or devices. Print the backup codes and put them in the fire safe with your birth certificate. Give trusted friends and family access to recover your account in the event you lose the credentials or get hit by a bus. It's a few extra steps up front, but once it's working, it's so much easier.
Honestly, there are so many people who never have any idea what their password is, so they end up resetting it all the time... passkeys is a net-positive. Now they don't even have to remember anything.
It's a few extra steps per site. Every time you get a new device you need to go back to every site you've ever visited and update the credentials. It is maybe feasible for a few important accounts but it doesn't scale.
Whatever solution we have needs to be syncable and able to be exported to a safe once and continue to be usable by new sites and devices into the future. People aren't going to print out their credential list every month to update the fire safe.
The device's hardware security facilities are there to protect the keystore. They aren't /the/ keystore.
Find a key manager. iCloud Keychain, Microsoft Authenticator, Bitwarden, something. Use that. Concerns about migrating devices dissolve away.
My experience is not necessarily representative, but I am not sure how big the issue you describe would be, in practice, for the majority of users, who will be, by and large, using one of these services.
What is clearly a major issue for the majority of users is unauthorized account access and resource theft through the use of easily-phished account credentials protected by nothing more than a character string being passed around in text messages and sticky notes.
Is this a major issue though? I think it’s pretty minor, not being able to share or backup my passwords is a pretty huge issue in my books.
My recommendation: get a yubikey that you wear on your keyring, it's not as cheap as a password but it adds another layer of security without an even closer tie to you as a person, you can usually associate more than one yubikey with an account which gives you a way to diffuse ownership of the account without tying it to a particular computer or phone. And stay away from biometrics if you can.
From the Google Blog I clicked on "Today, passkeys for Google Accounts are available. You can try them out here"
However, I got: "Passkeys aren’t allowed on this account. Contact your admin for help"
And the Workspace admin page doesn't seem to include any options for Passkeys.
https://security.googleblog.com/2023/05/so-long-passwords-th...
the first sentence reads, "Starting today, you can create and use passkeys on your personal Google Account." (Emphasis mine.)
I'm not surprised that Workspace accounts weren't included in the initial rollout. Workspace setups have interesting requirements that aren't necessarily there for personal accounts. For example, under some circumstances, if an employee gets hit by a bus, and there is critical business data which is stored in the employee's account, an appropriately authorized Workspace admin is supposed to be able to gain access to the employee's account. But what is the right thing to do for passkey access? Especially if the user uses passkey to authenticate to some non-:Google resource like, say, Slack which has been set up for corporate use? Should the workspace admin be able to impersonate the corporate employee in order to gain access to non-Google resources via passkey? What about if the employee (accidentally) uses their corporate account to set up a passkey to a personal account, such as for example E*Trade? Maybe the Workspace admin should have a setting where passkey creation is disabled except for an allowlist of domains that are allowed for corporate workflows? It's complicated, and if I were the product manager, I'd want to take my time, understand all of the different customer requirements (where customer === the Workspace administrator who is paying the bills) before rolling out support for Workspace accounts.
I found out [1] that WebCrypto + IndexedDB is pretty much the missing piece, where you can store/retrieve a generated CryptoKey without having access to the private data. I wish the WebAuthn API would handle that for me...
The end-result is likely that everyone is using WebAuthn as a 2FA, rather than a password replacement, because on-boarding seems to suck right now.
At their core, passkeys are a easy and nice way to move from passwords to public private key cryptography. And hardware based authentication does allow more security. And by leveraging the hardware-backed keystore and security enclave, you can use your phone the way FIDO keys are already used. But there aren't clear benefits over 2FA and a password.
There are many reasons why I will wait as long as possible, maybe indefinitely before I start using passkeys. The idea of this being tied to Google or any other major company for my logins is not okay. There are many cases of people being locked out of Google accounts without the ability to appeal. With current 2factor, you can control the secrets yourself if you choose to. While it's true that you can't be phished into sharing your passkey as easily, you also lose a lot of convience and flexibility in login management. And it makes login sharing or multi-account management very inconvenient and difficult.
I was hopeful with 2FA rolled out that my accounts would be more secure, but most companies give you very little over which methods of 2FA are allowed or enabled. I don't want to be forced to enroll a phone number just to enable TOTP 2FA. I want to be able to choose between TOTP or HOTP for my accounts. I don't want to be forced to use a 2FA app that doesn't allow me to export and manage the secrets myself. In some ways FIDO keys solve some of those issues, but the hardware security aspect of it contradicts giving the end user the choice to self manage.
https://www.concordlawschool.edu/blog/constitutional-law/fif...
I went to my google account and clicked "Create a passkey", but apparent my "device doesn't support creating passkeys" (Linux, Firefox).
The page said my Pixel 2 has an automatically created passkey, so maybe I could experience the "use another device to sign in" flow. Opened a private window and my only option was a password (but there was a feedback prompt asking why I still wanted to use a password).
I tried again with Firefox on Android, but the "Create a passkey" button doesn't even appear. Same story with Chrome on Android.
Is it just me, or does the future look a lot like Internet Explorer in the early 2000s?
Just stuffing more of our private lives into phones full of ads and tracking. Each time you unlock your phone Google makes money.
I am not a cryptographer: why would a 6-digit screen lock PIN with this system be any safer than a 6-digit numeric password on the web (i.e. not very)?
It’s a 4 digit number. What am I missing behind the scenes that makes it more secure?
Some critical notes on Passkeys: https://www.jbspeakr.cc/fido-passkeys/
What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?
Eg you’ll get:
Token{domain:hax0r.net username:bob}
2. evil.example: confirm 2fa code to log in.
3. evil.example starts logging into good.example as you, triggering good.example to send the 2fa code.
4. You see the 2fa code and enter it into evil.example.
5. evil.example has phished your 2fa code.
This doesn't work with passkeys (or 2fa tokens) because those verify the domain matches.
Because when evil.example requests the passkey it has to do so through browser APIs [1], and it can't lie about its domain name. Your browser is what reaches out to your phone, which is how your phone learns what domain you are actually on.
[1] https://www.w3.org/TR/webauthn-2/
In this case your phone wouldn't even show you your passkeys from good.example.
You are not googles customers. Advertisers and other agent wanting to target you are google customers.
Channeling someone, "just say no to google." Or "friends don't let friends use google passkeys".
I wonder if they get your device fingerprint on login too.
https://developers.google.com/identity/passkeys/faq
>Can I move synchronized passkeys from one platform provider to another?
>Each device / platform may offer different experiences and controls. But a user can always register a second credential with a site and remove the first, effectively “moving” from one to the other.
1. email-based "reset passkey" flow -- only as secure as the email it's sent to, and you need to make sure the email is still valid since the user isn't using it regularly as part of their auth.
2. multi-factor "reset passkey" flow -- you have to make sure the user has kept multiple factors (eg backup codes) which they're mostly not using.
Is there something better? Anyone have a good resource?
Its also fairly surprising that desktop UI on linux tells me I can't add passkeys from it. I understand that Chrome isn't planning on supporting platform authenticators on linux, but why can't I add another phone from the desktop with the QR flow?
To put it another way, it's not really any more secure than passwords.
Sure, there's a lower risk of password breaches, but if you're the target audience for passkeys, you probably also use a password manager with unique passwords per site (even if that manager is the one built into your browser and synced across your devices).
This is the difference. With the big players pushing it, including Apple instructing developers on the best way to integrate passkeys in their apps[0], it's going to overall shift more people from passwords to passkeys (especially when developers prioritize passkeys during signup).
0: https://developer.apple.com/documentation/authenticationserv...
Chrome and Edge on Windows are the only ones that prompt me for passkeys today (Firefox tries to use Windows for auth, which throws up a scary prompt).
> Already webauthn isn't prompting for passkeys on Apple.
It does for me on iOS, at least (and Safari on MacOS; other browsers don't use the native icloud passkeys, chrome has its own secret store).
> Chrome wants a bluetooth connection out of the box,
IIRC it works without it for on-device passkeys, but caBLE requires Bluetooth to facilitate proximity passkey connections if you want to use wireless webauthn.
> but caBLE requires Bluetooth to facilitate proximity passkey connections if you want to use wireless webauthn.
And that's the problem. The lack of a cross browser/device/os standard. You can't create a secure authentication chain - let alone replace passwords - without standards that are broadly accepted; without broadly accepted standards. To do otherwise means you have to train your average Jack on 4 (or more) different ways to authenticate to one service.
And the way they'll pick? Passwords. Because they know how to use passwords.
True if you are being specifically targeted, but there are whole classes of vulnerability that you are better off not having even if you have less than perfect opsec. To take an extreme example, my personal server may have an unpatched vulnerability that a determined attacker might exploit, but that doesn't imply I might as well share the same password across all my accounts.
Irrelevant to the argument I made. My argument already assumes you're using unique passwords, since it's made quite simple these days.
Good passwords (stored on the backend with a password-optimized hash) are pretty close to bulletproof, and all browsers that I've used in the last few years prompt you with very good passwords.
Again, the key is that people who would use passkeys are the same ones who will be using good, non-reused passwords in the first case. We've taught non-technical users too well that they should not pay attention to out-of-browser prompts, so they're not going to be able to use passkeys without significant and broad re-training.
Has anyone used these in the field for a major, popular site or product? What was it?
More importantly: What if I have a Windows laptop and an iPhone? Can I transfer a Passkey from my "only Apple device" to something else as a backup, or will these be locked to one vendor?
g.co/passkeys (my gut says, "what is this scam? I am not clicking on that") https://myaccount.google.com/signinoptions/passkeys (my gut says, "interesting, let me take a look")
So, for the vast majority that does not have hardware that supports fingerprint reading or face-scanning, this grand new alternative to passwords is... passwords?
I get that it's nice for phones, but that's only about 50% of the web's traffic.
EDIT: Looks like support will be coming to NordPass and other password managers soon - https://support.nordpass.com/hc/en-us/articles/1298467820264...
Can anyone who knows more about passkeys explain why this is the case? Are service providers just misusing passkeys as the second factor, or do I misunderstand passkeys?
They already have "sign in with google" which directly links sites to your Google account. This is not that.
No passwords. No email. No Google. Just public key authentication with private keys in possession of the user. https://github.com/Cyphrme/Coze
I wish they gave the option to disable this.
Firefox might get it around version 120: https://connect.mozilla.org/t5/ideas/support-webauthn-passke...
Apple does not yet support Passkey for iCloud accounts login.
Biometics? Authentication device?
It doesn't necessarily need to use biometrics or be bound to a specific device, so those aren't quite accurate. Thus, passkey.
"But it's early days, portability is coming."
Google/Microsoft have been saying this for ages, and it hasn't happened yet. And there's no effort being made to mandate portability as part of the spec, so even if the companies ever actually get around to allowing cross-ecosystem sharing, there are still going to be implementations that don't support portability. And honestly at this point I feel like it is an "if" not a when because Google and Microsoft and Apple are not talking about this being early days, they are encouraging people to switch over right now. So if you launch a feature and you encourage people to start using it for everyday logins, and it doesn't support cross-ecosystem export/import, then it doesn't seem like that's a priority or a blocking issue.
"But 1Password will support this"
No, 1Password is looking to support cross-device syncing, it's not allowing you to move out of the 1Password ecosystem. It's just tying to the 1Password account instead of the hardware.
"But cross-ecosystem syncing would enable phishing"
We crossed that bridge. If you can sync passkeys between devices (and every major player is going to allow that), then there are phishing risks. iCloud accounts can be hacked. Your 1Password account can be compromised. It's not for the sake of security that Apple allows syncing keys across devices but not to other ecosystems.
"Just use a Yubikey"
That's still proprietary hardware and the recovery process that people advocate for with Yubikeys is ridiculous and unworkable. I'm supposed to have 2 keys that I keep in sync and store in different places. I have enough trouble synchronizing Org-mode files between computers, that is not a feasible way to manage account logins.
I refuse to get excited for or advocate for a technology that at this point is just transparently about vendor lock-in, no matter how many times that advocates say it's not. Every time I look into this I wonder if something has changed, but last I checked FIDO alliance is not looking to standardize portability, they're just leaving it up to individual companies. Well, what that means is that maybe if you're lucky you'll be able to sync keys from Microsoft to Apple and vice-versa. You won't be able to sync those keys to a Linux computer (Chrome's implementation of login doesn't even work on Linux without a hardware key, you literally can't use that computer to log-in without a separate non-Linux device).
We should reject this. Passwords have real problems and a key-based authentication system would be a major improvement. It stinks that it's being run this way. And it stinks that advocates for Passkey are trying to argue that it's Open when there's not a single non-proprietary implementation on the entire market. It honestly feels deceptive to me, I have no trust in the FIDO alliance right now. There's been basically no visible progress on this, and every time the issue gets raised, somebody shows up to say that we just need to wait longer. Well... now it's launching. And surprise, we need to wait longer.
BTW, passkey is the name for a password that is made using word keys.
The attempt to get rid of passwords has been the biggest assault on the free internet in recent history, and people are asleep at the wheel as it's happening.
They want to tie you to an external service, so they can tie you to your phone, which they also manage with another external service.
All of these schemes are braindead with obtuse, user-unfriendly backup/transfer/restore options. They fail at even making things "simple" for regular users.
For example: https://github.com/StrongKey/fido2
Arguing effectively that passwords were fine for computing in 1970 isn't an answer. So if you don't like passkeys it's reasonable to ask for your alternative.
My mom can’t tell if a website is fake if it’s made to look exactly like Facebook, for example. So in a sense passwords are actually awful for users because they’re required to remember dozens of passwords and verify that a website is legit. If they just reuse the same password everywhere then they are vulnerable to another kind of attack because some website somewhere will mishandle it, forcing her to change every password on every site afterward.
Instead, she can have the best of both worlds by remembering one master password, that basically opens a magic app that will check that the website is legit and create/retrieve a unique passkey for each login.
Or use a password manager to solve both of these issues
Except you're not tied to a magic phone