I have literally implemented SRP at both the client and server side but I am still unable to figure out, if I were to purchase or set up a "Passkey", what exactly I would have, or how it would work, or which computers, web browsers or web sites I should expect it to work with
I've been reading lots of explanations of passkeys but they all either contradict each other or go unbelievably vague on fundamental points, for example saying that an authenticator "communicates" a key to a website without elaborating on how the communication occurs. I think what happened here was at some point during standardization "Passkey"/FIDO/WebAuthn wound up becoming an umbrella containing several fundamentally different kinds of system
@mcc Yeah, I have swerved passkeys so far because I do not understand the failure modes or how to recover at all. And they're asking 'normal' people to use this!
@mcc when you speak of this, is YubiKey an example of what you're speaking of? because this is exactly how I've felt about those. clutches password manager and typeable but high-entropy passwords closer
@mcc I don't know if this helps, but if you search "the crucial difference is secret versus public key" on the page it has an explanation https://www.grc.com/sn/sn-965.htm
And if the details there are too rudimentary and I am wasting your time, I apologize.
My vague sense: 2FA is difficult to defeat but can be defeated if either I or the server leak my credentials and TOTP key. Passphrases can only be defeated if I lose my secret key, the server never contains enough info for anyone to impersonate me.
@firebreathingduck I believe I understand how the mathematics works but the part I do not understand is the products/implementation. Your link says "The website sends the user a never-before-used large random number to sign". "Sends"? What does "sends" mean in practice? It then references "the user's Passkey agent". What is a passkey agent (or, what I mean is: What kinds of passkey agents will I be allowed to use? Will what is allowed vary between web browsers or operating systems?)
@mcc Ah, okay. So I see the confusion here. They're all using the same basic underlying idea (private key stored on a hardware thing somewhere) - but Apple and Google are attempting to solve the problem of "What happens if I drop my hardware key in the ocean with no backup?" by syncing the private key around to every device via their cloud service.
The underlying mechanism is still a challenge/response between the server and device for all of those.
@cthos I am fine with (and would even say I'd prefer) the key being synced to several devices as long as this doesn't extend to "and every device you access a passkey-enabled web page on has to be a trusted device with a copy of the keys" or "and every device you own must be manufactured by the same company"
Basically 20 years ago for a particular corporate login I had a tiny challenge/response device where instead of a password I'd type a number into the device & it spat out a number to send to the server. This was great. This is what I want instead of passwords, potentially with the challenge/response device being an app on my phone. This is what I thought WebAuthn would be, but I can't figure out if anything like that is still allowed or the spec is now limited to "Google stores your passwords"
@mcc WebAuthn supports hardware keys, but it’s of the “the private key is stored on this token” rather than a human entered challenge response (though the device can issue whatever challenge it wants. Biometric most common)
@cthos If the human cannot enter the data, then how does the "token" communicate with the computer, web browser, or web site?
Because every time I look into this the answer appears to be either "it uses a proprietary apple or google system that's built into your OS" or "bluetooth", which in either case means it's useless to me because I don't use the propreitary OS systems and bluetooth has never functioned properly on any computer I have ever used
@mcc@cthos Honestly it's time for Linux to get with the times and start properly supporting secure enclaves. It's such a huge improvement in security, and Linux to me now feels like one of the least secure OSes for not using them.
@mcc So for something like a USB Yubikey with FIDO support, the browser will hand the challenge over to the hardware device (over USB) for signing with the private key on said token.
I don't know off the top of my head how the usb handshake is implemented (I think webusb?)
That does have the side effect that the key is only on that device and if you lose it, you have to have a backup.
Theoretically a site that allows Webauthn should allow you to register multiple keys for that reason.
@shironeko If I use bitwarden as a passkey agent, and i have bitwarden on my phone, can i use the passkey agent to sign into a passkey-based website on a desktop computer?
@feld@shironeko I don't have bitwarden on my desktop pc because I do not consider it a secure device. Does this mean I can no longer use Bitwarden's passkeys with this machine?
This is why I refuse to use Bitwarden's implementation, personally.
I use a combination of Apple's and Yubikeys solutions. Apple's is per-device not synced with iCloud because it's stored in the secure enclave and nothing can get the seed out.
I recommend the Yubikey approach. Buy two or three. Connect them all to your important accounts. Keep two handy and one in a fireproof lockbox somewhere.
With the USB-C Yubikeys you can plug them into almost any computer and phone. Yes, it works on phones. Just plug into the USB-C port of your phone and it will be recognized by the browser.
They cannot be cloned or copied. This is the way it should be.
@mcc there is a fundamental disagreement within the “passkey” community where both factions believe the term “passkey” means “phishing-proof cryptographic authentication using FIDO2” but one faction believes that it just means “cloud-synchronized version of this to address potential problems with device loss” and the other faction believes it means “any device which can do this including single-device TPM encrypted tokens or hardware keys where device loss means unrecoverable account”
@glyph Yeah. And the problem I have is that what I fundamentally want is "allow me to authenticate with forward secrecy on device A using a private key on device B, where A and B are fully airgapped" and someone on the Webauthn standards body appears to consider my usecase to be "phishing" and is specifically introducing technical constraints to prevent it being possible.
@mcc yes, this precise scenario is what webauthn is designed to prevent, since it’s (by definition) phishable. If you had to manually type in the domain name it might work but that introduces a truly untenable number of unicode problems for non-ascii domain names and so is a non-starter globally
@glyph and so the end result is they've built this baroque system which is accessible in neither my advanced use case nor in basic use cases (because people with basic use cases will not be able to understand the system), and the result is people keep using passwords, which lack the forward secrecy benefits of passkeys and are also still phishable.
@glyph Like it does seem to me some of the people involved in this process have got a fixed idea about the Right Way to do things, and they're trying to force everyone to do it the Right Way, but the only tool they have is to deny people access to the improved security passkeys offer, so in practice anyone who doesn't already align with their Right Way is just gonna get worse security and what have they accomplished :(
@mcc while we are quibbling about certain details, fundamentally I really agree with you. There’s a paternalism about the whole process that I am deeply ambivalent about. Like it’s extremely difficult and annoying to get normies to understand the stakes, and so “just use passkeys it’s easy” can feel like the right message, but there is a significant issue with user education that we can’t just skip over.
@mcc and so we end up in a situation where users need a simple, accessible explanation for how the whole auth flow works, from factor requirements to verification to account reset to what happens when a user dies, but neither the platform vendors nor site operators will explain any of it because it’s boring, and they certainly won’t explain it in standardized and consistent ways. In the absence of that documentation it’s almost impossible to explain the stakes and thus motivate users.
@glyph …on an unrelated note, I'm also really pissy about the assumption that I saw stated in some passkey documents that forcing bluetooth is a positive because will guarantee that the cellular phone is physically close to the pc
@mcc so, you know. Just use passkeys. It’s fine. Click this button. Do you not know where the button is? Look at this screenshot. Nevermind that this is a screenshot of a UI that an actual website has to prompt you to see, and every website has different terminology for this and puts it in a different submenu if they even support it at all. Did you not see the button? Let me refer you to the screenshot again without reference to any particular site and tell you how great passkeys are.
@mcc Worried about getting locked out of all your accounts if you lose your phone, because you only have one device like most people? Don’t worry, it’s associated with your account. You can probably reset your password, right? Somehow? There’s a kbase about it. And you can always export to Chrome. How do you do that? Is there a place for you to practice this before committing to it in a way that might lose you access to all your banks? No, look, here’s the button, look at the screenshot again
@mcc despite all of this I actually do think that webauthn is pretty great technology and users should invest in onboarding onto it, and probably even get some physical tokens for their key accounts given the amount of control that computer communication systems have over our lives and the very real and horrible toll of phishing, but, fucking hell is it frustrating to deal with as a social construct
@glyph I am somewhat suspicious about this because the efforts put in place to prevent airgapped negotiation have the effect of making the easiest and most practical way to use webauthn be using one of the proprietary OS-locked systems, and the vendors of these exact proprietary systems are on the w3 board
@mcc@glyph essentially it's a bit of standards judo where the hardware token people built the public awareness and momentum for change, and now in committee the cloud people and OS vendors are redirecting that momentum to their own benefit
@irenes@mcc fwiw most of these people from both camps are on the fediverse and you can speak to them directly here. These sorts of things don’t really drive lock-in or device sales (consumers absolutely do not give a shit about security like this) so I have a pretty strong presumption of good faith. Although I categorically disagree with many of the deployment decisions :)
@irenes@mcc a lot of effort has been put into import/export, portability and sharing among the various platform auth managers, including third party tools like 1password, so I don’t think they are trying to keep people in the walled garden this way
@glyph@irenes@mcc I don't doubt that effort has been put in, but documentation is pretty sparse and/or misleading. Every time I've created a passkey, I have no idea where it is or how to import/export it --- using Firefox on Android and Ubuntu seems to be far enough off the beaten path that I don't even know how to get started, even having non-trivial education in cryptography.
good faith, yes, everyone believes in what they're doing
the thing is, our Google experience taught us that even people who want what's best for humanity and practice being self-critical can be substantially influenced by the biases that come with being embedded in a corporate structure. management dictates and profit incentives start to feel like laws of nature, rather than things that people invented...
@glyph@mcc we were personally influenced in that way. we wouldn't trust ourselves if we were still in a corporate environment, so we definitely don't trust anyone else :)
@irenes@glyph One problem is if any of them are doing this for their jobs, then the things the humans attached to the jobs say or believe is kind of not important, because in the end the employer can and will override them…
@irenes Anyway, I don't think there's any benefit to me talking to the people you mention unless I can convince them to change their minds. And even that might not help because of the aforementioned employer problem
@mcc no, yeah, we don't think there is either, or else we'd be doing it. besides, the fundamental choices you and we both take issue with aren't the ones made by ICs, they're probably made by SVPs.
@mcc@irenes yes, unlikely that you can change their minds given that even I disagree with you, and I have no particular corporate motivation here :). (There’s a reason I said “they’re here” rather than tagging them, though, no need to drag them in if the discourse would not be productive)
@mcc@glyph in principle that's maybe possible, but every system I'm aware of doesn't let you do it because:
webauthn challenges are up to 64 bytes and nobody's copying the challenge/response manually
you'd have to either use the same keypair across multiple websites, or be vulnerable to phishing
I don't think your use case is phishing, but at a technical level it's indistinguishable (in either case it's, "the web page that I believe is $service told me to type this into my authenticator")
@shadowfacts@glyph I would do it. I would copy-paste a 88-character base58 response between applications (because I don't fully trust, and don't want to bother with, installing a browser extension that connects to my password manager), and although I would not want to type in an 88-character base58 key sequence, I would do so as a fallback in a situation where neither my password manager binary nor bluetooth were available.
@shadowfacts@glyph …but what I do not think I would do is invest time and change my behavior patterns to switch over to a system that will become completely unavailable if at some point I need to use a computer where bluetooth isn't working. Especially because bluetooth is one of the most frequently glitchy, infrequently effective pieces of technology I interact with! If I am going to depend on this I need it to be always available.
@shadowfacts Meanwhile not only is the current system only-sometimes-available, the places where it becomes unavailable are the situations where it is needed most (i.e., when I must connect to something through a not-fully-trusted system). The problem I want passkeys to solve is limiting damage from an intercepted password. The phishing case is not one I am interested in it solving for me.
@mcc well, having an airgapped authenticator fundamentally means copying the data back and forth by hand. if you're willing to have the authenticator application running on your computer and copy/paste things, I think that's entirely doable. but I think the willingness to do so rather than trust a browser extension to communicate directly with the OS/authenticator app puts you in the vanishingly small minority
@shadowfacts It seems unlikely I'm the only person who finds installing browser extensions everywhere inconvenient.
But even if it's the case I'm a small minority, does it make sense to exclude me from using passkeys entirely? There's just so many exclusions and so much friction here at so many edges of the process and it seems like the end result will be people who were potentially reachable continuing to use passwords.
@mcc The vast majority of people don't need/won't use a browser extension, since on Microsoft/Google/Apple platforms, passkey management is built directly into OS and browsers integrate that directly.
It might be the cast that designing the system for the majority has the effect of excluding the minority, but in the eyes of the players pushing passkeys that may well be an acceptable tradeoff. If the vast majority is more secure and you are no less secure, is that so unreasonable?
@shadowfacts I mean if "designing for the majority" means "increasing Microsoft/Google/Apple platform lockin", then yeah, I'd say it is unreasonable!
I'm just really baffled by the presentation of phishing as the primary problem to solve, or even a problem solved by these systems. Even if you use the platform-locked versions, the systems appear to be so complex that anyone who can successfully set them up probably has high phishing resilience to begin with.
@glyph@mcc (as historical context in case it helps with deciphering the politics, Google is on the "include physical tokens" side of that divide; Microsoft and Apple are on the cloud side)
@filippo@irenes@mcc they did hardware tokens first in fact. Although their official developer documentation doesn’t really treat these as “passkeys” and it steers you towards the native cloud-synced version, I believe they do that because it’s inherently impossible to back up a hard token, you just need to buy multiples and keep them in separate secure physical locations and they don’t want to be recommending that to most users or allowing them to set up a fatal SPOF for a critical account
@glyph@filippo@mcc yes. fail-closed is pretty harsh, and there are good reasons most people don't do it. there are also good reasons some of us do do it.
@irenes@filippo@mcc the steering is relatively gentle and if you know what you want, you can click the appropriate radio button in the prompt and get it. This use case is definitely supported.
@glyph@filippo@irenes@mcc I think the hardware is usually referred to as "security key" and "passkey" is pretty universally understood to be a cloud-backed credential.
Also pretty sure Google is very onboard with passkeys as a way of making something that's easier to handle for more inexperienced users to get closer to the level of security that security keys provide without some of the downsides (recovery).
@djc@glyph@irenes@mcc I think that the current consensus is that a passkey is a discoverable credential that you can store on a security key or, more commonly, in a platform and/or cloud backed store.
@filippo@djc@irenes@mcc wait when you say “discoverable” do you mean like in the CTAP2 sense? Like a resident key? This is a whole new, third sense that I had not previously heard! Passkeys terminology is not doing great 🤣
@glyph@djc@irenes@mcc yep, it’s not part of the marketing definition, but it’s been the definition I’ve seen used by the engineers building them for a while now. Passkeys have the ability of autofilling before you type your username in.
@mcc@filippo@djc@irenes whether it's desirable or not, this is a huge surprise to me, I don't think I've ever seen a site do this without me entering a username first
@mcc@filippo@djc@irenes Is there an example site that does this kind of enumeration? I feel like I've gotta be top 0.01% of the population in terms of buy-in on these standards and I have 0 resident keys on my various hard tokens as far as I can tell
@glyph@mcc@filippo@djcsigh we have exactly one (it's for accessing a friend's infrastructure). not really our preferred configuration, U2F was better.
we've been avoiding adding more because we don't want to fill up our smartcards' storage, but the browser tooling is there to do so at this point and the big sites appear to do it by default for new hardware tokens.
@mcc@glyph@djc@irenes well, for the same reason password manager autofill is desirable, and with pretty much the same privacy profile: the site doesn’t get to do the discovery, the browser does and offers autofill. If you think about passkeys as U2F replacements they won’t fit, because they are password (manager) replacements. Security keys were just forward ported to fit the API.
@filippo@glyph@djc@irenes Yeah, I don't… enable password manager autofill. (But I feel like this conversation has convinced me I will no more be required/tricked into enabling "discoverability" than I would be tricked into turning on password manager autofill, so… whatever)
I'm beginning to feel like maybe passkeys/webauthn were trying to do too many things at once, and it is causing problems for me because only one of the three things it does is a problem I actually want to solve :(
@filippo@mcc@glyph@djc the existing implementations quite literally do use passkeys rather than U2F when both are available. SOMEbody thinks they are replacements.
@irenes@mcc@glyph@djc right, I guess I should say passkeys are primarily meant to replace passwords, and they happen to also be replacing U2F because the APIs and UI flows are unifying, but they don't start out as a U2F replacement, so it makes sense they wouldn't feel as the right way to replace U2F in isolation.
@filippo@djc@irenes@mcc fwiw engineers building anything even vaguely related to u2f/fido/fido2/webauthn/passkeys (myself included, honestly) are the furthest down this rabbit hole out of any population I've ever interacted with: https://xkcd.com/2501/
@filippo@djc@irenes@mcc I did a poll on twitter in 2022 when google was starting to work on / talk about their implementation; consensus among implementors was "I guess some users might think 'passkey' still means the hardware device, but most people should understand it's the cloud version", but among even my followers almost half thought "passkey" was Apple-specific branding https://twitter.com/glyph/status/1563310487642615809
Add comment