[HN Gopher] Passkeys.io - A Passkey Authentication Demo
___________________________________________________________________
Passkeys.io - A Passkey Authentication Demo
Author : night-rider
Score : 92 points
Date : 2022-10-25 15:18 UTC (7 hours ago)
(HTM) web link (www.passkeys.io)
(TXT) w3m dump (www.passkeys.io)
| replaceusb wrote:
| I am confused as to why there is a hard requirement tied to
| apple,google,ms accounts. I get that its so they can sync to
| other devices but what if I do not want them syncing?
| drdaeman wrote:
| When signing up on a Windows machine with Firefox it doesn't let
| me use Yubikey but prompts for a Windows Hello PIN instead.
| Canceling the dialog doesn't go to the next available method
| (like it normally does) but just retries once again, after a
| second cancellation it just gives up. I'd say this makes this
| whole thing completely unusable, because under no circumstances
| would I ever want to use a machine-bound authenticator (unless
| that's the only option I physically have). I really cannot think
| of any reason, it won't give me any extra security and it will
| make things needlessly complicated in event of device loss.
|
| To make it worse, when I'm trying to sign in, it prompts me for
| my Yubikey PIN, and not Windows Hello PIN. Basically, multiple
| token support is badly messed up.
| ArchOversight wrote:
| Using a physical key in Windows now requires you to enter the
| pin to unlock your Yubikey (or set a pin) before you can use it
| to register.
|
| This is an issue we've run into a lot at $work where users will
| forget their FIDO2 pin cause its only used during registration,
| and never after that, and when they reset the pin it destroys
| all their previous known 2FA (which is expected).
|
| This is a new requirement from Microsoft.
| drdaeman wrote:
| I'm aware about this requirement, and it makes sense.
| Obviously, I want the authenticator device protected, so I
| must know the device PIN or password to unlock it.
|
| It's exactly the same for Windows Hello built-in
| authenticator, they require a PIN (or face, or whatever other
| means you have configured) for the computer itself. Same for
| iPhones, you need a PIN or password to unlock it. It's merely
| a matter of frequency (phones and laptops are unlocked daily,
| Yubikeys - depends on the individual), and if use of hardware
| tokens is prohibited (or even discouraged) from the very
| beginning they'll never have a chance and the world would go
| the path of least resistance once again.
|
| I'm curious if resetting a PIN or password on Windows or
| macOS or iPhone OS would retain the Passkey identities. I
| suspect it would...
| dwaite wrote:
| > I'm curious if resetting a PIN or password on Windows or
| macOS or iPhone OS would retain the Passkey identities. I
| suspect it would...
|
| Depends on the process for changing the PIN/password. The
| desktops may have an option to log in with the cloud
| account, which can have separate recovery processes.
|
| If I lose my PIN to my iPhone though, pretty much my only
| option is a device reset. The difference with Passkeys is
| that they are bound to an iCloud account, not the hardware
| - so I get them back on device restore.
|
| Some of the security key enterprise and government
| customers also don't necessarily want credential
| backup/restore. Handling the account recovery and key
| registration process in their environment has more
| quantifiable risk than having it as an external process.
| michaelt wrote:
| _> I 'm aware about this requirement, and it makes sense._
|
| See, pins for yubikeys don't make much sense to me. If you
| have to enter a PIN and press the button on a token, that
| doesn't seem very different to entering a password and
| pressing the button a token which U2F has offered for
| years.
| dwaite wrote:
| There are yubikeys with biometric readers.
|
| The reason they are referred to as PINs rather than
| passwords is that they are locally set and entered,
| without being shared with external network systems. Since
| they are being used to augment the physical security
| properties of the hardware device, the PIN can also be
| far simpler than a typical password - someone has to
| steal your hardware before they can contemplate forcing
| the PIN.
|
| This additional user verification over the physical
| factor is used for two purposes:
|
| 1. The site can request user verification as part of
| accepting this system as a one-stop replacement for their
| current two-factor authentication systems.
|
| 2. Enumerating what credentials are on a key is often
| PIN-protected, so that someone who has temporary access
| to your security key (such as at a border checkpoint)
| can't inspect which sites you have logins against without
| your knowledge/consent.
|
| This second one is the more annoying of the two - I might
| have the system request my PIN just so it can tell
| whether that particular security key is a viable source
| of credentials for a particular site.
| psanford wrote:
| Entering a PIN is known as "user verification." The point
| is to prove not just that you posses the key but also
| that you know a secret about the key. This is better than
| passwords for a number of reasons. The pin doesn't need
| to be secure in the way that passwords need to be secure.
| The pin is only sent between your browser and your FIDO2
| device. If you some how learned my pin you couldn't do
| anything with that unless you also stole my yubikey. And
| you can't brute force the pin. Guess the wrong pin more
| than 10 times on my yubikey and the key will erase
| itself.
|
| Pins make a lot of sense when you start using a yubikey
| as your primary form of authentication (instead of as a
| second factor). Note that there are other ways to perform
| 'user verification' besides a pin. For example,
| biometrics are specified in the FIDO2 spec, and
| implemented by yubikey in their Yubikey Bio product.
| homero wrote:
| I wish chrome showed me what keys are issued. There's no way to
| see a list
| dwaite wrote:
| The platform is often managing things, sometimes with Chrome
| and the platform splitting responsibilities when the Chrome
| team adds support for additional options.
|
| So the ability to see or manage passkeys will unfortunately
| vary by platform, and Chrome's support there will thus also
| vary. We can only hope this gets more consistent over time.
|
| For passkeys in Google Password Manager, I expect they will (at
| least eventually) show up right alongside passwords. This is
| also how it works in the Apple ecosystem.
| homero wrote:
| Chrome on Android should show easily but it doesn't
| sreevisakh wrote:
| I don't think I understand passkeys. The best I could make out is
| that it uses an asymmetric key pair for authentication. How is
| this different from self-signed TLS client certificates (like the
| ones used in Gemini protocol) or CertFP used in IRCv3?
| psanford wrote:
| The difference is that: 1) this is accessible and usable by
| anyone running a modern operating system+browser. mTLS client
| certs need to be provisioned which is one of the major reasons
| why it is only used in enterprise settings. And 2) passkeys and
| WebAuthn are privacy preserving features. You can't track users
| across different websites with FIDO2 devices (mTLS does not
| preserve your privacy at all). This was one of the core
| principals that went into the design of FIDO(2) from the
| beginning.
| sreevisakh wrote:
| Client certs as implemented on Gemini and IRC are self-
| signed. They are enrolled on the service after they're
| created. They don't need enterprise level capabilities. In
| fact, even the creation of these certificates are automated
| on many clients (eg: Lagrange Gemini browser, soju IRC
| bouncer). You don't even think of them as certificates.
| They're considered as identities.
|
| And regarding the privacy. You can deploy as many
| certificates/identities as you want on multiple accounts and
| sites. It's not possible to track them across sites or even
| across accounts, since there is no CA involved.
| WorldMaker wrote:
| Passkeys are indeed similar to that approach. There's no CA
| infrastructure, so they can be considered "self-signed
| certificates" (though they do not present _as_
| certificates, and currently cannot be used for TLS to my
| understanding, though I don 't think there are technical
| reasons you couldn't wrap them in x509 metadata and use
| them as such it's just not a core use case), generated per-
| service, and enrolled as they are created. Passkeys add a
| couple enterprise features back in than just "raw self-
| signed certificates" in the form of optional "attestations"
| designed in a somewhat privacy-preserving way to prove the
| type of device that owns the key and in deeper enterprise
| modes the serial number of the device.
| mpalmer wrote:
| Because here the private key totally inaccessible, stored on
| the user's authenticator device, which is analogous to a
| certificate authority in this case. Part of the WebAuthn spec
| provides for methods for trusting (or distrusting)
| authenticator apps, and presumably browsers themselves will
| assist in blocking untrusted authenticators as they do with
| CAs.
| thealistra wrote:
| Jus a note for the creator. Not all email adresses support the +n
| thing. Just gmail based
| endorphine wrote:
| I don't get why this is downvoted. Even if the second sentence
| is I correct, the first one is correct.
|
| I mistakenly assumed the "+" thing is built into the email
| standard.
| frenkel wrote:
| Fastmail supports it too and you can configure postfix and
| opensmtpd to support it as well.
| jonahhorowitz wrote:
| iCloud Mail supports it too
| leetbulb wrote:
| More than Gmail supports this.
| sreevisakh wrote:
| I can confirm it works on MailInaBox. So it should probably
| work on any installation that uses Postfix and/or Dovecot.
| jbverschoor wrote:
| Most providers support it afaik.
|
| Additionally, gmail normalize all periods (.) to the mail
| address without periods.
|
| So your.name@gmail.com yo.u.r.n.a..m.e@gmail.com both get
| delivered to yourname@gmail.com
| masterof0 wrote:
| Does anyone knows if 'passweys' will be implemented in open
| source password managers like BitWarden or KeyPassX, etc. ? Or do
| we need to rely on Apple/Microsoft/Google for this to work?
| dwaite wrote:
| 1Password and Dashlane have web extensions which replace any
| integrated browser support with their own UX and functionality.
| I do not know the current release state of those extensions.
|
| I personally hope there is more of an 'officially supported'
| integration in the future with the various browsers and
| platforms. "Passkey managers" need to be able to integrate with
| native applications just as well as they do with web apps
| inside browsers. The fall-back of 'I'll just copy and paste the
| password over' won't work if the credential isn't text.
| psanford wrote:
| The specification is fully open and most of the components have
| already been implemented in various open source libraries. The
| nice thing about passkeys is that they are just a FIDO2
| implementation with a few extensions. That means any site that
| supports passkeys will also support other FIDO2
| implementations, including the existing open source FIDO2
| projects.
| [deleted]
| stavros wrote:
| This completely fails on Linux (doesn't even pop up the dialog
| for my FIDO2 key), even though WebAuthn on e.g.
| https://www.pastery.net works fine (and works fine with Passkeys
| on my Android phone).
| dwaite wrote:
| Firefox is unfortunately a behind on support for this
| technology. I believe at least one password manager (Dashlane)
| has shipped a web extension that would polyfill the missing
| bits on Firefox.
|
| Unfortunately, passkeys.io as a demo falls back to a legacy "no
| passkey support" behavior for Firefox, without making it clear
| (as a demo site) that this is happening.
| groovybits wrote:
| Just looking at the table at the bottom of the page, "where can
| passkeys be used", Ubuntu is the only Linux distro listed, and
| it does not support Passkeys.
| stavros wrote:
| Yes, but it supports WebAuthn, which works fine, so I'm
| confused as to why this site is Passkeys-specific and doesn't
| use WebAuthn, which, as far as I can tell, is a superset.
| FlxMgdnz wrote:
| Currently, only platform authenticators are supported to
| create passkeys with. Support for Security Keys is in
| development and will be available soon. Certain
| combinations of Linux distros and browsers will then
| support passkey creation as well.
| jbverschoor wrote:
| A few things I don't understand:
|
| 1) How can I share the fingerprint keys between chrome and
| safari?
|
| 2) How do I share keys between different types of devices? (mac,
| ios, android, windows)
|
| 3) What happens if my devices are gone?
|
| 4) What happens if I want to change my login (email to a new
| email for example)?
|
| 5) Is account recovery handled simply by a reset-email?
|
| 6) It seems a validation step of the email is missing?
| greggman3 wrote:
| Watch the video linked below by psanford
|
| 1) How can I share the fingerprint keys between chrome and
| safari?
|
| You don't need to. That's not how it works. Chrome and Safari
| and every device will have a different key for the same service
| (see video)
|
| 2) How do I share keys between different types of devices?
| (mac, ios, android, windows)
|
| You don't. You authenticate and a new key is created on each
| device, possibly on each piece of software (Firefox, Chrome,
| Safari, App). To be more clear, when and if you decide to use a
| service from a new device or new browser you'll be asked if you
| want to login via passkey. If you have a passkey on another
| device you can (see video) use that to login from the other
| device (similar to how google asks viat the gmail app of you
| were trying to log into some other device or Apple asks across
| your device). After you authenticate you can then create a new
| passkey for this device/software you're using. This new passkey
| is separate from the previous passkey. You effectively have 2
| passkeys now, one to login with one device/software, one to
| with a different device/sofware. (See video)
|
| 3) What happens if my devices are gone?
|
| You follow whatever recovery procedures the service has.
|
| 4) What happens if I want to change my login (email to a new
| email for example)?
|
| Unrelated. Your email is not shared with passkey. So login and
| set a new email
|
| 5) Is account recovery handled simply by a reset-email?
|
| That's up to the site/service just like it is without passkey
|
| 6) It seems a validation step of the email is missing?
|
| That's up to the service as well. They could require an email
| but that's unrelated to passkey
| barkerja wrote:
| 1. I don't believe you can, but I could be wrong.
|
| 2. Apple does this using Keychain (iCloud), but that's limited
| to Safari in iOS/iPadOS/macOS.
|
| 3. I assume would be treated as any other MFA option; if you
| lose your auth code generator with no backups, you're SOL. With
| Apple, you can setup what they call a contact recovery, which
| lets a trusted contact be a point of recovery for your account.
|
| 4. I don't believe this is an issue specific to Passkeys.
|
| 5. Account recovery isn't really necessary, unless you hit up
| against point 3, in which case it's about recovering your
| ability to use the passkey and not so much the account.
|
| 6. If emails are being treated as usernames, they absolutely
| should be validated.
| cameronh90 wrote:
| > Account recovery isn't really necessary,
|
| Unless you want to switch from Safari to Chrome, I guess?
| barkerja wrote:
| I would assume so, but I'm not 100% sure. I personally
| haven't yet messed with Passkeys much aside from use on a
| couple of sites that have implemented them.
|
| My working assumption is if you wanted to use a new
| browser, you'd have to attempt to log into the service with
| the new browser. When the Passkey flow prompts you with a
| QR code to scan, you'd have to use your iPhone/iPad to scan
| that QR code to allow entry. What happens after that, I
| have no clue.
| psanford wrote:
| Part of the design is that every site will support multiple
| passkeys tied to an individual account. So it will be
| normal to use one browser to bootstrap registering another
| browser with a new passkey into your account. This video[1]
| by the FIDO alliance shows what that process will look like
| with a bunch of different OS and browser combos.
|
| [1]: https://www.youtube.com/watch?v=SWocv4BhCNg
| ylk wrote:
| The keys aren't stored in the browser. The browser just
| forwards to the hardware.
|
| Switching from one password/-key manager to another is
| going to be more of an issue.
|
| But you should be able to add an additional passkey once
| logged in to an account, just like how you can have
| multiple hardware 2fa keys now. Then you could manually
| migrate accounts that way, which is painful, of course, but
| you wouldn't be completely locked in.
| jbverschoor wrote:
| I use both chrome and safari, and hate they don't use the
| same password store anymore (chrome used to just use
| keychain). But on iOS, you can at least fill in passwords
| using chrome as well
| 0x457 wrote:
| > 1) How can I share the fingerprint keys between chrome and
| safari?
|
| If you're talking about TouchID then - keys aren't stored in a
| browser, they stored in whatever powers Touch ID (secure
| enclave?). So any browser that supports Webauthn will be able
| to reuse it.
|
| > 2) How do I share keys between different types of devices?
| (mac, ios, android, windows)
|
| Yes. I have multiple hardware keys that I use on: iPadOS,
| Android, Mac, Windows, Linux. Key exposes itself as HID, so it
| "just works"
|
| > 3) What happens if my devices are gone?
|
| Then you have to perform account recovery, just like when you
| forget your password
|
| > 4) What happens if I want to change my login (email to a new
| email for example)?
|
| Email isn't stored on the key. So changing email to a new email
| if entirely dependent on service you're logging in, just like
| in case of a password.
|
| > 5) Is account recovery handled simply by a reset-email?
|
| This is unrelated to passkeys and webauthn. This is a
| replacement for authentication, not account management, so yes,
| it's handled the same in a way that is entirely up to service
| how to handle it.
|
| > 6) It seems a validation step of the email is missing?
|
| I think at this point you can answer this question yourself?
| [deleted]
| fbn79 wrote:
| What if your device cannot connect to internet? OTP can work even
| if device is offline.
| endorphine wrote:
| I guess you're specifically referring to TOTP or SMS-based OTP.
| Email OTP still requires an internet connection, for example.
| Karunamon wrote:
| The passkey lives on the device you are logging into the
| service with, so it implies you have internet access there to
| be able to log into it in the first place.
| dwaite wrote:
| If your device has limited network connectivity, it can create
| new passkeys or use a passkey it already has for interacting
| with a service. However, it won't be able to synchronize new
| credentials with any cloud service in multi-device scenarios.
|
| Or in other words, it works the same as a password manager
| today.
|
| There is a slight wrinkle that some platforms may eventually
| offer to use an internet service during registration for any
| required device attestations (e.g. no, this is really coming
| from mobile phone brand X). Your registration process can't
| require such things if you are dealing with non-internet-
| connected devices.
| thewataccount wrote:
| I'm a bit confused with WebAuthn/Passkeys/Fido
|
| If I have a single hardware key/tpm/yubikey/iphone/etc - can you
| create multiple users on one site? And can they tell that you're
| the same user? Or are you now locked to just a single user for
| your phone/macbook/yubikey/whatnot?
|
| Also if multiple services colluded (or integrated with say GA) -
| can they (or at least GA) all tell that you're using the same
| hardware key across services?
|
| Unless I'm missing something this sounds like very bad news for
| user privacy
| dwaite wrote:
| Yep!
|
| As a user registering an authenticator with a typical site, the
| authenticator creates a public/private key pair and returns the
| public portion. Using it later tells the site it is the same
| authenticator as last time, without options to release much
| more information than the batch of authenticators it was
| manufactured in.
|
| So if you register _again_, perhaps as a different user, all
| the site would see is that they have two users with 'Early
| 2021' Yubikeys. Even this level of identification still
| requires the site to request attestations, which the user has
| the option to reject.
|
| My demo sites may have pages of users from dummy accounts, if I
| don't periodically clean them up. The site has no way (official
| or heuristics-based) to know these are all from the same person
| or same piece of hardware. Different sites also wouldn't see
| that you were the same.
|
| The authentication and registration flows also require some act
| of user consent (such as tapping a key) to release _any_
| information at all - you can't find out ahead of time that the
| user has a credential registered. This also makes sense when
| you think about ones which communicate transiently - my phone
| might not know that I authenticate with NFC until I tap that
| security key against the reader.
|
| What's allowed behind the scenes can muddy this up a bit, so
| I'll list that out too:
|
| 1. Sites can provide a list of registered credentials to try to
| keep you from registering the same authenticator twice under a
| single account. This works as a filter during the consent
| process, but the browser doesn't know if say these were across
| multiple accounts. If a small site provided the entire list it
| would block you from registering the same security key against
| multiple accounts - but the site wouldn't know it was
| successful in doing so.
|
| 2. In addition to the classic second-factor mode (where the
| site provides all the credentials it would honor for
| authentication) there is a _discoverable_ mode, used by
| passkeys, where the site simply says "what you got" to use as a
| first factor. These take up storage. So some keys may have
| limited storage and not want to support multiple passkeys for a
| single website at all.
|
| 3. There is a feature called Enterprise Attestation where your
| system policy (or policy on a pre-provisioned security key) may
| report its serial number to white-listed sites. I consider this
| more a problem with privacy impacts with managed devices in
| general, and many platforms don't support that feature at all.
| I believe pre-provisioned security keys must wipe out any such
| policy on factory reset, but that would likely then limit your
| ability to use that key to access corporate resources.
|
| Authenticators and clients can certainly abuse your trust and
| break your privacy assumptions. The platforms are generally
| acting as clients and limiting access for other software to act
| as clients to prevent correlation attacks and phishing attacks.
| They use API access to limit what a website or native app can
| request.
|
| These clients may also block-list authenticator features or
| whole authenticators which do not meet their published
| requirements.
| dandanua wrote:
| You can use multiple usernames.
|
| As for privacy, services can require additional info from your
| key (WebAuthn shows an additional confirmation button). This
| info includes the manufacturer and probably some other info
| (not sure about that). Otherwise it should be impossible to
| tell if a single key is used for multiple usernames.
| sebk wrote:
| Attestation information requires that at least 100k security
| devices share the same attestation key, so device information
| can't really be used to track a given user. The proposed
| devicePubKey extension that helps RPs reason about which
| device is authenticating with a given Passkey scenario also
| requires domain-specific DPKs, meaning multiple identities
| using the same authenticator are indistinguishable as far as
| WebAuthn is concerned.
|
| Of course, other signals like origin IP or browser
| fingerprinting can be used to correlate identities.
| sumitgt wrote:
| It supports multiple user names. From what I've seen in
| screenshots it shows a picker to select the account you want if
| there are multiple applicable.
| iou wrote:
| Take a listen to
| https://securitycryptographywhatever.buzzsprout.com/1822302/...
| the Q&A helped explain a lot
| Ciantic wrote:
| YubiKey has nice explanation of this [1], it doesn't even store
| the usernames or anything per service. It just has single
| symmetric key, from which it derives the stuff.
|
| It works like this (WebAuthn non-resident keys):
|
| 1. YubiKey contains symmetric key.
|
| 2. When you register to WebAuthn service it generates random
| private key/public key, encrypts the private key with symmetric
| key, and sends this as token to server. Along with your
| username and newly generated public key.
|
| 3. When you login to WebAuthn service and type your username
| you get back the token. YubiKey then decrypts the token to get
| the private key, and answers to the challenge server gives in
| public key.
|
| In other words, you don't need to store the public/private keys
| at all, all you need on the client side (YubiKey) the symmetric
| key. The private keys are stored on server you login.
|
| For WebAuthn resident keys it needs to store info, more here:
|
| https://developers.yubico.com/U2F/Protocol_details/Key_gener...
| Brajeshwar wrote:
| Any idea how are Password Managers, such as
| 1Password/Bitwarden/Keepass, thinking of integrating or competing
| or co-living with Passkeys? I can live with something like
| 1Password but my wife and kids will be more suited and happier
| with Passkeys.
| sebk wrote:
| They could implement a virtual authenticator, emulating a TPM
| or security key and running entirely in software. Of course,
| this nullifies several advantages of FIDO.
|
| Alternatively, and likely a much better option longer term,
| they'll need operating system support that provides them with
| APIs to establish trust between authenticators and export
| passkeys wrapped with keys corresponding to trusted devices,
| not unlike how these OSs provide APIs for integrating password
| managers today. A growing number of password manager vendors
| have joined the FIDO alliance, hopefully to help move this
| along. Establishing trust between devices in a Sync Fabric is
| also something that needs careful consideration if not a
| standard, since it's a huge target for phishing.
|
| In either of these cases Passkeys from different vendors aren't
| interoperable.
| forty wrote:
| We will try to support it (and I'm aware of similar work by
| some of our competitors)
|
| https://www.theverge.com/2022/8/31/23329373/dashlane-passkey...
| Operyl wrote:
| Bitwarden already support regular WebAuthn for 2FA[0] to log
| in. They have an active request for Passkey support[1]. It
| seems like they want to include these inside of their own
| service too, as the storage provider.
|
| [0] https://bitwarden.com/help/setup-two-step-login-fido/
|
| [1] https://community.bitwarden.com/t/unlock-bitwarden-
| with-2fa-...
| stavros wrote:
| They support WebAuthn to log in to Bitwarden, which is very
| different from supporting WebAuthn to authenticate to sites.
| Operyl wrote:
| That's exactly what I said, "to log in". They've also
| stated in many places over time their interest to be the
| holder of keys for these things too, including as a reply
| to the parent of my comment :).
| stavros wrote:
| I know, I'm clarifying that "support WebAuthn to log in"
| means "to Bitwarden". I'm really looking forward to them
| being a soft FIDO2 client.
| frizkie wrote:
| If I understand what I've read correctly, 1Password nightlies
| already have support for webauthn, but it's certainly not
| something they advertise as ready for general usage.
|
| https://blog.1password.com/1password-is-joining-the-fido-all...
| captaincrowbar wrote:
| Tried entering my email. Fail 1 - doesn't allow autofill.
|
| Then tried signing in. "Enter the passcode that was sent to
| <email>." Fail 2 - no passcode was ever sent. (Yes, I tried the
| resend button multiple times, because I'm not a moron. Yes, I
| checked my spam folder, because I'm not a moron. I know the HN
| crowd would have taken great pleasure in explaining the obvious
| to me if I hadn't mentioned it.)
|
| Even if that had worked, how is copying a code from unencrypted
| email supposed to be either easier or more secure than a
| password? Fail 3.
| dwaite wrote:
| The email and passcode is part of the site registration flow
| for this particular site (e.g. registration requires a verified
| email address). Other demo sites like webauthn.io do not
| attempt to add a 'real' registration flow.
|
| My guess is that a demo app was pummeled a bit and fell behind
| on the email verification queue.
|
| That aside, only the part where you register a new credential
| (e.g. the browser/OS modal dialog) in that registration process
| is using passkeys.
| jasonlotito wrote:
| So, not saying what happened to you didn't happen, but as a
| counter point:
|
| 1. It allowed me to auto fill. Both the email and the pass
| code.
|
| 2. The pass code was sent and I received it without issue.
|
| So, not sure what happened to you, but your failures don't seem
| an issue with Passkeys, but rather just software in general.
| FlxMgdnz wrote:
| The demo in it's current state is built with a web component
| using shadow dom. Unfortunately, most browsers do not support
| autofill in shadow dom yet. A newer version using light dom
| will be available soon.
|
| Email codes are just the fallback auth method in case no
| passkeys are supported on the device or the user has lost
| access to the passkeys. In real world scenarios, this may be
| secure enough, or fallback authentication could be disabled
| completely, or secured with Security Keys or other 2FA methods,
| depending on the use case.
| odo1242 wrote:
| I would _really_ like this tech if they supported third party
| services to store passkeys in.
| lsowen wrote:
| Wouldn't that completely eliminate the security benefits of
| passkey?
| FlxMgdnz wrote:
| It really depends on your security requirements and where
| you're coming from or what you're comparing it to. There
| would be still many advantages over, say, passwords stored in
| a pw manager, such as no shared secrets across all
| sites/apps, phishing protection, and far fewer opportunities
| for user errors.
| stavros wrote:
| No, because it already uses a third party service, it just
| doesn't let you pick the one you want to use. I want to have
| the option to use a FIDO2 key, for example.
| dwaite wrote:
| 1Password and Dashlane have announced support via web
| extensions. I also really hope we have future platform-level
| support, so that third party "passkey managers" will work
| outside of the browser (such as on mobile, within all native
| apps).
| fourmajor wrote:
| It asked for my email address, which I provided. Then it said
| there was no account for that email address, and asked if I would
| like to create an account. I said yes. Then it said I was logged
| in. Huh? I didn't have to verify anything.
| barkerja wrote:
| If emails are being treated as usernames, in a real world
| usage, they should be verified. But beyond that, no
| verification is necessary.
| astrosi wrote:
| How would you go about handing a lost device with this? A passkey
| reset email which would have a link that you could use to
| register a new device?
| lwhsiao wrote:
| > passkeys are way more secure and are easier to use than both
| passwords and all current 2-factor authentication methods
|
| Perhaps I'm naive, but how are passkeys "way more secure" than
| "all current 2-factor authentication methods"? Don't many
| security keys (e.g. Yubikey) also require that you are in
| possession of the physical yubikey? I'm using that as a 2-factor
| authentication method. Why is a passkey more secure?
|
| Update: Ah, reading closer it seems that they mean to exclude
| this yubikey example from "all current 2-factor authentication
| methods"?
| homero wrote:
| I think it protects against someone getting the 2fa code.
| Passkey talks to the website directly
| princevegeta89 wrote:
| One question : will the signature generated on a brand new
| device still conform to the requirements, if I end up losing
| all my devices? What if I'm signing in on a random public
| device?
| dwaite wrote:
| Yubikey is included - as a passkey.
|
| They are more secure because they are different per-site and
| are public-key-based rather than secret-based, so they can't be
| captured and replayed later, a website compromise doesn't lead
| to further compromises, and they are phishing-resistant (e.g.
| paypa1.com can't request PayPal.com credentials).
|
| Passkeys are meant to refer to primary-factor authentication,
| as opposed to using something like a yubikey as a replacement
| for SMS OTP or TOTP. The ability to discover available first-
| factor options for a web domain was something new in FIDO 2
| over the older U2F-based keys - I'd expect any security key
| sold in the last three years to have at least limited support
| for discoverable credentials.
|
| By default when someone talks about passkeys they mean multi-
| device, where you back them up (most likely to the cloud) and
| can sync/restore them to other devices. But modern Yubikeys
| (and current Windows Hello) support single-device passkeys.
|
| Or to put it a different way - passkeys are meant to be a
| concept for something equivalent but better than passwords, not
| a proper spec in themselves. Hence the lowercase 'p'.
| FlxMgdnz wrote:
| By the latest definition, Security Keys also store passkeys.
| taf2 wrote:
| I love this in chrome at least I ran into all sorts of issues
| trying to get WebAuthn to work with touchid and my yubikey...
| anyone have plain JS example that works?
| Zamicol wrote:
| I second this. I would love to see a raw demo that doesn't hide
| the internals.
| dwaite wrote:
| webauthn.io has recently been revamped to support more of the
| 'passkeys' behavior, such as conditional UI (the password
| manager/form-fill-like behavior added in certain browsers).
|
| webauthn.me has a developer tab that lets you really get your
| hands dirty.
| smcleod wrote:
| Just tried this on iOS 16.1 and when I go to sign in with the
| passkey it loads a pop up menu with a QR code that I need to scan
| - but it's on my phone so what am I supposed to scan it with?
| bouke wrote:
| Read the "learn more" to learn more. (I had the same question.)
| First create an account and then setup the passkey.
| smcleod wrote:
| Ohhhhhh I see, thank you. Logged a bug on GitHub that
| hopefully makes it clear that the experience is confusing.
| ents wrote:
| The demo is just using OTP sent to my email, which essentially
| makes my email a password manager, and now a much higher value
| target.
| FlxMgdnz wrote:
| Email OTP is just the fallback authentication method of the
| demo in case a user does not have access to the passkey(s)
| anymore. Depending on the real world scenario, fallback
| authentication may either be completely disabled as soon as
| passkeys are widely available, or protected by e.g. a Security
| Key or other 2FA methods.
| freeone3000 wrote:
| There's a different user experience in Safari on Ventura -- it
| prompts for my TouchID.
| georgyo wrote:
| Your email is already both the password and 2fa reset for the
| vast majority of services... including things like bank
| accounts.
|
| Email access is basically total access.
| ents wrote:
| That's a good point. It's annoying to have to check email for
| a code for each login though, compared to 1Password autofill
| w/password and TOTP.
| charles_f wrote:
| Very nice, a good step towards the future.
|
| Just tried on multi-device scenario with android and my mac and
| that worked fine. I'm wondering though, how the biometric data
| gets associated with my email address.
| dwaite wrote:
| The use-case is to create a new key pair when you register an
| "authenticator" device, and then sign a challenge later to
| authenticate (prove it is the existing known authenticator).
|
| It is up to the site to decide if it wants to accept that
| authenticator, e.g. if it meets the necessary security
| requirements. For most sites, they'll accept anything based on
| user preference.
|
| The site only ever knows the 'kind' of authenticator though
| (possibly through a cryptographic attestation). The
| authentication process only releases/uses the public key, not
| any supplemental information. The site would never see any PIN
| or biometric information that was gathered locally to release
| the use of the key.
|
| The site (usually) can't even tell whether it was a PIN or
| biometric used - just that that 'kind' of authenticator has a
| particular behavior and particular security
| reputation/policy/certifications.
| otachack wrote:
| From what I remember, your biometric data shouldn't get
| associated at all. Your hardware uses your biometrics to unlock
| the onboard enclave / vault and then the process asking can
| obtain or create what it needs once unlocked. If you don't have
| biometrics enabled it would resort to your phone password/pin.
|
| Don't take my word for it though!
| charles_f wrote:
| I think you are correct, I took a shortcut there ; my
| question is more "I used email A to sign in, and used my
| android creds (incidentally my fingerprint) - which is using
| my Gmail account B. Now I want to use my apple creds C to
| signin on my Mac.
|
| What links are created between all these accounts? Does
| Google now know that their account B is linked to email A?
| Does Hankio? Or is that the service provider?
| azinman2 wrote:
| I guess I'm not understanding passkeys. On my iPhone it's asking
| generating a QR code to scan with another device. Is this
| assuming another device already has credentials? What if this is
| my only device?
| dwaite wrote:
| You register a device (authenticator), which generates and
| registers a new public key. You show up with that again in the
| future, which answers a challenge by using the private key. So
| it's just saying "I'm the same device as you've seen in the
| past".
|
| The system QR code behavior is for when your registered
| credential lives on another device. It sounds like you might
| have not registered anything yet, so you don't have any account
| or credentials with which to sign in.
| ezfe wrote:
| You can also save it to your phone, you only need to scan
| another QR code if you want to save it on another device
| azinman2 wrote:
| I'm given a prompt to either use another device or an
| external key. Those are the only two choices. Or am I
| supposed to create via email first and that's what I'm
| missing?
| 58028641 wrote:
| You have to create first.
| LeoPanthera wrote:
| In the specific case of Apple, your PassKey is stored in
| iCloud, and so can be retrieved from any Apple device you are
| signed into.
|
| Without this kind of cloud sync, you need at least two devices,
| or you will be locked out if you lose or break one.
| number6 wrote:
| Do you use fingerprints to unlock your device? The page asked
| me to identify via fingerprints
| jonas-w wrote:
| Why does it use Apple specific terms like "Touch ID" or "Face ID"
| or is this now the standard way to talk about fingerprint sensors
| and face recognition?
| bryfb wrote:
| Is passkeys just a webauthn implementation? https://webauthn.io
| is a similar demo I think.
| psanford wrote:
| Passkeys are an implementation of FIDO2 so yes, any sites that
| have implemented webauthn will support passkeys.
|
| It might be useful to think of passkeys as a usability
| extension to webauthn. You no longer need to buy dedicated
| security devices but can use your existing laptop and phone to
| login securely to your accounts. I expect my parents will start
| using passkeys on sites in the next 24 months. I would not have
| tried to get my parents to use Yubikeys.
| Zamicol wrote:
| This demo would be far more useful if it displayed the public key
| that was used.
|
| As a developer, this appears more like a superficial sales pitch
| than a technically informing demo.
| psanford wrote:
| Try https://webauthn.me/debugger. It will show you all the
| gritty details.
___________________________________________________________________
(page generated 2022-10-25 23:02 UTC)