Passkeys: The beginning of the end of the password(blog.google)
blog.google
Passkeys: The beginning of the end of the password
https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/
1,129 comments
> use this to tether and lock you in to their platform.
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...
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...
The article says "Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN."
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?
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?
No passkeys are just normal private keys. You can store those private keys in a particular platform's secure key store which on phones can be decrypted/made usable when you unlock the device. But there is nothing stopping you from transferring these keys to a different device if you wish.
> But there is nothing stopping you from transferring these keys to a different device if you wish.
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.
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.
> 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
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.
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.
> The google password manager and Apple devices will sync private keys as part of the password manager sync fabric.
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.
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.
> 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 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.
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.
> 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.
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.
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.
> 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?
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.
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.
> I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.
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.
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.
> > Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
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.
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.
I'm with you, Dan. It is grossly irresponsible for the industry to be pushing passkeys while fundamental problems like transferring from one ecosystem to another aren't solved yet.
We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.
We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.
So if I transfer a passkey to my Yubikey, which has a single button and no pin, thus achieving 1-factor authentication - is that undetectable to the website?
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?
[1] https://developers.google.com/identity/passkeys
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?
[1] https://developers.google.com/identity/passkeys
You wouldn't transfer a passkey to your YubiKey. You would enroll it as another device that can be used to login. Like right now on my Google account I have an iCloud passkey and a Windows Hello passkey since iCloud can't sync a passkey to Windows (yet).
Hypothetical political journalist just lost both his Yubikeys when his office and home were both targeted. He still has an off-site backup of his passkey. How would you envision this working?
I'm unfamiliar with the particulars of passkeys, but with hardware tokens I've used before, you'd log in ASAP and unenroll the keys you've lost custody of.
edit: spelling
edit: spelling
So this is basically the same thing like ssh keys?
Exactly. But with some added security.
If the site insists on UV (User Verification) rather than UP (User Presence) a device which has no way to verify the user should reject that.
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.
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.
How exactly would you transfer your iOS passkeys to Android? Please provide an enumerated list of steps.
This is incorrect. Passkeys on iOS and Android are locked to Apple and Google account ecosystem. They cannot leave their ecosystem. Also, only the OS platform can use the BLE transport for CTAP2 protocol on iOS and Android devices. That is, a 3rdparty app (like 1password) cannot implement a FIDO2 BLE or NFC authenticator on iOS and Android – which is a huge handicap.
True, Passkeys are private keys at heart, but relying parties can verify whether they are stored in software or hardware by requesting/requiring authenticator attestation when they are created.
And certain hardware from certain platform vendors doesn't allow exfiltration of private key material. Though I don't think this can be specified by the relying party so that's how Apple stores all keys in keychai. I sincerely hope it remains best practice for relying parties to not require/use the platform attestation feature to lock users onto "trusted" platforms.
Device binding can be required by relying parties! They can just refuse to accept credentials without attestation statements signed by a trusted party.
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…)
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…)
That's more like vendor binding. Apple’s credentials aren’t device bound so “pinning” to Apple as a vendor by requiring attestation doesn't ensure a credential is device-bound. Not that you don’t have a point, generally.
Ever site I've accessed with a passkey lets you tie it to an existing account with a username/password, Google login, Apple login, iPhone, YubiKey, etc. I've not used a passkey where that was the _only_ auth I could create on an account.
The title of the article though is "the beginning of the end of the password." Google seems to be making it clear here that they eventually want to get rid of other login methods, they just don't think it's mature enough yet for them to do so.
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.
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.
But they’re not the only one using passkeys. If you could have multiple passkey logins to an account, it’s not earthshattering if one of them becomes unavailable.
That's the intention yes, and it's a whole 'nother conversation about how many passkey-eligible devices people actually do have in reality, and how often they travel with all of those devices on their person at the same time and how often they're going to actually go through the extra steps of logging in on their secondary devices and adding a new passkey.
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.
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.
> 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?
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).
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).
[deleted]
What it does imply is that if you store your passkeys on Apple's keychain, migrating to Android becomes that much harder. (I assume that Google will provide an implementation of passkeys on iOS when that becomes available as an API, but it will be a cold day in hell before Apple provides access to its keychain on Android.)
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 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.
You can use your device passcode instead of FaceID.
You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just let me advertise some mDNS service record for "authenticator" and require me to advertise a pubkey and let the user select/allow me once and remember the decision until the pubkey changes so that I'm trusted backend without the QR scanning rigamarole.
> the scenario where your password manager is running on the same device as the one where the user is performing the login
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...
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...
Yes, I'm waiting patiently in the wings. Sadly when I asked Apple's Passkey team about supporting this, they said it wasn't on the roadmap (though they carefully didn't say never, it still doesn't instill much hope). Once this missing piece becomes a required part of the standard, I'll stop holding my breath and get super excited about passkeys.
Can I store the keys in bitwarden or am I stuck using google chrome to access this or whatever Mozilla cooks up?
I can't rely on retaining access to my Google account for logging into things.
I can't rely on retaining access to my Google account for logging into things.
Not now, but soon. Bitwarden's public statements over the past year, and their acquisition of passwordless.dev, would seem to indicate that they're working very hard on adding passkey support.
On Android, there will supposedly be an API for third-party Passkey implementations soon: https://developers.google.com/identity/passkeys/supported-en...
1Password has already announced their intention to use this once ready. I really hope iOS will provide something similar soon.
1Password has already announced their intention to use this once ready. I really hope iOS will provide something similar soon.
> You could say this about Google's proprietary authenticator app in the past
There's many implementations of OTP. I've never used google's and I've been fine.
There's many implementations of OTP. I've never used google's and I've been fine.
> 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.
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.
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.
Can you explain how passkeys explicitly reaches that end goal, when all of that is already currently possible without passkeys?
You can share passwords easily, I don't think you can trivially share passkeys.
You can trivially share passkeys with others, at least on all apple devices:
https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16...
https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16...
You don’t need to share them because you can enroll more than one for a given account. So for example if 3 people are sharing an account, you can enroll 3 passkeys for that account and they each have their own access.
I don’t see any way that passkeys kill account sharing.
I don’t see any way that passkeys kill account sharing.
What the other user says is that maybe those companies will only let 1 device per account to be registered. So you can’t have 2 devices to login. Harder to share.
In this case, Google, that isn't true and just they're mostly treated as special Security Keys ("yubikeys" etc).
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)
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)
Hey, shhh, new thing bad! Get with the program! Not enough fear mongering and too much rational thinking.
It's not fear mongering to have and express concerns about a technology. Especially a technology that many people want to force everyone to use whether they want to or not.
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.
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.
I think it's simpler than that. Expenditure is linked to trust. Companies and platforms that erode trust, make less money in the long run - they have to continually exert energy to attract customers. Companies / platforms that focus on building and retaining your trust have to work less hard to have you part with your money.
Apple, Google and Microsoft are all supporting passkeys
https://developer.apple.com/passkeys/
https://arstechnica.com/information-technology/2022/10/passk...
https://developer.apple.com/passkeys/
https://arstechnica.com/information-technology/2022/10/passk...
class ASAuthorizationSecurityKeyPublicKeyCredentialAssertionRequest
Now I'm wondering what's the longest class name out there...
Now I'm wondering what's the longest class name out there...
> 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:
• 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...
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...
> 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.
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.
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.
Call me a cynic but I'm convinced that won't be happening anytime before critical mass adoption of these companies' own solutions, and either defeated acceptance of this new norm or abject incomprehension by whomever remains.
"All your base are belong to us"
"All your base are belong to us"
Yeah I fail to see why google would be incentivized to provide this functionality.
EU provides incentive.
[deleted]
To which law are you referring?
I think they are referring to the EU's aggressive data surveillance and zero expectation of privacy to government organizations. While the EU has been very pro customer to business privacy they are vehemently against anything that lets anyone hid anything them the government.
I’m a cynic too, but I’ll also be optimistic about published statements. Goggle said they’re committed to supporting 3rd party passkeys when they announced android support. Apple, not so much though. I am hoping Google just does the right thing and makes this table stakes.
> 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.
How so? I just created two passkeys for my Google account — one for Chrome, and one for my Apple Keychain.
How so? I just created two passkeys for my Google account — one for Chrome, and one for my Apple Keychain.
What you describe sounds awesome. Is it still something people could use? If the WebAuthn protocol gains broader support because Google/Apple are pushing passkeys then anything that speaks WebAuthn should be a viable option, right?
Disclaimer: I own 2 NFC rings :)
Disclaimer: I own 2 NFC rings :)
Contact me and let’s add it to https://qbix.com/platform and ecosystem so it is not captured by Big Tech corporations.
We have a lot to talk about and exchange information.
greg at the domain qbix.com
We have a lot to talk about and exchange information.
greg at the domain qbix.com
> 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
https://qbix.com/resume.html
I regret to inform you that someone has carelessly or maliciously leaked your deobfuscated email address, on the site
https://qbix.com/resume.html
i say this every time this is mentioned... all these thing are mostly to help advertisers and fight spam and reduce cost on their servers.
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.
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.
> 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.
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.
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.
I recall Mozilla tried something similar around a decade ago, which was a good solution but didn't get any adoption. There's also been approaches like OpenID which were once popular, where you can have a single login, but they have the problem of third-parties aggregating the sites you visit. Who uses OpenID today? It's all been replaced by facebook or google login.
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.
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.
> 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?
What does "authority" mean here?
The user giving authority to access their information.
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.
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.
I don't see the fundamental difference between stealing/spoofing someone's biometrics vs. their secrets.
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?
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 bios represent identity.
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.
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.
MPK is really cool.
> 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.
> 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.
If your ring is your password then they'll just take your ring and your phone...
Cool idea about the NFC ring. Is there anything like that now? Any application?
There's https://store.nfcring.com/products/omni, but chip it uses isn't the best, plenty of applets can't be installed on it.
There are payment rings a plenty though, for just using them instead of contactless credit cards.
There are payment rings a plenty though, for just using them instead of contactless credit cards.
You patent your things, then disseminate. Your ideas will be burglarized, stolen, reintroduced and shown as an invention of someone else (who is a lapdog of given entity).
I love this approach.
At least Google does those things as an open standard.
So it should be easy for everyone else to do their own.
So it should be easy for everyone else to do their own.
The paragraph in the section, "What are passkeys?" tells me that they: are new, are easier, let me use biometrics, and are resistant to attacks. But, it doesn't tell me what passkeys actually are.
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.
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.
You need to click on the link that is in the post: https://blog.google/technology/safety-security/one-step-clos...
> 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?
> 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?
Why not call it a private key then, we've been handling those since the 70's.
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.
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.
It isn't (just) a private key. It is part of a purpose-built authentication process that leverages private keys as a component.
You cannot use the private key within a passkey for general purpose data signing, for example.
You cannot use the private key within a passkey for general purpose data signing, for example.
Why not call passwords private words? We've been using words even longer.
The answer is that they're being used to pass an authentication challenge. Pass + key is no different.
The answer is that they're being used to pass an authentication challenge. Pass + key is no different.
>Why not call passwords private words?
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.
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.
I guess because historically (before computers) passwords were often shared. Even now a password doesn’t technically need to be private.
Neither does a passkey. They've designed the standard to allow sharing the passkey with others.
Are you sure you have the details correct here? This is not generally how public key cryptography works.
For instance, with Apple you can AirDrop the Passkeys. https://support.apple.com/guide/iphone/share-passkeys-passwo...
I think he might be referring to single device vs multi device pass keys
https://developers.yubico.com/Passkeys/Passkey_concepts/Sing...
I wouldn't be surprised if password managers implement sharing between users tho
https://developers.yubico.com/Passkeys/Passkey_concepts/Sing...
I wouldn't be surprised if password managers implement sharing between users tho
Wait, they have?
"Open sesame"
There's already nomenclature for that too. Auth keys vs signing keys.
I think the real answer to your question is a) marketing and b) it’s more data than just a private key. It has a private key, but also some other things.
Could be clearer for the tech folks though I agree.
Could be clearer for the tech folks though I agree.
Given how poorly private keys have done in the end user marketplace so far, they definitely need to be rebranded.
Every time I notice a rebranding I assume they're trying to hide something from me. Maybe that's just me.
It is a fair assumption even in this case, the rebranding serves to hide the fact that private keys are used from you.
The simplified terminology is not for you or I as technologists. It is for the general consumer market. Yes, public/private key cryptography has been a thing for decades, but it has been out of reach for the consumer market. The whole passkey idea is to reduce the technical and cognitive friction to make it a viable replacement for passwords.
because there's a time based hardware component to it.
this isn't just public key encryption. Think of it as a physical Yubikey but embedded in your ...whatever.
this isn't just public key encryption. Think of it as a physical Yubikey but embedded in your ...whatever.
[deleted]
[deleted]
So it's like a private key but you can't access or manage it, as it's owned by Google/Apple/Microsoft?
How convenient!
How convenient!
My reaction as well. From Google's FAQ:
> 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.
> 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.
> Time will tell if Google's implementation will be open source, and if third parties can hook into the OS level integration
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.
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.
> but it doesn't need to be for an interoperable ecosystem.
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.
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.
I don't know what a service provider is in this case for sure, but I'll assume you mean something like Google Password Manager or iCloud Keychain or 1Password.
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.
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.
WebAuthn is a standard. From what I understood, can use any third-party authenticator like a YubiKey instead of Google's implementation.
> can use any third-party authenticator
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.
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.
[deleted]
[deleted]
Thank you didn't know this! I just hope the underdog can stand a chance against the "it just comes with it"
I do too. The ability for a smaller focused company to innovate and pivot to find unique markets is way different than what the platforms will ever offer. I suspect passkeys provide new ways to innovate beyond what they have been able to do with passwords in the past.
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.
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.
The thing with these authentication services is that if Google doesn't like you and blocks your account, you're fucked.
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.
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.
AFAIK android will have an open API, iOS however is going to only support iCloud, classic monopoly.
Also it seems that Linux is completely out of the picture.
Also it seems that Linux is completely out of the picture.
> AFAIK android will have an open API, iOS however is going to only support iCloud, classic monopoly.
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.
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.
No, hold on. That's not what I implied.
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.
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.
Some devices e.g. Apple have a Secure Enclave that is not user accessible, that's what I'm referring to, I'm not suggesting that they are stored on a server.
Not sure if you’re being sarcastic, but that really is convenient.
Until it's not and they decide you shouldn't exist anymore.
Precisely this. What happens when Google decides that your account is banned, and no, we don't have to tell you why, and we regret to inform you we have automatically reviewed this decision and it is final?
Owning the private key for your Google account isn’t going to prevent that in any way.
Passkey is an open standard, clients are not limited to Android or IOS devices.
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.
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.
Possibly a dumb question... the Yubikeys a bunch of us own were originally sold as U2F / FIDO keys. My understanding of this system was that it was, as labeled, a "universal second factor" standard. But passkey is supposed (?) to be a single-factor (something you have, not something you know). Is it doing this just by (ab)using the "second factor" approach for single factor auth? Or is there something a little more sophisticated, and hopefully more secure, happening here?
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.
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.
[deleted]
[deleted]
Nothing that you said prevents vendor lock-in. If my private keys are stored are in a Secure Enclave, I can’t copy them to a FOSS client or a Yubikey.
The list of members of the FIDO alliance is public. It includes several companies that most people refer to as “big tech”.
The list of members of the FIDO alliance is public. It includes several companies that most people refer to as “big tech”.
I'm not sure why you couldn't associate a new key with whatever services you use, like changing a password, or even having multiple keys associated to one account.
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.
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.
Having to regenerate all your keys just to switch client is an order of magnitude (or two) harder than migrating from one password manager to another. The article we are commenting on is titled "the beginning of the end of passwors" as if passkeys were an improvement over passwords.
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.
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.
[deleted]
[deleted]
[deleted]
[deleted]
[deleted]
I'm not completely sure, but my understanding is that it's basically the same principle as SSH keypairs, with the added twist that the user never gets direct access to the private keys.
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)
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'm not completely sure, but my understanding is that it's basically the same principle as SSH keypairs, with the added twist that the user never gets direct access to the private keys.
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).
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).
Sounds like you are describing how hardware tokens are typically done? With this being an idea of how to move the token into the cloud?
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.
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.
Well, guess it won't work for me. Rooted phone and prone to boot loops and hard resets whenever i get curious with some stuff. Every authenticator stored in the phone can't be recovered when you install a new ROM (google tries to send the authorization pop up to the previous version of the phone and, of course, it'll never get there)
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.
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.
> Rooted phone and prone to boot loops and hard resets
> 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.
> 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.
Ok, i wasn't specific enough, that's on me.
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.
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.
> To put it bluntly: you’re wildly out of touch with reality for most people. 99% of people who have a phone
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.
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.
[deleted]
> You need to click on the link that is in the post
So, a communication failure straight away. Does not bode well.
So, a communication failure straight away. Does not bode well.
The passkey itself is an encryption key.
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)
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)
> The passkey itself is an encryption key.
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.
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.
I think you're right about discoverability being a key property differentiating Passkeys from WebAuthn credentials, I got that one wrong. I think the other ones would be it's likely syncable across devices, and likely requires some type of user verification.
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].
[0] https://www.w3.org/TR/webauthn/#credential-id
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].
[0] https://www.w3.org/TR/webauthn/#credential-id
> 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.)
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.)
> 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.
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.
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.
There is a nice diagram on this page for those wanting a bit more of a visual overview:
https://developers.yubico.com/Passkeys/How_passkeys_work.htm...
https://developers.yubico.com/Passkeys/How_passkeys_work.htm...
The term "passkey" is not a technical term, it is a user-facing term.
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 .
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 .
> Until they develop a way to explain what passkeys really are, I question how quickly they will be adopted.
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.
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.
You might like https://passkeys.dev if you want a more implementer-focused overview.
I suspect that one screen comic or a 20 second video could explain it. Instead they give us a wall of text that even technical people can't understand.
How about: "Passkeys are digital keys that can be securely stored either in a physical device (such as a Yubikey) or in an online account (such as iCloud Keychain or Google Passwords)"?
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?
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?
Yubikeyrings? I like it.
From what I can find the word passkey is just a synonym for password. So yes, none of this makes any sense.
It makes sense if you want to move from two factor authentication to just the second factor while making it seem new and cool?
It seems to be smoke and mirrors for you register a bunch of TPM/HSM.
It seems to be smoke and mirrors for you register a bunch of TPM/HSM.
Don't be so quick to dismiss it. Afaiu, (one of) the problems they intend to address is the (all too common) case of breach of security at the server where large number of passwords are stolen. The public part of a passkey, i.e. the one stored on the server, is worthless to an adversary.
I think it's a great change but I am critical of the way it's being marketed.
Thank you. I've been trying to figure out what they hell they are and have been unsuccessful. I thought it was just me.
This goes into more detail: https://developers.google.com/identity/passkeys
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).
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).
Can it be uses on both Android and iOS? What about desktop machines with no fingerprint sensor or faceID?
What happens if user loses the only device on which passkey was enrolled?
What happens if user loses the only device on which passkey was enrolled?
> Can it be uses on both Android and iOS?
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.
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.
> 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?
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?
The upcoming W3C Web Authentication Level 3 defines a "backup capable" authenticator, which means that it goes beyond a single piece of hardware. Indicating "backups enabled" means that the user has a recovery process, such as if they store the passkeys in their iPhone and then lose/upgrade the model - they can just sign into iCloud on the new device.
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.
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.
> 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.
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.
Apple won’t even let you set up Passkeys without online backups/syncing enabled. Not sure if Android does.
It can be used on both Android and iOS. Desktop machines can display a QR code which you scan with your device. Passkeys are backed up to the cloud using E2E encryption. If you get locked out of that device, you can do the same thing as when you lose your password.
> do the same thing as when you lose your password.
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.
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.
You could also try your password, I guess.
The one you lost?
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.
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.
In principle it can be synced between any is, it just depends on the cloud/implementation. Eg. 1Password is currently adding Passkey support, that would probably work on any device they have browser plugins and the private key material is stored and synced through 1Password vaults.
[deleted]
It's an open standard that allows a website to ask your browser for secure, authenticated, per-site-specific credentials. It's also a UI and method to provide those credentials and store them on your devices.
You don't have to use the latter, you can store your keys wherever you want.
You don't have to use the latter, you can store your keys wherever you want.
Passwords will never be supplanted unless the new challenger can satisfy all of the following:
* 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.
* 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.
It's also private.
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?!
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?!
Passwords will never be supplanted? As always, it's a false dichotomy. Passwords will continue to be useful for some scenarios, but in others they will and are being replaced by other methods such as biometrics, U2F tokens, etc
Biometrics should never serve as a password. It may serve as a login.
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.
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.
I would add portable (which passkeys are not) and recoverable (which passkeys are not, in the worst case).
I'm not sure if it is passkeys or other mechanism, but I can easily open my bank account on my Android phone just by using biometrics. Instead of typing a pin or password I just do the biometrics and voilá, it opens like magic. That really made me appreciate passwordless apps.
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?
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?
I guess the idea is they will ask you to grab your smartphone the same way they do it for 2FA. For the end user it will be just like using the 2nd factor of authentication without the primary one (login + password).
What do you do if you don't have a smartphone or are unwilling to use it for this?
Passkeys do all of this
* 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
* 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
I'm actually going to set this up on my mother-in-law's machine next time I see her. She's forever losing her book of passwords, but always has her phone on her.
That'll be fun when she drops her phone in the toilet.
Then she's back to where she is now.
And easy to share.
It’s a password that Google controls so when they incorrectly ban you from their services you lose access to literally everything.
Or if you drop your phone in a lake you’re out of luck too.
Or if you drop your phone in a lake you’re out of luck too.
Banning has nothing to do with it.
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.
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.
This means that you still need a password, which you still should store securely.
It just becomes much harder to phish out this password.
It just becomes much harder to phish out this password.
Maybe "Passkey" + "Magic sign-in link email" will be a good enough combo for most?
If you've also lost access to your email, you've got other problems.
If you've also lost access to your email, you've got other problems.
That makes your email box effectively a password vault. Might as well use a service designed for that such as LastPass, or 1Password.
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.
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.
[deleted]
Passkeys are open, so you can for example store them in a Yubikey if you want. Else many password managers will soon support passkeys, for example 1Password or NordPass.
https://www.yubico.com/blog/a-yubico-faq-about-passkeys/ https://nordpass.com/passwordless/ https://www.future.1password.com/passkeys/
https://www.yubico.com/blog/a-yubico-faq-about-passkeys/ https://nordpass.com/passwordless/ https://www.future.1password.com/passkeys/
It's the second one, not the first one.
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).
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).
"best have another way to auth"
right, so passwords it is then.
right, so passwords it is then.
well, the argument is that for strong passwords you will need to use a password manager anyway. Which you will sync somehow, which will sync your passkeys too. So in the end you might as well replace all your passwords with passkeys except for the one password you use to access your passkeys in your password manager / the master access basically. The one way to make sure that you never lose access. I think this makes sense, I'm also very dependent on a password manager now.
> 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.
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.
Unless there is proof that the hardware on the phone is isolated specifically for this task you cannot make the claim that google is unable to MITM.
Yes, the hardware vendor that controls the kernel and chips can do whatever they want. I meant there is no method as per the definition of the protocol to MITM the passkey because the device only ever emits the public key unencrypted.
> Google doesn't have a way to MITM that
Google controls the software so it can MITM.
Google controls the software so it can MITM.
I'm not sure how it's all that different from Windows Hello.
> 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.
> 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.
Windows Hello can supply single-device passkeys at the platform level. Browsers and native apps will leverage Hello in the background (a la WebAuthn.DLL).
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.
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.
> What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or retina.
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?
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?
> What's a password? A secret word or phrase that only you know.
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'"
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'"
> a secret word for phrase that both you and the service you want to sign into know
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.
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.
Agreed, I think we have to move past the general assumption that people do not understand anything written in terms that are even remotely technical. Obviously HN is a tech savvy audience but still software service providers should provide greater clarity into how things actually work and encourage users to think about things more technically instead of just making everything a magical black box.
How quickly they will be adopted will be almost completely determined by how convenient they are to the user, not how secure they are.
[deleted]
If people here can't understand what passkeys are, how are the "normies" gona get it? Or maybe the wide public is not supposed to get it how it works; they should "simply" use it.
The second. The term passkeys is meant to describe "like what I get with passwords, but easier/more secure'.
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.
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.
[deleted]
They will understand their password has been replaced by fingerprint reading or pin on their smartphone. They won't bother with the technical aspects behind it.
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.
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.
You drastically overestimate technical competence on HN. Especially as of late.
i think you underestimate how many users want to just be signed in to their account, and don't really give a damn about security in any way. they see a password as an inconvenient impediment, and if they could get rid of it tbat would be fine.
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.
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.
From what I've understood it's a TOTP without the air gap of user typing the code manually.
For a technical standpoint it's a system that generates OTPs from another Auth source, like biometrics or even a classical password.
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.
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.
WebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards.
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.
[1] https://github.com/w3c/webauthn/issues/1714
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.
[1] https://github.com/w3c/webauthn/issues/1714
My cynical assessment of Passkeys is:
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.
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.
> If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere.
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...
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...
> Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co
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?
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?
Right now, the identity of an account is tied to knowledge of the email address and the password. Something you know.
If you forget the password, you need access to the email account.
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.
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.
Passkeys don't negate regular account recovery processes. Just as if you were to lose your password, you would have to talk to support.
Agreed. This whole thing seems incredibly user hostile. At the very least, there should be severe legal recourse (criminal liability and also large, material-to-earnings statutory damages) if one of these providers intentionally locks you out of a third-party account.
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.
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.
Lol. If something does happen Google will immediately and repeatedly remind you with every communication that they have no liability. Once your account gets flagged or locked, Google adds the following to damn near every email:
“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.”
“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.”
Giving your passwords to a company that cares about money more than you is risky. But losing devices with passkeys is a big problem too. Even if passkeys are saved to your Google, Apple, or Microsoft account, if that account itself is behind a passkey, how do you access it if your phone holding the key breaks? If a disaster or fire happens, all your devices could be gone.
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.
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.
I don’t know about privacy, but the lockout risk doesn’t seem worse than losing your phone or Yubikey. You should have multiple independent ways to log in for any account you care about. Passkey will be one way.
Possibly two ways, if you have both Android and iOS devices and you register both? (I assume Android and iOS remain independent.)
Possibly two ways, if you have both Android and iOS devices and you register both? (I assume Android and iOS remain independent.)
What if one loses all their devices in a natural disaster, a house fire, or burglary, or lost baggage while traveling?
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.
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.
I think it's more likely that you'll lose your password by forgetting it? People forget many things without losing their heads.
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'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.
Passwords, particularly passphrases, are easy to remember and you can reuse a similar structure for probably decades:
- 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.
- 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.
Well okay, but now you depend on a password manager. Hope you picked the right one and backed it up?
I’m not sure this is better than using a device to log in.
I’m not sure this is better than using a device to log in.
You are right, choosing the right one (reading its whitepaper and what encryption it uses where), and backups are very important for those. I suppose logging into all of the services we use these days is complicated and not very secure no matter the method.
1Password literally asks you to print out your private key. Yet their hygiene is lauded.
So if passkey is just yet another way to log in, then all the security aspects are moot, no? The attacker could still attack the other login methods. E.g., even if the passkey is a secure surface, it does not replace the insecure attack surfaces.
ideally the site requires 2FA for those, or sends a confirmation email and makes you wait a few hours, etc.
[deleted]
Personally I don't want to be dependent on a third party like Google or Apple for my identity. That's never going to be acceptable.
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 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.
> I wonder if there's a fully self hosted passkeys option?
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...
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...
> If external authenticators work for you, physical keys (like Yubikey, Solokey etc.) are arguably self-hosted!
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.
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.
https://connect.mozilla.org/t5/ideas/support-webauthn-passke...
This page has a recent comment from a Mozilla employee on Firefox support:
04-24-2023 04:39 AM
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
Hmm that's nice actually!! Because I only need the first one and perhaps the second, I will not do full passkeys until it becomes possible to self-host it anyway.
I really hope it will come to all platforms though. Not just Windows or Mac but also Linux and BSD.
I really hope it will come to all platforms though. Not just Windows or Mac but also Linux and BSD.
> 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.
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.
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.
> Their authenticator apps that they do have are terrible and my security would be improved if I could just use a simple 2FA app.
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.
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.
How is this different than a password manager with encrypted cloud backup? Your recourse if someone breaks passkeys is legal, not technical. Security must be a balance with functionality, and this is a huge improvement over passwords. (Tangentially, it would be great if we got cryptographic digital identity cards like Estonia has for signatures but that’s more of a long term goal)
Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.
Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.
The difference is that I can choose my password manager on iOS (and thereby pick my desired security level for password synchronization or opt out of it completely), but not my Passkey synchronization backend: iOS forces these to be stored in iCloud Keychain. (Passkeys are unavailable without iCloud Keychain [1]!)
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...
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...
Okay so use a YubiKey?
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.
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.
Sure, I already do that, but why shouldn't there be a choice in on-device passkey implementations just like there is for password and HOTP/TOTP authenticators?
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...
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...
> 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.
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.
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.
> Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.
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.
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.
> 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.
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.
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.
I agree there should be a way to opt out of system level ecosystem passkey sync with a big ol’ “you’re fucked if you don’t back these up somewhere” click through warning.
That's exactly what I want, ideally at a per-passkey level.
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.
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.
Putting on my "personal opinion" hat;
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.
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.
Yeah this is fair. It blows my mind that platform players don't understand that the security posture needs to be configurable at a per-credential level. The hope would be that 3rd parties step in and provide implementations that afford these options to users, but that would require platform players to stop dragging their feet on allowing PW managers to hook in to WebAuthN challenges as a credential store/backend.
> The difference is that I can choose my password manager on iOS
This is what you expect when you buy into the closed Apple ecosystem.
This is what you expect when you buy into the closed Apple ecosystem.
> Tangentially, it would be great if we got cryptographic digital identity cards like Estonia has for signatures but that’s more of a long term goal
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.
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.
> Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator
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.
https://www.zetetic.net/codebook
https://github.com/sqlcipher/sqlcipher
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.
https://www.zetetic.net/codebook
https://github.com/sqlcipher/sqlcipher
> password and TOTP convenience
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.)
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.)
Codebook links passwords to specific websites/RPs. Some people don't take phone calls from random callers.
Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?
Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?
> Codebook links passwords to specific websites/RPs. Some people don't take phone calls from random callers.
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.
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.
> sometimes auto-fill fails
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.
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.
> 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?
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?
> Codebook links passwords to specific websites/RPs.
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.
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.
You have the option to use a non cloud password sync method today. Best of all, that can sync a single password or private key across multiple vendors. This locking down inside bubbles really needs to go for me to want to use passkeys, I don't want to register 3 separate passkeys for each account I want to register 1 and sync them between my devices.
You’re not the target. Your average user who doesn’t even know what a password manager is or doesn’t want to use one is.
Agreed I'm not the average user but what does that have to do with the passkeys not being exportable between devices/clouds and instead being forever locked into only that vendor's cloud? The average user does not own only Google or only Apple or only Microsoft products nor do they want to enroll every account for every new device manufacturer key store instead of have options to use something else. This isn't predicated on existing use of a password manager it's just also a downgrade from that aspect of them.
For the client-side, the spec is comprehensive in allowing the authenticator to decide whether backups are allowed. In this case it's iOS not exposing that to you as a user. I get why you'd want this, but trusting Apple to store your single-device passkeys for high-stakes credentials but not trusting them for syncing them is somewhat of a very specific threat model I'd say, and definitely not in Apple's own interest to support, to your detriment.
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.
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.
> trusting Apple to store your single-device passkeys for high-stakes credentials but not trusting them for syncing them is somewhat of a very specific threat model I'd say
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...
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...
You can't even use Passkeys on iOS without using iCloud; if you opt out of iCloud, Passkeys are disabled.
Apparently so; I just saw that as well (and edited my post). Bizarre.
Between that and completely removing anonymous attestation (i.e. implicit device binding), it makes me wonder what Apple's motives here really are...
Between that and completely removing anonymous attestation (i.e. implicit device binding), it makes me wonder what Apple's motives here really are...
> Today, Google has sent me an email about their intention to deprecate their (device-bound) iOS authenticator
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.
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.
Ignorant question:
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)
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)
I like to explain it like this:
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.
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 generalized solution to this is allowing 3rd parties to be your passkey provider, so that you can choose how your passkeys are stored
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.
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.
> Would this be a thing that the passkey folks would be OK with? That would ease a lot of my hesitation.
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.
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.
If I'm understanding you correctly, then I should be able to write my own manager to behave in a fashion that is in line with my wishes. Is that correct? That would be a nice escape hatch to have available if need be.
> 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.
> 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.
> On the other hand, if that's the result of doing that, then there'd be no gain.
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.
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.
[deleted]
Yes you can just use a hardware FIDO token like a Yubikey as your passkey.
And you can enroll more than one, so if you lose or wreck one, you’re not locked out.
And you can enroll more than one, so if you lose or wreck one, you’re not locked out.
This is not really the same thing as what GP is asking? They're asking about backing up existing keys, you're talking about creating new ones. I can back up my entire password database just by copying a file. To "back up" a Yubikey I buy a new key then I individually visit every single site I have an account on and attach a new key one by one. That's not equivalent.
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.
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.
You are describing the tradeoff made by passkeys, yes. The idea is that it shouldn't be possible for someone to phish your passkey, because lives on a piece of hardware and signs challenges, but is not transmitted to the requesting party (or to anyone).
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.
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.
> The idea is that it shouldn't be possible for someone to phish your passkey, because lives on a piece of hardware and signs challenges, but is not transmitted to the requesting party (or to anyone).
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.
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.
So what I'm hearing through all these answers (many thanks for the info!) is that my original question of "am I screwed if I arrive to somebody's house naked/robbed/with a broken device", the answer is "yes. Thorougly. Unpleasantly. By design."
Am I missing something here?
Am I missing something here?
To be fair -- if you go out and buy another device owned by the same company and you go through their recovery process (and are capable of going through that recovery reprocess) and you stay in their ecosystem like a good little consumer, then you'll be OK (although you won't have immediate access to those accounts until after you've purchased and set up the replacement device).
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.
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.
> 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.
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).
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).
> Why do the blessed vendors get to do that but not 3rd parties?
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.
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.
Right. I just wanted to make that clear. That’s why I say there’s no fundamental difference between the two technologies and compare webauthn to passwords of yore.
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.
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 come down really hard on passkeys sometimes, but I'm not opposed to the idea of using keys for authentication. I think that's an amazing idea.
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.
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.
I like the passkey idea in the general sense, too. But what I don't like is the involvement of a third party, and the loss of control over my own critical data.
Wait
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?
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?
> 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?
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.
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.
> because lives on a piece of hardware
But it doesn't, unless you opt to use something like a Yubikey, right? I mean, you can sync passkeys through the cloud...
But it doesn't, unless you opt to use something like a Yubikey, right? I mean, you can sync passkeys through the cloud...
I think there's a difference between being able to backup a file (like I can with keepass password database) to any device,format or location I choose, vs backup my iPhone to Icloud,because for all intents and purposes that's just secondary memory/storage for my one device.
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!
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!
Would be nice if there were something like pass-otp for passkeys :)
[deleted]
I'm aware of that, yes, but that doesn't really address my question (or use case).
> 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.
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).
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).
So can I set up a self-hosted solution?
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.
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.
"And... am I the only person completely dreading this system? Passkeys sound... like a nightmare?"
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.
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.
> Are Passkeys, at some level of abstraction, permanently replacing "something you know" (password) with "something you have"?
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).
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).
Yes, it replaces something you know with something you have and something you are. The hypothetical scenario you describe is a downside.
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.
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.
This is my worry, but you now you just have to make sure you can access your keychain.
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.
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.
Dumb questions:
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)?
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)?
> 1. what's the backup login mechanism when you lose your mobile device?
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.
> 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.
Like the commenter you are responding to, I still don't understand how any of this can possibly work in practice.
> 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?
> 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?
> […] 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?
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.
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.
> 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.
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?
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 are synced to the cloud by default on iOS and Android, which is probably a good idea for many use cases,
Gtfo.
Gtfo.
Here's what Google has to say [0]:
> 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.
[0]: https://developers.google.com/identity/passkeys
> 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.
[0]: https://developers.google.com/identity/passkeys
How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits.
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.
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.
>with a fingerprint, a face scan or a screen lock PIN
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.
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.
> And just a daily reminder that biometrics are usernames, they are not passwords.
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.
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.
> 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
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."
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."
This is so true - most older people I've worked with have major problems with touch devices. No one has come up with a satisfactory solution. This is not a new problem - I remember working with my grandfather in his 80's on a 286 equipped with a mouse - his arthritis prevented him from accurately positioning the mouse. Today's touch interfaces are far worse. And fingerprint scans are very difficult to get right and use with older people. Maybe face scans are fine but I've never trusted them. Regardless of security logins, there are a host of other issues - complex navigation, complex and confusing layouts (especially desktop), and hard to manipulate controls. One example, a simple zoom or skype call - why hasn't anyone ever developed a simple device to allow for same without having to use intricate controls. I've always imagined something similar to the video enabled nest or alexa devices but with physical knobs and push buttons. There's a very large market being ignored for some reason.
> There's a very large market being ignored for some reason.
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.
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.
[deleted]
> No one has come up with a satisfactory solution.
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.
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.
Forcing my dad to carry around and stick something on his finger just to get into his device, seems rather overkill, don't you think?
People carry around earpods, keychains, wallets. What's one more little dongle on a keychain?
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.
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.
It might not be that the android is crappy. Some people's fingerprints stop being readable as they age, and there are various injuries and diseases that have that result.
Essentially every biometric has a population they won't function well with.
Essentially every biometric has a population they won't function well with.
It's 100% accurate. And I get why it may not seem helpful, but I think this is simply due to this industry trying too hard to cater to people who want things to be 6-year-old level easy.
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.
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.
> It's 100% accurate.
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.
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.
Good point, you're right. And with e.g. federal agencies, this fine.
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.
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.
Your points are taken, but I do believe that the "something you are" is better than the "something you know" and "something you have" pieces -- as the knowledge or the thing you have can be stolen.
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?
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?
If convenience plus precision are your only goals, sure. But this requires probably too much trust in the systems. I'm fine with the FBI having that power and information.
Google, who I don't pay and doesn't owe me much, not so much.
Google, who I don't pay and doesn't owe me much, not so much.
Your fingerprints change over time (mine are different from just five years ago -- as I learned when recently renewing a visa a few weeks ago).
Those are all factors in multi-factor authentication. If a service does not require the "something you are" there's still good security if they require the other two factors. If the only required factor is "something you are" that's bad security.
They all require the "something you have" as well. Pretty much all the face recognition / finger print tech on mobiles is locked to a single device.
> 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.
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.
> Please provide evidence that biometric data has ever been extracted from a major platform
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).
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).
And then extrapolate to how those biometric factors could be changed outside of your control -- car accident requires facial reconstruction. Or a fire burns your fingerprints.
I cut myself on a cheese slicer once and had to use PIN for unlocking my phone for a week or two while the cut healed. Annoying, but that's what the fallback PIN was for I guess.
Actually, the PIN isn't a fallback - the biometric is just a more convenient option once the PIN is "cached".
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.
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.
I don’t understand how this could work actually. From a couple of photos on the social media you can likely recover the 3d geometry of the face. From that, if the signing algorithm is known, you should be able to replicate these passkeys.
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?
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?
The biometrics like your face or fingerprints aren't used directly with the site you're trying to log into and would never leave your device. It's just used to unlock your phone/tablet/computer/whatever's stored secrets to sign a message verifying it's you. If you don't trust the biometric systems on your device or are worried about someone stealing them and trying to fool your device's hardware, you can always just not use them and just use a passcode/password to protect your device instead.
The problem is not that biometrics are leaking from my device. The problem is that faces are already on the social media. And that the biometrics of the face can be reconstructed extremely easily and at scale.
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.
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.
That’s not my understanding of how it works.
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.
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.
[deleted]
How does my use of faceID on my iPhone promote de-anonymization if it doesn’t leave my phone?
Everything you’ve described can be done whether or not I use biometric to sign into a device, or even own a device?
Everything you’ve described can be done whether or not I use biometric to sign into a device, or even own a device?
Biometrics are shitty usernames too. They might change, it's just outside of your control.
My apple touchID never works because I rock climb and I guess that abrades the skin too much
My apple touchID never works because I rock climb and I guess that abrades the skin too much
i rowed on a crew team for many years. The pads of my fingers were all worn down. I was rejected three times for "bad fingerprints" when applying for US citizenship.
It's not as rare as people think for fingerprints to be messed up either permanently or temporarily. Which amazes me, actually, because I'll be willing to be pretty near 100% of adults have, at least once in their lives, burned or otherwise injured their fingers in a way that alters their prints.
Relying on fingerprints to gain access to things on a regular basis never seemed like a great idea to me.
Relying on fingerprints to gain access to things on a regular basis never seemed like a great idea to me.
> you cannot change biometrics
Bodies are not invulnerable to damage. You can absolutely change your "biometrics", you just probably wouldn't _want_ to.
Bodies are not invulnerable to damage. You can absolutely change your "biometrics", you just probably wouldn't _want_ to.
> biometrics are usernames, they are not passwords
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.
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.
But most biometrics (at least faces and fingerprints) make terrible passwords. They can be copied and they're very hard to change if you need to.
Because it's a PIN protecting a certificate stored on the device. Even if you know the PIN but don't have access to the device, you can't use it.
And the pin is the same functionality as activating a hardware authenticator like a Yubikey.
… which have historically yielded credentials at any touch, without a need for a PIN, fingerprint, or face scan.
This is more secure, passwords can't be stolen from the site. Sure, let's go with the assumption that your phone can be stolen. It would be only your phone. If a site has 100 million users, an attacker could steal 100 million passwords. With this approach, the attacker would have to steal 100 million phones. No matter what password manager you use, with a password length of 100 characters. The entire password list (encrypted) can be stolen.
This keeps you from ever sending the password to the site (similar to e.g. SRP).
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.
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.
> How is this more secure?
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.
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.
A PIN entered onto a physical device like a smartphone can be rate limited (see iPhone progressively increasing PIN timeouts). If you try to rate limit password entry to an online service, you make it trivially easy for an attacker to lock out a real user.
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.
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.
This has been bothering me, a lot. Google talks [1] about how Passkey replication is e2e encrypted between devices, but AFAICT they're just using a pin + key derivation. A six digit pin is like 20 bits of entropy before a KDF. [2]
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??
[2] https://www.omnicalculator.com/other/password-entropy?c=SGD&...
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&...
Talking about Apple here because it's what I'm more familiar with, and their security whitepapers are more widely available.
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
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
Thank you! I'm trying to understand more deeply, so I appreciate it. :)
> 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 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... :)
Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher. The question shouldn't really surround the effective entropy of the PIN, but rather the systems in-place to protect bypassing safeguards in the key derivation function which render the actual entropy of the PIN irrelevant. There probably isn't no way around that safeguard, but as more of this gets moved into trusted compute silicon the level of sophistication required to breach it goes up; and is one hardware revision or operating system update away from being made moot again.
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).
[1] https://future.1password.com
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).
[1] https://future.1password.com
> Sure, but if that key derivation function is protected by a "you get 10 attempts then we wipe the keys" safeguard, the effective entropy is much higher.
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.
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.
Password + password manager can be trivially phished. PIN can’t, because even if you somehow phished a user you can’t use it.
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.
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.
FWIW, my password manager has prevented me from being phished because it wouldn't auto-fill the password.
it's more secure on the back end. The DB will store a hashed unique pass phrase that isnt shared with anyone else.
You enter a pin, the web server sees a public key that only your side has the private key to.
You enter a pin, the web server sees a public key that only your side has the private key to.
> it seems strictly worse than a password + password manager
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.
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.
You're forgetting Oyler's Law of Passwords: Humanity will be forced to try each wrong approach to passwords, one at a time and trial-and-error, for all eternity.
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?
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?
Being tied to a device, it defeats the most serious threats of phishing and weak passwords, for which attacks can be mounted on a global scale.
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.
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.
> 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.
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.
The devices are far from being security bastion.
[deleted]
> And, unlike passwords, passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes.
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].
[1] https://robertheaton.com/almost-scammed/
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].
[1] https://robertheaton.com/almost-scammed/
> In the past number of years only after a phone is attached do other 2FA methods like TOTP become accessible as options.
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.
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.
I don’t have my phone number “registered” with Google. IE it does not appear in my account.
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.
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.
There is a legal advantage that passwords have that passkeys and FIDO and so on do not have. In civilized countries, no one can force you to hand over a password (as you have a right to not incriminate yourself). That does not hold for property which can be confiscated or even biometric attributes which can be taken against your will legally.
Theoretically, passkeys could still offer this advantage if they are stored exclusively on my phone which is encrypted and secured with a password.
Theoretically, passkeys could still offer this advantage if they are stored exclusively on my phone which is encrypted and secured with a password.
Passkeys are an authentication mechanism, and as such replace (authentication) passwords, not (encryption) passphrases.
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.
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.
Great! Where I can type those passhphrase in google mail or o365 or million other serivces to secure my data ?
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"
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"
> Then why you're even talking about the distinction ?
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 [...]
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 [...]
This is incorrect because you’re conflating access by request and access with a court order. Without a warrant, or even probable cause, police can get some meta data, but not everything in the cloud. In many places police can force you to use biometrics to unlock devices, but not compel a passphrase. (Passphrases are significantly harder for e.g. Greykey to glitch brute force than PINs.)
What's "access by request"?
> 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...
> 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...
The police just ask the company for the data.
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.
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.
> In civilized countries, no one can force you to hand over a password (as you have a right to not incriminate yourself).
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.
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.
This was not my understanding so I looked it up and found this: https://www.reuters.com/business/legal/us-supreme-court-nixe...
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?
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?
Exactly.
As I said, civilized countries. Unfortunately, lots of countries do not adhere to their own constitution anymore, which I believe is mostly caused by a lack of technology understanding. I would guess that the judges that force Alice to hand over the passphrase for her phone encryption wouldn't force the CEO of a company to hand over the key to the safe that contains incriminating info.
In Canada it has been upheld that you cannot be compelled to divulge your passwords as it violates the Charter of Rights and Freedoms.
And if you don't comply?
With biometric data like FaceId or fingerprint it's easier for them to get access.
With biometric data like FaceId or fingerprint it's easier for them to get access.
I think in Florida v. Voigt someone was sentenced to 6 months for not handing their iPhone password in an extortion case. If I recall, the phone was ultimately hacked to get the evidence.
Pretty much only the US explicits this right. I know France tacks on more charges to protesters who refuse to unlock their phones when arrested.
Has that been tested with the ECJ yet?
As opposed to where you store your passwords? I can only speak for me, but they're in 1Password; if the police get my phone, the same thing protects 1Password as would protect these passkey private keys: FaceID, maybe a PIN if a lockout can be triggered before they get it, and at its core, the Secure Enclave. There's no legal advantage to passwords, unless you were actually memorizing every password you've got (and if that's the case, son we got bigger fish to fry).
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 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.
Argh.
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
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
"Personal opinion" hat on:
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.
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.
> we need to work on fusing all the factor-types into 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.
Would this not make logging into things three times more painful? Even just using 2FA is a pain right now.
This is another hot take, the word factor is overloaded (by marketing people) to be really confusing.
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..
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..
This is a good start, but like everything Google introduces, it's only designed to be useful to Google, and has a number of flaws:
- 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)
- 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 either insecure or unreliable. Let me explain:
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.
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.
It would be a bad and dangerous idea, if what you said was true; but it isn't.
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.
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.
> Now one could allow backups of a passkey
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?
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?
> 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.
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.
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.
> 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.
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).
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).
You seem to be under the false impression that passkey databases are stored completely unencrypted and unprotected on disk or in the cloud. Obviously those details are implementation-dependent, but I don't know of any passkey implementation that works that way.
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...
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...
As an administrator, I hear you, but we have to adapt. Passwords are awful. On the whole, the effort and energy spent training people on passwords, battling phishing, dealing with password managers, cleaning up from breaches, and more… passwords can't die soon enough.
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.
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.
I'm looking forward to such glory days. Right now, however, none of the solutions available are ones that I could live with if I had to use them for everything. For one or two very sensitive things, sure, but for everything? It's less of a pain to use long, random passwords.
This is just like using a long random password, except that it's cryptographically verifiable without ever leaving your device.
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.
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.
> you cannot make a backup of it
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.)
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.)
Maybe for browsers on Windows it'll default to storing the key purely on-device, but especially with iCloud Keychain the key is not encrypted by the on-device processor.
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-...
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-...
The point of passkeys isn’t to be perfect — the point is to replace passwords, which are already far more imperfect than passkeys. The bonus points with a password is that every site that uses them has to secure them properly and theft of passwords, in plain-text, hashed, etc form is common.
For an end-user, reliability and ease-of-use trump security. Passkeys are imperfect in the wrong places imho.
Imagine for a moment that instead of all the time wasted on this, we just implemented a protocol amongst the browser makers which allowed a secure password prompt to be requested, and required strong-hashing before sending anything over the wire?
Which would be easier to use and more effective.
Which would be easier to use and more effective.
If you hash before sending anything over the wire then the hash of your password is now your password, meaning that if it leaks it amounts to basically the same as your password leaking. Granted, applications may choose different hashing algorithms, provide their own clientside salts, etc. which would be really nice. To be fair, I believe more systems should be doing this nowadays, it's really weird to have to send your actual password to the website if a hash would suffice. Then the website could store the salted hash of the salted hash of your password in their database.
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.
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.
If a common browser protocol required the password to be salted with an application supplied value and then rehashed with the domain name it's served on, there'd be no way to phish a password.
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.
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.
The idea seems to be that you will either trust a provider like Apple or Google to keep you private key safe and let them sync it around, or you will create a passkey for each device that you use. If you lose the device, deauthorize the passkey. If you somehow lose the passkey itself, create another one, either by using an older form of authentication, or by creating using a different device to authenticate. There is no need for passkey recovery or backup.
I find this to be a regression in terms of usability and security as well.
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.
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.
What would be a better idea, then?
I wrote about my experience with passkey support on other services here: https://news.ycombinator.com/item?id=35758918. That experience was mostly negative. For anyone implementing this, the user experience matters and requires usability testing of a lot of combinations.
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).
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).
> it just said I already had a registered key on this device
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).
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).
This was on an iPad. My experience before had been that I was able to register an iCloud passkey for Google 2SV when using Safari on iOS/iPadOS, but I was unable with Chrome.
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.
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.
The linked security blog post[1] has a lot more of the technical details and can clear up some of the questions/confusion that people have added in the comments.
[1]https://security.googleblog.com/2023/05/so-long-passwords-th...
[1]https://security.googleblog.com/2023/05/so-long-passwords-th...
Those guys should not work in identity and access areas. Period. Only one reason says everything: they provide no support. Customers will be left in the cold, minus all their belongings.
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.
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.
+1 everyone should read that - 60% of comments on this thread are explained away by reading this.
This looks and feels like passwords with extra steps...
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.
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.
Passwords can be both stolen (they are valid for multiple authentications) and are susceptible to phishing/MITM attacks.
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.
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.
> Passkeys are synchronized to your device ecosystem ... and soon also third-party password maangers on Android
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.
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.
Not quite: Passwords are long-lived bearer tokens, which can be phished/MITMed (exclusively using auto-fill helps, but non-technical users are still prone to be phished) and are administratively harder to securely manage on the backend of the relying party.
> Passkeys are synchronized to your device ecosystem vendor by default (i.e. Google or Apple, and soon also third-party password maangers on Android)
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.
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.
Me too – I'd much rather trust my password manager, so I'm hoping that platform/browser APIs will eventually become available that will allow such third-party implementations. (Android is planning to; iOS hasn't stated anything yet.)
Even then I would probably not add my bank credentials or other high-sensitivity things there.
Even then I would probably not add my bank credentials or other high-sensitivity things there.
The solution, for you, is a cloud synced passkey manager, possibly a custodial one.
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.
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.
So in the event that i lost everything, i mean catastrophic, like my house burned to the ground with all my belongings, i have no kin nor "trust alternate people" configured for my account, my password manager requires my "synced in google/apple drive/cloud" passkey or my last known device, i can't retrieve it in anyway, how can i recover my account?
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.
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.
Sure. The idea of authenticating a human based on something you know, passwords, is still useful and not going to die anytime soon. But it would be a much much safer world if you only had to remember one or two passwords than if you had to try and get passwords right for every service you use out there. A single password protecting a keychain full of passkeys is still better than reusing that same password on every single site. Hands down no argument. This is why passkeys exist. They are objectively a superior technology and you are objectively safer using them, as long as you can comfortably recover from disaster scenarios. The fact that you might choose to still use a password to get access to your passkeys is, well, up to you. You're free to take whatever posture makes most sense to you. Someone else might "trust alternate people" and another might keep a printed copy of all their passkeys in a bank vault. But whatever you choose as your preferred recovery/bootstrap method, using that to get you to a per-site passkey world makes you safer than what you're currently doing using symmetric keys everywhere.
> Trust the security experts when they say passkeys are more secure.
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 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.
Understood completely. I was only trying to articulate that there are tangible security benefits to using passkeys over passwords and no/zero theoretical downsides. A 32byte random password is just an edDSA private key that's not private, after all, and the two can be managed the exact same way with none of the device-bound woes. That is, all assuming that platform vendors commit to providing the same affordances for passkeys as they do for passwords in terms of allowing users to delegate to 3rd parties to complete signing of the WebAuthN challenge.
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.
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.
> The solution, for you, is a cloud synced passkey manager
This is in fact the only possible solution you get on iOS, and the default solution on Android.
This is in fact the only possible solution you get on iOS, and the default solution on Android.
The advantages are very poorly explained in the article.
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.
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.
My takeaway is that this is infinitly more secure for those do not care about security - the "password1234" crowd, actually their account may even be secure from them logging in from now on -, for the rest it is about the same, but different.
Let’s say I have a passkey in Chrome and no password. How do I add a passkey to iOS so that I can login via both mechanisms?
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?
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?
At least for the Google account, it looks like you can add multiple passkeys.
Sure. But am I still locking my ability to access that account permanently to Google? Can I login via Chrome on an Apple/Windows platform and add a passkey there?
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).
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).
Google actually outlines that very scenario near the bottom of their announcement:
> 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.
> 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.
> 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.
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.
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.
All of that just locks you into Apple’s platform and now I have a problem copying that passkey to chrome.
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.
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.
AFAIK QR code export is not a thing, just speculation for how passkey exports could work (which I doubt since QR codes get hard to scan the more data you pack into them; maybe you could ask the user to hold the camera to the screen for a minute while the target machine cycles through each passkey, or cycles through qr code data itself to facilitate error correction and 100% data transfers)
Seems to be a thing on Android/Chrome:
https://news.ycombinator.com/threads?id=vlovich123#35802511
https://news.ycombinator.com/threads?id=vlovich123#35802511
That commenter is mistaken. The QR code is for authenticating on your computer via your phone over Bluetooth. It does not export the token to be used by another authenticator, you have to have the device with the Passkey anytime you use this QR code method.
> that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account
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.
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.
If that is a concern of yours, there is an option on Apple devices to disable iCloud syncing for passwords/credentials. This would limit passkeys to strictly device-only.
Actually, that would disable passkeys [1]:
> 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...
> 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...
> 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.
No lock-in; you have two phone OS vendors to choose from!
No lock-in; you have two phone OS vendors to choose from!
For Chrome on desktop OS, it will popup a QR code that you can scan it by passkey-registered phone like[1].
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...
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...
That’s interesting and I think potentially addresses the concern. I don’t think I’ve seen Apple have a QR scanning code option for passcodes but it’s possible that’s just integrated into normal QR in-camera. Apple doesn’t have a QR export does it?
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.
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.
> I don’t think I’ve seen Apple have a QR scanning code option for passcodes but it’s possible that’s just integrated into normal QR in-camera.
Exactly — I just did this, and it's that simple.
Exactly — I just did this, and it's that simple.
You transferred a passkey from chrome to iOS?
In my case I created (1) one passkey for the Apple ecosystem, and (2) a second passkey for Chrome. I had to add the Chrome-specific passkey because Google isn't using native OS passkey support via Keychain.
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.
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.
You are confusing the location where passkeys are stored (your Android, your iPhone, your Yubikey) and where they can be used (to access your Gmail account).
I don't think they are; they're effectively asking whether accounts will support multiple passkeys. This is a reasonable question IMO: if the protocol is not well-designed different services (account providers) may have different rules about how many passkeys can be attached to your account in their system. (E.g. "2 passkeys ought to be enough for anybody!") And for how they can be managed: removed and updated, particularly.
And if you have your google account banned/disabled for whatever reason, then what?
Indeed I wouldn’t trust Google or Apple to be the only place my passkeys are stored. I’m currently a 1Password user and their upcoming support looks like it could address this issue (I’m not in any way affiliated with them)
https://www.future.1password.com/passkeys/
https://www.future.1password.com/passkeys/
Sure but this currently means a virtual authenticator that puts unwrapped passkeys in the same memory as other applications, leaving only the OS and no other physical measures to protect a direct-memory read. That might be acceptable for your threat model, but no other currently adopted WebAuthn authenticators work this way other than password managers that don't want to be left out.
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.
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.
Thanks for that info! Still just learning about this stuff.
Passkeys should still be on your local device. Account recovery should fall back to e-mail magic link or government credential proofing (depending on data sensitivity and threat model).
(manages customer IAM for a FinTech)
(manages customer IAM for a FinTech)
And when that last device dies in an accident or force major, what's next? Proofing won't work because if the solution is really as secure as it should be then neither party can have access in an unencrypted form.
[deleted]
[deleted]
Users pay a subtle price for the perceived convenience of passkeys when it's time to migrate to another platform.
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.
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.
I really wish these “password killers” would acknowledge that we will never eliminate passwords. Ever. There’s too many under-funded applications deployed out there that have no resources to add passkey support. Password managers are an excellent place to progressively enhance the user authentication story and could support more advanced schemes like passkeys while remaining compatible with the registry of deeds site from 1999. Instead, it’s always presented as some other thing (usually conveniently tied to Chrome) that you have in lieu of your password manager.
Actually I'd see a future where some of those password killers might replace passwords, even for some of the under-funded, under-manned applications out there.
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.
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.
Yeah, none of big tech wants that, they don't want to make it easy for 3rd party.
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.
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.
> Yeah, none of big tech wants that, they don't want to make it easy for 3rd party.
iOS has an API for password managers and HOTP/TOTP authenticators. Android is planning to introduce one for passkeys.
iOS has an API for password managers and HOTP/TOTP authenticators. Android is planning to introduce one for passkeys.
Just here to note that there are several huge problems with this approach from an actual security standpoint:
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.
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.
I completely disagree. Even if you are concerned about evil maids (which are comparatively very rare), it is not the case that passkeys are "strictly worse" than a password. The core advantage is that they cannot be phished. And not only does phishing exist, it is way more common than people stealing your hardware used to authenticate you with a passkey.
In the case of networked hardware, the stealing the device part is a relatively minor concern.
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.
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.
> 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.
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.
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.
On the contrary, it _is_ 2FA: One factor is something you have (the phone) and the other is something you are (your biometrics). You need both to log in.
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.
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.
The phone unlocks with the bio-metrics but the passkey has no additional lock. Be careful to take note of what thing you are actually "unlocking".
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).
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).
Came to HN today figuring there would be a thread about this, after getting an email about it from Google themselves, riddled with things causing me to wonder if the message was spoofed:
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!
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!
>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.
[0] https://vimeo.com/355556831
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.
[0] https://vimeo.com/355556831
> I've seen countless "how to spot phishing" guides
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.
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've lost a lot of confidence in Apple's keychain. I had been using iCloud Keychain and backing up username and password into BitWarden.
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.
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.
Just a heads-up if you're planning to use passkeys with iOS/macOS: Might be fixed already, but last time I tried it out it seemed like iOS only stored a single passkey per domain. If you first store a passkey for a@domain and then later on store a passkey for a different user b@domain the a@domain passkey is overwritten without any warning. Or at least this seemed to be the case a couple of months ago when I tried it out.
That would only happen if the site isn't properly giving the passkeys identifiers. Having single passkey/username combo is working as intended, but it shouldn't be overwriting different usernames.
For me at least it works. I have multiple accounts for the same domain and iOS/macOS prompt me to choose from the last one used, or I can choose to pick from a collection.
All the way back in iOS 15, when getting passkeys meant building an xcode app to access the developer menu and enable passkeys, I had no trouble storing multiple per domain when adding passkeys to GitHub. Maybe the site you were trying to use sent the same `user.id` for both requests? /shrug
I don't know if this is the correct tactical implementation, relies upon having a cloud-based account that never goes away or gets disrupted in any fashion etc etc etc etc.
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.
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.
And once again, with a Google Workspace (or whatever they call it these days) account, "Passkeys aren’t allowed on this account. Contact your admin for help".
I am the admin. Doesn't appear there's any way to help.
I am the admin. Doesn't appear there's any way to help.
Paying customers can't use this feature.
> 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...
> 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...
It seems like passkey isn't available for Google Workspace yet. (I'm a Google Workspace admin as well).
Please don't. In case of emergency, all that fancy stuff is unrecoverable - while passwords continue to work.
One weakness with passkeys is that a person can't login to an account with just information that they know. I.e. they need a authorised device. Given that devices can be lost, it seems that folks that only own one device should not use Passkeys. Most passkey users should probably have a minimum of three biometric enabled - authorized personal devices if they want to use passkeys. This might be the biggest roadblock to adoption as few have this many personal devices.
The goal from all vendors is absolutely to have passkeys backed up to the cloud. In fact, passkeys on iOS required iCloud Keychain to be enabled. Then the only issue is reauthorisation with the vendor when the only trusted device is lost. It would be surprising if vendors didn’t cater for this scenario.
It looks like a good change for the average user, a secret stored on the device is likely a whole lot safer than just having a password. Having it as the only factor seems less secure than password + good extra factor like TOTP on device though.
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
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
Passkeys can also be used in addition to passwords, as a form of 2FA. I've seen a number of sites approach Passkeys in this manner.
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.
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.
It seems there's no way to prevent an Android device from creating and registering a passkey when signing in to a Google account on the device. Also, once you opt in, there's no way to opt out of using passkeys except by signing out of all Android devices.
Great. Entrusting my Google account to my Fiio MP3 player for safekeeping was exactly what I was looking for.
Ok, Google. I'll bite.
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?
[1] https://support.google.com/accounts/answer/13548313
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?
[1] https://support.google.com/accounts/answer/13548313
I don't understand the hate for passwords. I want to keep my security in my head for as long as humanly possible. There was a whole movie plot about this [1].
[1] https://youtu.be/JrBdYmStZJ4?t=238
[1] https://youtu.be/JrBdYmStZJ4?t=238
I will never weld my login to a physically so fragile and unpredictably high maintenance and volatile thing as a mobile phone. It is also cumbersome for casual logins and increadibly risky for important ones. Thank you, but no.
(good thing I already started to migrate away from the Google universe)
(good thing I already started to migrate away from the Google universe)
I’m a Linux user. I don’t have an android/iOS/macOS/Windows machine.
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.
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.
Yubikey is supported; which has linux compatibility.
Passkey is an open standard and there exists FOSS clients which support it.
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?)
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?)
[deleted]
[deleted]
[deleted]
[deleted]
Until there is a viable way to sync passkeys between all devices, all platforms, and all browsers, I will be happily sticking to my passwords. The security benefits provided by passkeys are not enough to offset the ecosystem lock-in that passkeys cause.
What ecosystem lock-in are you talking about, exactly? I just created a passkey for Chrome on my macOS desktop and another on iOS. The Chrome passkey will sync to Chrome for Windows, my iOS passkey will sync to my other Apple devices, and I can create more as needed.
For every platform/ecosystem you are using (Chrome, Apple iCloud), you had to create a new passkey. For people using multiple different devices and platforms, this is a headache. I want to sign up once and be done with it.
> I want to sign up once and be done with it.
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.
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.
Agreed. If mobile operating systems allow password managers to support Passkeys, and password managers implement the functionality, then I will absolutely switch.
I understand crypto/web3 are hated because of all the scams and NFTs out there. However, I worked on a web3 login implementation and I think it’s the best login/account experience out there. Basically, your private key is your password. You can use your phone, a browser extension or a hardware wallet (kind of the equivalent of a YubiKey).
It’s a pretty straightforward experience and it keeps the full ownership of the credentials to the user.
It’s a pretty straightforward experience and it keeps the full ownership of the credentials to the user.
This is how passkeys work
Except you can no longer back up your private key, so you must trust a 3rd party to restore access when you lose the only allowed copy.
It seems passkeys mostly operate in the cloud, like replication across all iCloud connected devices? This seems like a major point of vulnerability for the average user.
Private key infra in crypto/web3 tends to promote best practice as offline, paper wallet, airgapped devices, etc.
Private key infra in crypto/web3 tends to promote best practice as offline, paper wallet, airgapped devices, etc.
I’m not familiar with passkeys. Can you back it up as a bunch of words? Does it require a third-party thing or the implementation is fully independent.
So, what I take from this announcement and the linked article [1], is that:
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...
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...
What are the legal implications of passkeys? Are there any case law examples yet?
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.
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.
You don't have to enable the biometric part of this as you can still protect your device with a passcode/password only if you want. I just tested it and was able to use it with just my device PIN, no biometrics.
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
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
I'm glad most people here are recognizing that this is a stupid, stupid idea.
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.
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.
Passkeys as implemented by Apple/Google has serious limitations – your credentials are locked into their platform and tied to their online account (iCloud account or Google account). They won't let you use your phone as a FIDO2 authenticator via 3rdparty apps (like 1Password or Bitwarden). Your credentials are only as secure and reliable as their online account services are, and they are subject all the risks of state/corp spying, forced logins at cross-border transits etc.
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).
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).
What are the privacy implications for this? Are companies that see my passkey going to be able to link it to all my other accounts, or will each passkey be completely anonymous?
Passkeys are unique per Relying Party, in this case, google.com can only access passkeys for google.com. They can't even enumerate them, all they can do is pop up a dialog and wait for the user to select one.
Doesn't this just mean giving control of authentication to proprietary systems like google?
I can't find a single FIDO level 2 (or higher) certified implementation that is open source?
I can't find a single FIDO level 2 (or higher) certified implementation that is open source?
I'm curious to get a take on Apple's documentation for passkeys and iCloud Keychain Recovery Escrow system [1] [2]
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...
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...
My presumption has been that they will force a long recovery key to be printed by you for recovery OR the enrollment of designated trusted users that can approve an account recovery.
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).
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).
How do you handle delegation in this case? Let's say I want to delegate access to my account to a partner/friend/employee on a service that doesn't support multiple users per account, charges extra for it or outright doesn't want me to delegate access to someone else (so it's not always possible to rely on the website's cooperation).
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.
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.
You can create a passkey for your account on their device, e.g. by selecting "Use another device" when creating it, and scanning the QR with their phone (their phone does not need to be signed in to your account).
And if you both use iOS, you can Airdrop a passkey: https://support.apple.com/guide/iphone/share-passkeys-passwo...
And if you both use iOS, you can Airdrop a passkey: https://support.apple.com/guide/iphone/share-passkeys-passwo...
This is what I love about passwords. They are tangable and understandable. I would have loved if we could move towards a solution that has the benefits of passkeys (prevents phishing, strong secret, doesn't seen the secret to the server) without ditching the underlying secret being a somewhat human-readable password. It seems that in-browser password-managers get us 99% of the way there. I would have loved to do something like adding a PAKE system to regular passwords rather than a new system built on top of non-human readable keys.
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'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.
Also tangible and understandable is a registry of users who have access to your accounts, that allows you to grant and revoke access (at possibly different levels), without having to reset all your own credentials.
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.
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 up front, but once it's working, it's so much easier.
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.
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 now-unfortunately-named "Password managers" help with this by providing various mechanisms to sync keys with multiple devices, so that every time you get a new device, you simply need to authenticate and transfer the key store to the new device.
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.
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.
The accounts and services I use that support passkeys also support some form of account delegation, recovery contacts, legacy contacts, or family sharing. This includes Apple, Google, Microsoft, and self-hosted services through Authentik, Authelia, and Keycloak.
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.
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.
> 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
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.
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.
This is just a way to tie your identity more closely to your account, it doesn't make anything more or less secure. Every big silo is trying to do this constantly and once you recognize the pattern you'll see it everywhere. Never mind the inconvenience to the users, all that matters is that you are known to the system wherever you are and on whatever device you are using so that your profile can be closely matched to your various interests and intents the better to sell advertising (or your data, depending on the operator).
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.
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.
My thoughts exactly.
In the post linked and in the post explaining how passkey works they mention that none of biometric data is sent to google. The catch? More precise data about your devices and subsequently about you.
Forgive me if I sound dense but you would still want a password to unlock the private key, right? Otherwise, authentication is just "something you have" not "something you know + something you have." In which case, this headline might really mean "The beginning of the end of the password on the web".
Anyone know if it's possible to use this with Google Workspace accounts yet?
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.
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.
Same here, but note that in this post on the Google Security Blog:
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.)
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.)
Disclaimer: I work for Google but nothing I say here is Google's opinion or relies on any Google internal information.
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'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 just started looking into WebAuthn this week, and was annoyed that there is no simple way to begin: Chrome (on Ubuntu) doesn't provide a local authenticator, unless you use an emulated one. This means any site that wishes to use WebAuthn can't just say "let's do it for everyone," because not everyone might have a phone they want to use, or a security key.
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.
[1] https://stackoverflow.com/a/49479890
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.
[1] https://stackoverflow.com/a/49479890
It looks like this is a wrapper around public/private keys stored on a device: https://security.googleblog.com/2023/05/so-long-passwords-th...
There's no meaningful benefit of this over a password and 2FA authentication for users who are already proactive about security. I also doubt that passkeys will be protected by the fifth amendment the way passwords are, based on the "key vs combination" argument. While I trust Google password manager to help me remember passwords, I don't trust Google or any company to manage them for me.
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...
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 don't use my google account for much anymore, but I love the idea. I tried very hard to use it and... it didn't work.
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?
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?
When a company rolls out something new and exciting that will improve your life, ask yourself: why are they spending money on this?
Just stuffing more of our private lives into phones full of ads and tracking. Each time you unlock your phone Google makes money.
Just stuffing more of our private lives into phones full of ads and tracking. Each time you unlock your phone Google makes money.
There is a less sinister motive available - reducing customer support costs - but the default of syncing everything to the cloud does give me pause.
> the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN
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)?
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)?
In order to exploit the 6-digit password across the web, the attacker needs 1) the password, 2) web access from anywhere in the world. To exploit the PIN guarding your phone, the attacker needs 1) the PIN, 2) your phone. You can't prevent the attacker from having access to the internet, but you are probably reasonably good at protecting your phone physically.
Generally, most devices don't encrypt/protect your data with that 6-digit PIN directly. They store the important secrets like device encryption keys in some kind of secure enclave/processor that does things like rate limit the PIN attempts to prevent brute-forcing. What the fingerprint or face scan is doing is just unlocking that secured data a different way.
Many phones block access after too many false PINs, if the web password has the same feature there is no difference.
If your physical device can be unlocked remotely with a 6 digit number, not much, but that's not generally the case.
I still don't understand how the QR code flow works with using/creating passkeys on other devices. It seems it uses a bluetooth connection to your phone, but I can't find much documentation about the exact protocol
It's called hybrid transport, and the old name for it was caBLE. Yubico has a nice explainer here: https://developers.yubico.com/WebAuthn/Concepts/Hybrid_Flows... It's not fundamentally different than other transports for other roaming authenticators like a USB key; the QR code sets up a BLE connection between both devices and presents the authenticator with a challenge for it to sign and log in the originating device.
If I choose the screen lock PIN example (instead of face scan or finger print) why/how is that more secure and less resistant to attack than a password?
It’s a 4 digit number. What am I missing behind the scenes that makes it more secure?
It’s a 4 digit number. What am I missing behind the scenes that makes it more secure?
Lots of uncritical media coverage out their and to be fair, I am also quite hyped about killing passwords. Nevertheless there is certain aspects that I believe did not get enough attention yet, the biggest potentially being the switch from knowledge to possession factors.. not sure whether everyone is aware of the potential implications.
Some critical notes on Passkeys: https://www.jbspeakr.cc/fido-passkeys/
Some critical notes on Passkeys: https://www.jbspeakr.cc/fido-passkeys/
The technology of passwords has been around for millennia, never perfect, not terrible enough to throw out wholesale. As I said somewhere else, the democracy of authentication, the best of several imperfect options. Certainly I'm not securing anything of mine behind my phone (can be broken) or my face (can also be broken) on a proprietary system under Google's fickle control, when my brain is less likely to be broken (and if it's not, I'll have much bigger problems to worry about than getting into my accounts).
Regarding the statements that you need a Yubikey (for the FIDO part of passkey, given application support?) on GNU/Linux, at least Solo 2, Nitrokey 3, and Onlykey hardware keys have free firmware. I can't vouch for them, but maybe also see https://github.com/psanford/tpm-fido and https://github.com/bulwarkid/virtual-fido
> passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes.
What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?
What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?
1. You're tricked into visiting evil.example and don't realize it.
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.
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.
Yes, I understand how phishing with 2fa works. But to me, passkeys sound like 2fa with your fingerprint/smartphone PIN? What's actually different there?
The difference is in step 4. With SMS or one-time code 2FA (or passwords) you're just entering text into a website, and nothing verifies you're interacting with the right website. With passkeys or FIDO tokens, though, there's a cryptographic protocol that considers the domain: your fingerprint/PIN isn't sent to the website.
So, evil.example tries to log in and triggers the passkey thing on my smartphone. My smartphone asks "Do you want to log in to good.example?" Because I'm currently being phished and didn't pay attention to the URL "evil.example" anyway, I will confirm this on my smartphone and evil.example is granted access to my account. I don't see how this is more phishing resistant than current 2fa. How can my smartphone know whether I'm interacting with the correct website on my laptop?
> How can my smartphone know whether I'm interacting with the correct website on my laptop?
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.
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.
This is maybe an oversimplification, but the token that your phone gives your laptop includes "only valid for good.example". Your browser on your laptop then knows not to send it to evil.example.
Passkeys sign a web origin. If you try to phish one, the token you get won’t be valid for the origin you’re trying to authenticate to.
Eg you’ll get:
Token{domain:hax0r.net username:bob}
Eg you’ll get:
Token{domain:hax0r.net username:bob}
That is also an issue with 2fa sms, but it's not phishing.
Phishing is quite often how a SIM swap attack starts.
Yeah okay, but then just don't do 2fa via SMS. How are passkeys better than a 2fa app on my smartphone?
How does google make money? By having information about users and providing that to people who want to 'target' users. So in the interest of making a 'better' user experience we now have google passkeys. Is Google making this to help users or perhaps does it provide more ability to target users. Hmmm.....
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".
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".
What about 3rd party applications, say MUAs like mutt or Evolution? Will I be able to generate a passkey and store it in the desk-top's ssh-agent for the MUA to retrieve on demand?
run your own passkey server with https://github.com/authcompanion/authcompanion2
More Google tracking.
I wonder if they get your device fingerprint on login too.
I wonder if they get your device fingerprint on login too.
I've yet to figure out how passkeys can be useful for someone who switches between multiple devices (and platforms) throughout the day, and who wants to retain control over where tokens are stored. I have switched as many of my MFA credentials as possible to TOTP and have avoided Yubikeys because I don't want to be tied to a single piece of hardware that can be easily lost, or to an identity provided that may decide to lock me out...
From the Google Developer FAQ...
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.
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.
How do you do account recovery if you run a service using passkeys?
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?
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?
I was expecting this also meant that I could add a FIDO2 resident key as a passkey, but the google UI currently does not allow me to do that. That's fairly disappointing.
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?
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?
Auth is as secure as the weakest link - in the case of this it's your email and/or customer service
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).
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).
> Auth is as secure as the weakest link
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.
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.
> 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.
Irrelevant to the argument I made. My argument already assumes you're using unique passwords, since it's made quite simple these days.
My example appears to have distracted you from the point I was making. Let me make the point again without an example: being vulnerable to one attack does not mean there's no value in not being vulnerable to another attack when the attacks require different strategies and levels of effort. Or again: making breeching security more difficult does in fact reduce your risk of random security breeches. Or to put it another way, a determined attacker will search for an opening, an opportunistic attacker will move on. There's value in protecting yourself from opportunistic attacks.
Changing out passwords for passkeys does not improve security in anything but a theoretical manner.
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.
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.
> but if you're the target audience for passkeys
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...
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...
I have... doubts. Already webauthn isn't prompting for passkeys on Apple. Chrome wants a bluetooth connection out of the box, and firefox does its own internal auth path that doesn't involve the OS.
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).
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).
I don't follow for these
> 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.
> 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.
> other browsers don't use the native icloud passkeys, chrome has its own secret store
> 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.
> 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.
No thanks. I trust google to a degree, but not that far.
I keep hearing a lot of talk about Passkeys, but I haven't yet seen any web site, service, platform, or cloud where I could actually use one.
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?
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?
It seems awfully trivial but in the context of a positive security announcement
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")
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")
Coming soon to a device new you, from the authors of no E2E encryption on Authenticator backups! [1]
[1] https://news.ycombinator.com/item?id=35708869
[1] https://news.ycombinator.com/item?id=35720460
[1] https://news.ycombinator.com/item?id=35708869
[1] https://news.ycombinator.com/item?id=35720460
> Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN.
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.
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.
If you don't use biometrics then it's passwords or passcodes to authenticate to the local device or a secondary device to unlock it. After that it uses public key cryptography to do the actual authentication with the site you're trying to log into. At no point does the site need to have access to anything secret, unlike traditional passwords.
Biometrics are not passwords. They are user IDs. I have concerns with this approach.
EDIT: Looks like support will be coming to NordPass and other password managers soon - https://support.nordpass.com/hc/en-us/articles/1298467820264...
EDIT: Looks like support will be coming to NordPass and other password managers soon - https://support.nordpass.com/hc/en-us/articles/1298467820264...
My understanding of passkeys was that they replace passwords, but a few places where I’ve seen them implemented just use passkeys as a second factor, NOT a replacement for passwords themselves.
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?
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?
I don't mean this to be negative as much as an observation but it seems like it's Google's version of "Sign in with Apple ID"? Apple ID only works with Apple devices though, so I wonder if will work for any device? Perhaps it will work better on Android but can be implemented for other devices?
No. This is the fido2 / webauthn standard, where the device itself generates new keys for each website and the device uses these stored keys to perform public key authentication to log into websites. For some ecosystems (namely iCloud Keychain) it syncs these key pairs between devices.
They already have "sign in with google" which directly links sites to your Google account. This is not that.
They already have "sign in with google" which directly links sites to your Google account. This is not that.
On my website, I'm doing authentication via simple public key authentication using Coze.
No passwords. No email. No Google. Just public key authentication with private keys in possession of the user. https://github.com/Cyphrme/Coze
No passwords. No email. No Google. Just public key authentication with private keys in possession of the user. https://github.com/Cyphrme/Coze
I've always expected end users would struggle to manage private keys. What sort of users does your website have?
Sorry for the delay. I didn't want too many eyeballs on it yet.
https://cyphr.me/wallet?power
https://cyphr.me/wallet?power
See also https://passkeys.directory
Is it just me, or does every "what is a passkey" definition never actually define what passkeys are?
Still flawed seeing as you can't disable Google Prompts (that I know of) which means any security key 2FA or Passkeys that you've set up can be bypassed if your phone is stolen as someone can simply click a prompt in the Gmail app.
I wish they gave the option to disable this.
I wish they gave the option to disable this.
Nope, passwords stay until passkeys aren't tied to a device that can be lost, stolen, or broken. Or you need multiple devices to avoid that. And they are offline and not controlled by multinational corps only interested in monitoring everything you do for profit.
I'm curious how free software users will be able to take advantage of this improved security. Seems tied pretty tightly to proprietary systems and I wonder if, as a free software user, I'll eventually be locked out of the Google ecosystem.
I enabled passkey and literally nothing changed. Signed out and back in again several times.
Yeah, it's not doing anything for me either
Doesn't work here either.
But I'm on Firefox on Linux, both of which are not yet supported as per the docs.
Firefox might get it around version 120: https://connect.mozilla.org/t5/ideas/support-webauthn-passke...
Firefox might get it around version 120: https://connect.mozilla.org/t5/ideas/support-webauthn-passke...
passkeys wont be the end of passwords: https://www.ory.sh/overview-login-password-passkey-webauthn-...
Since you lose the "something you know" factor with passkey-only authentication (e.g., with face scans), would it not be better to allow to add a (much shorter due to the passkey) password as well as an optional extra factor?
I wish world (Apple, Google, Microsoft etc.) had implemented SQRL instead of PassKeys :(
SQRL: https://www.grc.com/sqrl/sqrl.htm
SQRL: https://www.grc.com/sqrl/sqrl.htm
I tried added passkeys to my Google account, then tried to login thru incognito browser. It gave me the option for logging in with a passkey — and then showed me a QR code to scan???? Where did I go so wrong??
i’ve got passkeys enabled on github, cloudflare, google, twitter etc via apple’s passkey implementation (https://support.apple.com/en-gb/guide/iphone/iphf538ea8d0/io...). they all implemented passkeys as an alternative to sms OTP. very easy to use, and should be better than sms, but still haven’t seen full on login using passkeys. if anyone knows of such a site i’m curios how they implemented it.
Did anyone else get an email from Google about this, with a link I’m supposed to click on iOS, but which is broken?
Did Google really email all their iOS+Google users a broken link?
So, if Google suspends my account, I will lose access to everything indefinitely? No, thank you! I am happy with my passwords (Bitwarden + Aegis).
What happens if you lose all your hardware factors (eg if you have a home fire)? Are you just locked out of all your accounts with this approach?
Not if the Passkey was synced (ex: you used iCloud keychain). If the passkey was not synced, then I would have to assume it would be the same if you lost a physical hardware key.
How do you access iCloud without your passkey?
Complain loudly on Twitter and hope your tweet goes viral.
Apple account recovery supports setting a recovery code or having a friend listed as a recovery contact.
Apple does not yet support Passkey for iCloud accounts login.
Apple does not yet support Passkey for iCloud accounts login.
Call Tim, he'll vouch for you.
Google: What are Passkeys?
Also Google: Goes on to not explain what they are at all.
That's about when i stopped taking it seriously.
I believe to this date passkeys are not exportable. As such I am stuck either using Apple or Android. I cannot move between the 2.
Is a passkey a software implementation of a FIDO key? Where the implementation could use something like the TPM to protect the key.
"Passkeys aren’t allowed on this account. Contact your admin for help"
Being admin on google apps doesnt help
Sign in with ethereum is my preference
https://login.xyz/
https://login.xyz/
Passkey is convenient and safer than password, but all of that is based on the trust of 'trusted device'.
How is my 90 year old mother supposed to figure this out? I can get her to use log passwords that she writes down.
Basically, this thing need a complete ecosystem, any broke in link will lead to lose efficacy.
Doesn't support yubikey even though yubikey supports fido2 and passkeys.
Hmm, can I use these passkeys with Brave or other Chromium-based browsers?
That kinda looks like vendor-locked equivalent of pub/privkey auth ?
Does this basically means there is one "master password"?
fuck off and bring back smtp access!
Can we call it something other than passkey? That sounds suspiciously like password, but makes me picture a key fob.
Biometics? Authentication device?
Biometics? Authentication device?
Pretty sure that's intentional. It's replacing something you know (a word) with something you have (a key stored on a device or some kind of account).
It doesn't necessarily need to use biometrics or be bound to a specific device, so those aren't quite accurate. Thus, passkey.
It doesn't necessarily need to use biometrics or be bound to a specific device, so those aren't quite accurate. Thus, passkey.
I have used FaceID & TouchID passkeys for a few months now for MFA. I love it, it’s the most seamless auth for me thru PingID.
the "end of the password" is like the "year of linux on the desktop"
the only thing that i don't like about login with passkeys is that i need to turn on the bluetooth.
They still haven't solved the portability problem, there still is no way to use a Passkey without interacting with a proprietary device or hardware, it's still pretty transparently going to enable vendor lock-in. This technology is harmful.
"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.
"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.
I don't want to give Google my fingerprint or my face. A password in a password manager + 2FA is fine.
You're not. You're storing a private key on a device, and using something like a fingerprint or pin to unlock it and use it to authenticate. The fingerprint data is also only stored on the local device.
Yeah. Except if the usual Qualcom spy chips (also available in Google Pixel) phone home all your biometrics...
So yahoo has had this for a while. yes ... Yahoo. What's wrong with Google these days? They seem to be too focused.
BTW, passkey is the name for a password that is made using word keys.
BTW, passkey is the name for a password that is made using word keys.
I hate this, I hate every part of this.
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.
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.
Nothing about this is tied to phones or external services. You could just use a hardware authenticator (like a YubiKey) as a device-bound passkey if that is what you prefer.
Passwords are terrible for a world where people have hundreds of them and are lazy. And password managers are a bandaid solution.
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.
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.
The first point seems correct, the second seems incorrect. Remembering a single password for access to a secure well-designed password manager seems a bit more secure than a physical passkey, what am I missing?
Because password managers that you (and many others) use all the time are probably a more serious attack vector than your bank deposit box.
Whatever an alternative would be, it should be decentralized.
But you still need a password to use a passkey right? So passwords aren’t going away, they’re just being used to a more secure way.
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.
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.
> remember dozens of passwords and verify that a website is legit
Or use a password manager to solve both of these issues
Except you're not tied to a magic phone
Or use a password manager to solve both of these issues
Except you're not tied to a magic phone
Okay, but the alternative is users managing a separate password for every service, which is impossible to do securely without using a password-manager, and the password-manager is basically a weaker version of an external service like Google's.
Weaker? The UX for signing in on a new device seems better. Maybe that's the same thing as weaker. I'm not seeing any reason in all of this to switch from a password manager though.
[deleted]
Nothing prevents anyone from creating an open-source implementation of the FIDO server/services.
For example: https://github.com/StrongKey/fido2
For example: https://github.com/StrongKey/fido2
bsenftner(2)
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.