Passkeys.io – A Passkey Authentication Demo

https://www.passkeys.io/

by night-rider • 4 years ago

119 117 4 years ago

stavros5• 4 years ago

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

groovybits• 4 years ago

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.

stavros5• 4 years ago

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.

dwaite13• 4 years ago

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.

fbn79• 4 years ago

What if your device cannot connect to internet? OTP can work even if device is offline.

Karunamon• 4 years ago

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.

endorphine2• 4 years ago

I guess you're specifically referring to TOTP or SMS-based OTP. Email OTP still requires an internet connection, for example.

dwaite13• 4 years ago

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.

lwhsiao• 4 years ago

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

princevegeta89• 4 years ago

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?

FlxMgdnz9• 4 years ago

By the latest definition, Security Keys also store passkeys.

homero3• 4 years ago

I think it protects against someone getting the 2fa code. Passkey talks to the website directly

dwaite13• 4 years ago

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

taf22• 4 years ago

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?

Zamicol2• 4 years ago

I second this. I would love to see a raw demo that doesn't hide the internals.

dwaite13• 4 years ago

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.

ents2• 4 years ago

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.

freeone3000• 4 years ago

There's a different user experience in Safari on Ventura -- it prompts for my TouchID.

georgyo• 4 years ago

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.

ents2• 4 years ago

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.

FlxMgdnz9• 4 years ago

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.

charles_f2• 4 years ago

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.

otachack• 4 years ago

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_f2• 4 years ago

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?

dwaite13• 4 years ago

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.

azinman22• 4 years ago

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?

ezfe• 4 years ago

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

azinman22• 4 years ago

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?

LeoPanthera• 4 years ago

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• 4 years ago

Do you use fingerprints to unlock your device? The page asked me to identify via fingerprints

dwaite13• 4 years ago

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.

drdaeman2• 4 years ago

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• 4 years ago

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.

drdaeman2• 4 years ago

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

thewataccount• 4 years ago

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

sumitgt• 4 years ago

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.

dandanua• 4 years ago

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.

sebk2• 4 years ago

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.

dwaite13• 4 years ago

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.

iou• 4 years ago

Take a listen to https://securitycryptographywhatever.buzzsprout.com/1822302/... the Q&A helped explain a lot

Ciantic• 4 years ago

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

jiveturkey• 4 years ago

What you're asking is if the token can act as a so-called supercookie.

For the first part yes, you can re-register the key multiple times for multiple accounts on the same site, and generally speaking these are not very correlatable on the basis of the token itself, as long as you have gotten a non-dodgy token (ie, one with a unique attestation cert). There may be other ways to strongly correlate the users however, and then the token may give the final (hard) proof the site was looking for. As a trivial example, linked in does a simple correlation on src IP. If you create 2 fake LI accounts and visit from the same IP, after a ramp up time LI will ask each of them if you want to connect to the other. But in this case, LI already had the info necessary to associate the 2 accounts. The token itself isn't the tip of the spear here, that makes this possible.

Cross-site collusion is prevented by restrictions on the RP ID. So as long as the browser is functioning correctly sites cannot collude to use the token as a supercookie.

Unless I'm missing something

Well the thing you're missing is that you're simply supposing these things. But these things are prevented by, and intentional in the design of U2F/WebAuthn.

And if you don't trust the browser, or want to protect against sophisticated correlation attacks, "just" use a different token when you want to go dark. I'm not sure why you have this underlying assumption that a person can only possess one token.

One caveat: I've no idea what you're referring to with "GA".

ornornor• 4 years ago

GA

Probably means google analytics.

Brajeshwar• 4 years ago

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.

Operyl2• 4 years ago

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

stavros5• 4 years ago

They support WebAuthn to log in to Bitwarden, which is very different from supporting WebAuthn to authenticate to sites.

frizkie• 4 years ago

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

forty• 4 years ago

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

sebk2• 4 years ago

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.

thealistra• 4 years ago

Jus a note for the creator. Not all email adresses support the +n thing. Just gmail based

frenkel• 4 years ago

Fastmail supports it too and you can configure postfix and opensmtpd to support it as well.

leetbulb• 4 years ago

More than Gmail supports this.

sreevisakh3• 4 years ago

I can confirm it works on MailInaBox. So it should probably work on any installation that uses Postfix and/or Dovecot.

endorphine2• 4 years ago

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.

jonahhorowitz• 4 years ago

iCloud Mail supports it too

jbverschoor3• 4 years ago

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

odo1242• 4 years ago

I would really like this tech if they supported third party services to store passkeys in.

lsowen• 4 years ago

Wouldn't that completely eliminate the security benefits of passkey?

FlxMgdnz9• 4 years ago

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.

stavros5• 4 years ago

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.

dwaite13• 4 years ago

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

captaincrowbar• 4 years ago

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.

jasonlotito• 4 years ago

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.

FlxMgdnz9• 4 years ago

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.

dwaite13• 4 years ago

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.

masterof0• 4 years ago

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?

dwaite13• 4 years ago

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.

psanford6• 4 years ago

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.

jbverschoor3• 4 years ago

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?

barkerja3• 4 years ago

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• 4 years ago

Account recovery isn't really necessary,

Unless you want to switch from Safari to Chrome, I guess?

0x457• 4 years ago

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?

greggman3• 4 years ago

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

fourmajor• 4 years ago

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.

barkerja3• 4 years ago

If emails are being treated as usernames, in a real world usage, they should be verified. But beyond that, no verification is necessary.

FlxMgdnz9• 4 years ago

For the sake of the demo, email validation has been disabled to make the account creation as simple as possible and to allow fake email addresses to be used.

homero3• 4 years ago

I wish chrome showed me what keys are issued. There's no way to see a list

dwaite13• 4 years ago

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.

homero3• 4 years ago

Chrome on Android should show easily but it doesn't

bryfb• 4 years ago

Is passkeys just a webauthn implementation? https://webauthn.io is a similar demo I think.

psanford6• 4 years ago

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.

sreevisakh3• 4 years ago

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?

psanford6• 4 years ago

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.

sreevisakh3• 4 years ago

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.

mpalmer• 4 years ago

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.

Zamicol2• 4 years ago

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.

psanford6• 4 years ago

Try https://webauthn.me/debugger. It will show you all the gritty details.

FlxMgdnz9• 4 years ago

There are very few opportunities in the wild where you can use passkeys with a real account and not just a tech demo that pops up a WebAuthn modal. We've built passkeys.io to showcase what's possible with passkeys from the perspectives of the end user as well as the service provider. The demo that you can use on the page is very much work in progress, though, and we value any feedback.

jonas-w• 4 years ago

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?

astrosi• 4 years ago

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?

smcleod2• 4 years ago

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• 4 years ago

Read the “learn more” to learn more. (I had the same question.) First create an account and then setup the passkey.

smcleod2• 4 years ago

Ohhhhhh I see, thank you. Logged a bug on GitHub that hopefully makes it clear that the experience is confusing.

replaceusb• 4 years ago

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?

FlxMgdnz9• 4 years ago

At some point, the platforms may open their APIs and allow for 3rd party providers to hook in and do the syncing. It can be expected that most current password managers will do that asap.

egorfine2• 4 years ago

Seems like Safari (both mobile and desktop) is actively hostile to Passkeys.

Safari on a Mac requires me to enable iCloud Keychain in order to use Passkeys and has no way around that requirement.

Mobile Safari presents me a QR code to be scanned by another iOS device o_O

speg• 4 years ago

Yeesh. I thought the whole point was to make this easier? How am I supposed to take a photo of my phone screen?

illiac786• 4 years ago

This is the huge downside of passkeys in my view. You must subscribe to some sync solution, and apple/Google/Msft have a tight grip on it it seems, forcing users to use their own secrets sync solution.

Hope it will change though and I can sync my passkeys using 1password for example. I don't want and password manager and a separate passkey manager on top of that....

egorfine2• 4 years ago

You can't. I tried to screenshot the QR code and it disappeared immediately prior to screenshoting. It's a modal screen similar to Apple Pay one.

0dayz• 4 years ago

Am I wrong here, or isn't this just a glorified password manager on your phone?

tomstuart• 4 years ago

This was, for me, not an effective demo: when I tap “sign in with a passkey” it shows me a QR code to scan with another device. What? (I assume this is because I haven’t created an account yet, but if so, the demo needs to make that about ten times clearer.)

FlxMgdnz9• 4 years ago

Thank you for the feedback. We get this question a lot, and it is obviously not ideal right now. Things will get much better with passkey autofill very soon, though.

Passkeys.io – A Passkey Authentication Demo

Related Stories