13 ms·

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

by jimmar 3y ago

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.

JustSomeNobody 3y ago
Thank you. I've been trying to figure out what they hell they are and have been unsuccessful. I thought it was just me.
- TulliusCicero 3y ago
  This goes into more detail: https://developers.google.com/identity/passkeys 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).
  - deleted 3y ago
    [deleted]
  - laegooose 3y ago
    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?
    - microtonal 3y ago
      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.
    - echeese 3y ago
      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.
      - ChrisMarshallNY 3y ago
        > 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.
        echeese 3y ago
        You could also try your password, I guess.
        ChrisMarshallNY 3y ago
        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.
    - lxgr 3y ago
- stavros 3y ago
  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.
moffkalast 3y ago
From what I can find the word passkey is just a synonym for password. So yes, none of this makes any sense.
- psychphysic 3y ago
  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.
  - guenthert 3y ago
    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.
    - psychphysic 3y ago
      I think it's a great change but I am critical of the way it's being marketed.
laegooose 3y ago
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.
berkle4455 3y ago
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.
- shadowgovt 3y ago
  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).
  - yeeeloit 3y ago
    > 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.
  - xdennis 3y ago
    > Google doesn't have a way to MITM that Google controls the software so it can MITM.
  - dahwolf 3y ago
    "best have another way to auth" right, so passwords it is then.
    - Nathanba 3y ago
      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.
Dalewyn 3y ago
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.
- shadowgovt 3y ago
  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.
  - brokenmachine 3y ago
    That'll be fun when she drops her phone in the toilet.
    - shadowgovt 3y ago
      Then she's back to where she is now.
- mrb 3y ago
  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
  - nine_k 3y ago
    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.
- 3y ago
deleted 3y ago
[deleted]
jjav 3y ago
> 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.
- dwaite 3y ago
  You might like https://passkeys.dev https://passkeys.dev if you want a more implementer-focused overview.
dannyphantom 3y ago
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 https://imgur.com/a/heLrUkb It seems like it just integrates the built-in verification methods depending on what device you are on.
- dwaite 3y ago
  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.
mk89 3y ago
You need to click on the link that is in the post: https://blog.google/technology/safety-security/one-step-closer-to-a-passwordless-future/ 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/ 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/ https://fidoalliance.org/passkeys/ and this explains finally how it works FIDO in general: https://fidoalliance.org/how-fido-works/ 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?
- deleted 3y ago
  [deleted]
- __MatrixMan__ 3y ago
  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.
  - esquivalience 3y ago
    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.
lxgr 3y ago
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?
- JohnFen 3y ago
  Yubikeyrings? I like it.
stanislavb 3y ago
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.
- dwaite 3y ago
  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.
  - deleted 3y ago
    [deleted]
- waboremo 3y ago
  You drastically overestimate technical competence on HN. Especially as of late.
- prmoustache 3y ago
  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.
scott00 3y ago
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)
- stock_toaster 3y ago
  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.html https://developers.yubico.com/Passkeys/How_passkeys_work.htm...
- dwaite 3y ago
  > 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.
dwaite 3y ago
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 https://passkeys.dev .
benknight87 3y ago
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.
notatoad 3y ago
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.
yarg 3y ago
> 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?
iamthemonster 3y ago
How quickly they will be adopted will be almost completely determined by how convenient they are to the user, not how secure they are.
t0suj4 3y ago
From what I've understood it's a TOTP without the air gap of user typing the code manually.
OptionX 3y ago
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.
foobarmoo123 3y ago
> 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'"
- alpos 3y ago
  > 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.

by jimmar 3y ago

JustSomeNobody 3y ago

Thank you. I've been trying to figure out what they hell they are and have been unsuccessful. I thought it was just me.

TulliusCicero 3y ago
This goes into more detail: https://developers.google.com/identity/passkeys 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).
- deleted 3y ago
  [deleted]
- laegooose 3y ago
  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?
  - microtonal 3y ago
    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.
  - echeese 3y ago
    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.
    - ChrisMarshallNY 3y ago
      > 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.
      - echeese 3y ago
        You could also try your password, I guess.
        ChrisMarshallNY 3y ago
        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.
  - lxgr 3y ago
stavros 3y ago
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.

moffkalast 3y ago

From what I can find the word passkey is just a synonym for password. So yes, none of this makes any sense.

psychphysic 3y ago
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.
- guenthert 3y ago
  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.
  - psychphysic 3y ago
    I think it's a great change but I am critical of the way it's being marketed.

laegooose 3y ago

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.

berkle4455 3y ago

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.

shadowgovt 3y ago
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).
- yeeeloit 3y ago
  > 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.
- xdennis 3y ago
  > Google doesn't have a way to MITM that Google controls the software so it can MITM.
- dahwolf 3y ago
  "best have another way to auth" right, so passwords it is then.
  - Nathanba 3y ago
    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.

Dalewyn 3y ago

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.

shadowgovt 3y ago
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.
- brokenmachine 3y ago
  That'll be fun when she drops her phone in the toilet.
  - shadowgovt 3y ago
    Then she's back to where she is now.
mrb 3y ago
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
- nine_k 3y ago
  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.
3y ago

deleted 3y ago

[deleted]

jjav 3y ago

> 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.

dwaite 3y ago
You might like https://passkeys.dev https://passkeys.dev if you want a more implementer-focused overview.

dannyphantom 3y ago

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 https://imgur.com/a/heLrUkb It seems like it just integrates the built-in verification methods depending on what device you are on.

dwaite 3y ago
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.

mk89 3y ago

You need to click on the link that is in the post: https://blog.google/technology/safety-security/one-step-closer-to-a-passwordless-future/ 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/ 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/ https://fidoalliance.org/passkeys/ and this explains finally how it works FIDO in general: https://fidoalliance.org/how-fido-works/ 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?

deleted 3y ago
[deleted]
__MatrixMan__ 3y ago
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.
- esquivalience 3y ago
  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.

lxgr 3y ago

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?

JohnFen 3y ago
Yubikeyrings? I like it.

stanislavb 3y ago

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.

dwaite 3y ago
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.
- deleted 3y ago
  [deleted]
waboremo 3y ago
You drastically overestimate technical competence on HN. Especially as of late.
prmoustache 3y ago
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.

scott00 3y ago

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)

stock_toaster 3y ago
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.html https://developers.yubico.com/Passkeys/How_passkeys_work.htm...
dwaite 3y ago
> 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.

dwaite 3y ago

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 https://passkeys.dev .

benknight87 3y ago

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.

notatoad 3y ago

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.

yarg 3y ago

> 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?

iamthemonster 3y ago

How quickly they will be adopted will be almost completely determined by how convenient they are to the user, not how secure they are.

t0suj4 3y ago

From what I've understood it's a TOTP without the air gap of user typing the code manually.

OptionX 3y ago

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.

foobarmoo123 3y ago

> 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'"

alpos 3y ago
> 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.