[HN Gopher] A Tour of WebAuthn
___________________________________________________________________
A Tour of WebAuthn
Author : caust1c
Score : 279 points
Date : 2024-12-26 18:27 UTC (1 days ago)
(HTM) web link (www.imperialviolet.org)
(TXT) w3m dump (www.imperialviolet.org)
| xenophonf wrote:
| I've always wanted to write a serverless OIDC provider/SAML IdP
| but got stymied by the WebAuthn standards, which don't seem to be
| written for normal people. :( But this e-book looks like it might
| have enough actual code interleaved with exposition to serve as
| more than just a high-level intro.
| caust1c wrote:
| Adam Langley is probably one of the most gifted teachers when
| it comes to explaining cryptography concepts. Very clear,
| concise, precise, and makes it simple enough for me to follow
| without getting my neurons all knotted up.
| jf wrote:
| Agreed, I implemented TLS key pinning for a project at Okta
| using one of Adam's blog posts
| cyberax wrote:
| OIDC providers are surprisingly NOT complicated! I created one
| to implement single sign-on with AWS, and it ended up being
| only around 200 lines of code in Go. All you need to do is
| create a JSON blob that is signed by a public key that is known
| to the consumer of the IDP.
|
| I'll need to do a write-up for it.
| nmadden wrote:
| Yes, the WebAuthn spec is pretty unreadable. Every time I open
| it I feel like I'm lost in a maze of twisty hyperlinks, all
| alike.
| treve wrote:
| Looks like an amazing resource for webauthn. Currently diving
| into this so it comes at a nice time for me.
|
| But it's also great advertising against WebAuthn. Hard to believe
| that this kind of complexity is needed, but as with OpenID
| Connect it feels like enterprise interests are running the ship,
| not end-users. Ease of implementation seems like a non-goal.
| ggm wrote:
| It interested me how quickly all of my auth methods started to
| include "pick the right one of three presented numbers" tests
| after TOTP got widespread. I'm guessing there is some replay
| method which they wanted to prevent? This is distinct from in
| protocol large random value challenges, it must be to ensure a
| Hooman, or very numerate dog is actually present.
| g_p wrote:
| TOTP codes are phishable and repayable in real-time - both via
| web (visiting the wrong site which asks for a TOTP and relays
| it within a few seconds), and via social engineering over the
| phone (give us one of the codes to prove it's you and we can
| keep your account safe).
|
| Adding number matching or similar helps ensure that the same
| user is initiating the session as is approving it - an issue
| when people discovered that Microsoft (among others) would do
| push messages to authenticate a login, and that users (if
| spammed late at night with constant requests), would often
| eventually hit allow to stop the notifications.
| hirsin wrote:
| Pick the right number is not secure (enough), unfortunately -
| MFA exhaustion leads to users hitting one of three at random in
| an attempt to "make the notifications stop" (that are,
| naturally, being spammed by the attacker with a password but no
| mfa).
|
| The attacker just has to spam them a few dozen times to get the
| victim to pick the right one at random and let the attacker in.
|
| This is why it's switched on good platforms to "type in the
| number you see", which mitigated this.
| lxgr wrote:
| That's slightly better against people essentially
| accidentally letting attackers in, but still completely
| phishable by e.g. tech support scammers.
|
| The big advantage of WebAuthN is that (at least for sane
| implementations, including all I've seen) there just is no
| way to enter an attacker-provided number and/or supply a
| displayed code to an attacker.
| lapcat wrote:
| > A passkey is a synced, discoverable WebAuthn credential.
|
| This is my fundamental problem with passkeys: I don't want to use
| any syncing service.
|
| To be clear, I don't want to deprive other people of the ability
| to sync their credentials; I simply want to opt out myself. I
| just want to be able to manually back up and restore my
| credentials, like I've always done with passwords, but the
| passkey vendors seem to want to refuse to give anyone this
| ability. The vendors claim that this is to make phishing
| impossible, but I abhor paternalism in all forms, and also it's
| suspicious that this paternalism forces people to use the syncing
| systems of the passkey vendors, which are usually paid
| subscriptions. So passkeys become an endless supply of money for
| the vendors.
|
| It's very telling that passkeys were designed _and_ shipped
| without any export /import mechanism. You can plainly see the
| priority of the passkey vendors, which is to lock you in.
| Allegedly, export/import is coming _sometime_ in the future, but
| I strongly suspect that they 'll end up with some kind of
| "approved provider" system so that the big passkey vendors can
| retain absolute control and avoid giving power to the users.
| ylk wrote:
| Just use a password manager that doesn't sync by itself then
|
| https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
| g_p wrote:
| The downside of this (at least in my personal view) is it's a
| regression from the elevated security you got with non-
| resident FIDO/U2F MFA.
|
| The moment you go "passkey" and have to use a system like the
| one you suggest, you need to trust software based storage of
| long term credentials.
|
| That isn't the case with a hardware FIDO2/U2F token, which
| has unlimited capacity for non-resident MFA keys the server
| holds for you to decrypt and use locally to sign login
| attempts.
|
| I liked that FIDO seemed to get towards hardware backed
| security modules for login, without cognitive load of
| worrying about number of sites and yubikey slot capacity.
| Resident Webauthn keys limit the number of sites you can
| have, and push you towards software based solutions (so you
| lose out on doing the crypto on the single purpose, limited
| platform that's dedicated to generating those signatures).
| ylk wrote:
| I agree that it's annoying that there's now a limit on the
| amount of credentials you can store on hardware keys. But
| while older Yubikeys only support 25 resident keys, models
| with firmware 5.7 onwards support 100. That probably makes
| it feasible to exclusively store passkeys in hardware.
| https://www.yubico.com/blog/empowering-enterprise-
| security-a...
|
| However, I don't know whether it's possible to delete only
| a single resident key you no longer need.
| g_p wrote:
| Yeah, a fair point (though if you can't manage keys one
| by one that seems a massive usability issue and oversight
| with no safe path to resolution).
|
| This adds another step needing considered for a user, as
| finite storage means a whole edge case to consider (can't
| register as slots full), and no simple actionable step to
| take ("which account would you like to never be able to
| log into again?" or "sorry you need to wipe this key and
| lose everything, or buy another one")
|
| I feel there is a usability aspect of FIDO2 (for non-
| resident MFA) that is being overlooked - the paradigm was
| simple - a physical key you don't lose, and you can have
| multiple keys. The gotcha was no way to replicate backup
| keys, which becomes fairly difficult for users. But hey -
| passkeys launched with no export or migration process
| between closed device ecosystems!
|
| From my perspective though, I won't use passkeys until I
| get sufficient control over them to be allowed to decide
| if I want to make them "resident" or not. (I don't want
| resident keys!!)
|
| I want to use non-resident keys everywhere as a hardware-
| backed second factor that is phishing resistant, without
| capacity limitations (so zero cognitive burden on whether
| to use or not).
|
| It feels like a regression for passkeys to be forgetting
| about what (for me at least) was the core basic use-case
| of FIDO2 - as a highly secure second factor for someone
| who already can manage storage of secrets in software,
| and just wants high assurance phishing resistant MFA
| during their conventional login process.
| formerly_proven wrote:
| > Yeah, a fair point (though if you can't manage keys one
| by one that seems a massive usability issue and oversight
| with no safe path to resolution).
|
| You can, it's part of CTAP2 and various apps like Yubico
| Authenticator are available to do it.
|
| It's not user-friendly, but it is possible.
| lapcat wrote:
| There's no browser extension available for Safari: https://ke
| epassxc.org/docs/KeePassXC_GettingStarted#_setup_b...
| lxgr wrote:
| For macOS/iOS, you could give Strongbox a try:
| https://strongboxsafe.com/
|
| I haven't really looked into it myself, but it seems to be
| using the same database format as KeePass, and it hooks
| into macOS's "FIDO provider" API, which makes it accessible
| to not only Safari but all browsers that use it (which
| includes Firefox and Chrome on macOS, and probably
| everything on iOS), without requiring any browser-side
| extension.
| amlozano wrote:
| This is the exact reason I self host vault warden. I get all
| the convenience of syncing passkeys, but know that I am the
| only one with access to the back-end.
|
| I am also slightly paranoid as a security engineer, and admit
| that whole heartedly.
| g_p wrote:
| I share your paranoia and felt that passkeys were a step back
| as anything getting access to your browser extension memory
| can realistically dump both your "password" and MFA
| ("passkey") in one move.
|
| I wonder if there would be a way for vaultwarden to wrap
| passkeys such that a hardware FIDO2 key is needed to decrypt
| them "per-use", and prevent software on the host from
| stealing a pile of passkeys that give direct access to
| accounts without further MFA.
|
| Right now it feels like passkeys in the password manager is
| akin to storing MFA seeds and recovery keys in the same
| password manager...
| briHass wrote:
| I'm also waiting for a password manager that tightly
| integrates with a hardware device to protect passwords
| individually and in-memory.
|
| I wrote a quick PoC using certificates to encrypt a
| password, with the cert private key 'stored' in the TPM,
| with a PIN. This is pretty easy on Windows, which exposes
| the TPM as a special crypto provider.
| g_p wrote:
| That's a pretty neat solution. I like that idea.
|
| If you wanted to go a step further, you could use a
| smartcard with hardware PIN reader as a PKCS11 crypto
| device, and use that to decrypt the long lived keys in
| the store, then pass it back to the host encrypted by a
| platform-protected key to be decrypted and used.
|
| If you could get the right implementation specifics
| together, you could likely then have the smart card
| simultaneously re-encrypt the credential with a key bound
| to PCR state of the TPM via a policy. You'd then decrypt
| that ciphertext on TPM without a PIN, but conditional on
| PCR state of a couple of PCRs that represent your system
| like the secure boot toggle state and allowed CAs.
|
| That lets you be a bit more "cross device" than a fully
| TPM solution does, though your certificate technique
| works fine as long as you keep an offline backup for
| enrollment if anything changes on your system.
| amlozano wrote:
| For anything that is important enough, I put passkeys on 2
| separate FIDO2 key devices directly. Services that come to
| mind are things with recovery backdoors; like email or
| device backups. Unfortunately many banks and financial
| institutions don't support passkeys, but I'd consider using
| that solution there too.
| MaKey wrote:
| Storing the passkeys on a device protected by a PIN is an
| option too. Example: T2F2-PIN+ Release3 by Token2 can store
| 300 passkeys.
| g_p wrote:
| That's a fair point, although as the PIN is validated
| locally, you could argue from the server perspective you
| gain a second (knowledge) factor, but from a local
| perspective it's entirely correlated with the existing
| stored factor (a weakness in the local device
| implementation can skip that PIN check and yield the
| result).
|
| Perhaps this is excessive, but it's a model where I like
| to see layers of security that depend on different,
| uncorrelated failures being required to bypass them.
|
| Today if you want to get into an account using "FIDO2 as
| MFA" you need both the account credentials or ability to
| reach the Fido prompt (say password reset), and the
| hardware token device (with optional pin). The device
| alone being compromised shouldn't get you into the
| account.
| lxgr wrote:
| > The vendors claim that this is to make phishing impossible
|
| They do? I don't see how, since non-discoverable WebAuthN
| credentials make phishing just as impossible.
|
| The only thing discoverable credentials allow on top of non-
| discoverable ones is avoiding having the user type in their
| username or email address.
| drhuseynov wrote:
| yes, that is for "usernameless" login, in addition to
| passwordless. Does not increase security, improves usability
| a bit
| Elucalidavah wrote:
| Not to mention that a better security would involve a master
| key, and revocable subkeys signed with it, one for each device,
| instead of syncing. Not to mention n-of-m requirements.
|
| And sure, I understand that most people _need_ the
| paternalistic form, whey they are not given any guns and are
| also unable to export their keys from some service.
|
| For example, with TOTP, the key is given to the user in the QR
| code, but common authenticator apps are unable to export the
| same data after it was imported. But not all; and the only bad
| thing about this is that the export restriction is a surprise
| to those who didn't expect it.
| somat wrote:
| I was messing with implementing webauthn the other day, mainly
| because I like public key authentication. I was hoping for
| something sort of like ssh keys. and they were close, so close,
| to having something good that could replace password auth. and
| then they break it by requiring a hardware token, Yes, a
| hardware token is better, but I am not going to require users
| get a hardware token. there are working software token systems
| built into the browser but they are gated behind dev tools,
| again something I am not going to ask of users. and just to
| spit in whatever goodwill they have left, to make it really
| unusable, there is this weird mandated "no user interface"
| policy in the standard. making near impossible to manage keys.
| The keys are critical in a public key auth system. but "no, we
| are disallowed, by the standard, to give you an easy mechanism
| to back up and restore keys"
|
| If I were more conspiracy minded, I would suspect some sort of
| agent provocateur ruining our standards. However, I am unable
| to come up with a profit motive, so my only conclusion is
| incompetence.
| formerly_proven wrote:
| You used to be able to generate X.509 client authentication
| certificates (well technically CSR) right in the browser with
| the since removed <keygen> tag. Ergonomics weren't that bad,
| until a user forgot they had a certificate on their broken
| PC.
| lxgr wrote:
| As somebody that used to use them for a while: The
| ergonomics of TLS client authentication in the browser were
| abysmal. And that's to say nothing about the privacy
| consequences.
| formerly_proven wrote:
| iirc managing them was buried super-deep in the browser
| settings (just like managing resident keys, browsers
| don't even do that), but enrollment was fairly simple
| from a user PoV - submit a form and the server sent back
| the certificate, iirc you had to confirm a scarily worded
| dialog (or maybe import it manually? Not sure). Login was
| smooth if I remember it - just a pop-up if you want to
| use the installed certificate. Privacy should be fine
| with TLS 1.3 but would've been nonexistent with the
| contemporary SSL/TLS versions of course.
| lxgr wrote:
| > Login was smooth if I remember it
|
| That's unfortunately not how it works. TLS sits at the
| transport layer, so it's not possible for a website to
| use these certificates for a "login-like flow". The site
| doesn't get to present to the user _why_ and _to whom_
| they are authenticating, since transport layer
| authentication has to happen before HTTP even gets a
| single request in.
|
| There is also no "logout" button. It shares these UX
| problem with HTTP "basic authentication" (even though
| that's technically an application layer protocol).
|
| On top of that, TLS is these days often terminated by a
| load balance or even a completely separate entity like
| Cloudflare. Not sure if you can configure these to
| request client certificates at all; even if you can, it
| makes things pretty awkward if you want to have closer
| control of the authentication flow.
|
| > Privacy should be fine with TLS 1.3
|
| It's not fine at all. _Any_ HTTP server can request your
| client certificate, and most users would probably not
| think twice before clicking "authenticate", which then
| reveals their long-time stable certificate and public key
| to a potentially malicious server.
|
| Compare that with WebAuthN, which makes it intentionally
| impossible to accidentally present the certificate for
| a.com at b.com.
| lxgr wrote:
| > I was hoping for something sort of like ssh keys
|
| SSH keys (and any other keypair shared across services) are a
| non-starter on the web for privacy reasons. (See also: `ssh
| whoami.filippo.io`.)
| somat wrote:
| The implementation ends up being a new key gets generated
| per domain, which is actually what you should be doing with
| your ssh-keys as well something like "ssh -i
| server.domain.net server.domain.net"
|
| Because webauthn is such a nonstarter I am actually going
| to try and half-ass it using SubtleCrypto.sign() and
| friends. sort of mimic the webauthn api. This is really
| just a weekend project, nothing important. but I feel
| really stupid every time I work on it, mainly because of
| how ridiculous it is to have your key infrastructure
| managed by the service you are logging into.
|
| However due to domain sandboxing I have half convinced
| myself it is as secure as using a cookie to auth the
| person, perhaps even a little better because I never have
| to see a secret. then fall into despair again on how stupid
| this whole endeavor is, because I could see the keys
| anytime I want to. (sighs, shakes fist at the sky) why
| could you have not made webauthn usable?
| lxgr wrote:
| What specific gripes do you have with WebAuthN that makes
| you want to reimplement it?
|
| All the problems I have with it as a user originate from
| either reyling parties doing dumb/user-hostile things
| (enforcing resident keys even though I'm perfectly
| capable of remembering my email address or my username,
| improperly layering WebAuthN with existing second factors
| etc).
|
| These are possible because WebAuthN is trying to provide
| for many use cases at once, but I've never felt like it
| was missing something, and user-friendly behavior is
| definitely possible. I've seen many examples at this
| point.
| no_wizard wrote:
| At some point, you have to trust something. Thats how I feel
| about WebAuthN and syncing services.
|
| Ideally, some of this could actually be solved by having a
| government organization that provides this and is regularly
| updated / audited etc. but in the US at least, we are not in
| any place for that to happen, so you need to pick a provider.
|
| Apple is reasonably good at this, if you're in their ecosystem.
| Can't speak for Google. 1Password has been very good to me as
| well, and there are Yubikeys too.
|
| Nothing is perfect, but this is a far, far far better state
| than were it was heading before WebAuthN
| lapcat wrote:
| > At some point, you have to trust something.
|
| If by "something" you mean an internet syncing service, then
| no, I don't.
|
| I do trust my own backup methodology.
| no_wizard wrote:
| Some service. I'm not saying you have to trust what I
| trust.
|
| Personally I'm a big 1Password fan and have been in the
| Apple ecosystem for a very long time as well.
|
| Most security folks I trust also vouch for them, as far as
| practices and effectiveness goes of their software.
|
| But you'll need to trust something somewhere, and you might
| even need to expose it to a network in some cases.
|
| The one thing I really like about Yubikey is it doesn't
| require a network connection at all to work, but it never
| caught on generally for that model to be widespread
| supported so I have found while I do use my Yubikey a fair
| amount there are still things that don't accept it that I
| wish did
| lapcat wrote:
| > But you'll need to trust something somewhere, and you
| might even need to expose it to a network in some cases.
|
| Again, no, I don't, and you still haven't explained why.
| Unless you mean that the big tech companies will _force_
| me to use a sync service whether I want it or not.
|
| Moreover, you've ignored my point about paid
| subscriptions.
| arianvanp wrote:
| There are some hairy edge cases during registration that many get
| wrong. (At least GitHub and google had this bug) that if create()
| returns but the passkey never reaches the server due to bad
| networking conditions that your password manager thinks it can
| log in but the server never recorded the passkey for the user.
| Basically there is no transactionality and you can get in a split
| brain situation where your password manager and your server don't
| agree and it's very confusing for end users.
|
| https://github.com/w3c/webauthn/issues/2038
|
| They apparently came up with a fix for this using something
| called Signals API but I don't think any browser implemented that
| yet.
|
| Just wanted to highlight that this part of the UX is hairy and
| hard to get right
| arnarbi wrote:
| Chrome on desktop did:
| https://developer.chrome.com/docs/identity/webauthn-signal-a...
| jesseendahl wrote:
| Nice seeing you here! :)
| 1oooqooq wrote:
| now just 27 absurdly insane implementation hacks to solve.
|
| webauthn is the only spec born like a 60 yr old legacy
| technology with global adoption. everything about it is
| insane.
|
| they didn't even think about having more than one key plugged
| in (mostly because the use case was just so that the device
| own your identity so they never thought the use would have
| control over the hardware), and the solution is to just blink
| all the keys and use the first one the use touches while
| hoping the other keys with timeout before the use actually
| have to use them. so much insanity.
| arnarbi wrote:
| "They" in this case included me and this was a deliberate
| fix for poor UX many years ago. We definitely thought about
| it and we used to blink only the key that had a credential
| from the allow list, because like you we thought that made
| the most sense. But people got routinely stuck because they
| just tapped a different key out of habit and nothing
| happened. There was no way for the browser to tell them
| "not that key". Best case the reports would say the key was
| dead because it didn't blink.
|
| We changed it to blink all keys, so that if you tap the
| wrong one, the browser can at least tell you something
| sensible and get you unstuck. This wasn't a hypothetical
| shot in the dark, but something we tested and actually
| worked well for real users.
|
| I don't disagree that WebAuthn has grown well beyond
| anything we could call good spec design. But it's worth
| remembering that there's /a lot/ of context behind it, and
| that the average user doesn't behave anything like an
| average HN reader.
|
| > hoping the other keys with timeout before the use
| actually have to use them
|
| Both Chrome and Android will cancel requests to all other
| keys. If your keys are locking up until a timeout it's more
| likely the key itself is buggy.
| compootr wrote:
| chrome is a child's toy with MV3. lmk when it's in a real
| browser!
| surajrmal wrote:
| What extensions do you use which are not supported under
| mv3? I'm sure there are some chromium forks like brave
| which will also get this support for free.
| tgsovlerkhgsel wrote:
| This is an excellent write-up that finally motivated me to try to
| understand the mess that was left behind as new standards kept
| being layered on top of each other.
|
| Given the requirement for discoverable credentials and sync,
| truly open/independent passkey implementations seem
| impossible/impractical. For example, you couldn't just have a set
| of Trezor-style devices that you load with the same seed and use
| that as your passkey without syncing the "discoverable" part of
| the credentials through some kind of cloud service. (The cloud
| service wouldn't need to be trusted with the actual keys, but you
| couldn't operate without it.)
|
| As a result, it looks like you can essentially choose which
| ecosystem you want to lock yourself into...
|
| With authenticatorAttachment, sites have been given a convenient
| foot-gun to make sure no single setup actually works for all
| sites, and with both the discoverable and non-discoverable
| credentials supported, inconsistency in the login flow for
| maximum confusion is guaranteed.
|
| Add to it that this is like the 4th or 5th iteration of a
| standard in the field in about 10 years, and there's endless
| opportunity to get locked out because providers migrated from one
| standard (or buggy implementation) to another, or start setting
| things up only for the 6th standard to obsolete what you had
| (again, potentially locking you out).
|
| And then people are surprised that users stick with passwords.
| lxgr wrote:
| There is no technical requirement for discoverable credentials
| in most scenarios.
|
| Sure, not having to type your username is nice, but I'll gladly
| still do that if it allows "passphrase-based paper-restore-able
| authenticators" such as the one you describe. (I have one of
| these, in fact!)
|
| Many services I use that do support WebAuthN allow either
| variant to be used (i.e. they'll prefer discoverable
| credentials but will work just fine with non-discoverable
| ones), and arguably that should be how almost everybody ought
| to implement it.
|
| Unfortunately, at least as many other services completely botch
| it, e.g. by making discoverable credentials mandatory, by
| allowlisting browsers (e.g. Paypal), allowlisting
| authenticators (e.g. my government's e-signature platform), or
| by using them in a functionally braindead way (e.g. Amazon, who
| for completely unfathomable reasons _still requires TOTP behind
| WebAuthn_ , i.e. they replace the password with it, not the
| second factor).
|
| So far I haven't noticed a strong trend towards enforcing
| discoverable credentials, but let's please name and shame
| everybody doing that. It's completely unnecessary.
| userbinator wrote:
| _And then people are surprised that users stick with
| passwords._
|
| IMHO that and a TOTP seems to be a sweet spot.
| porridgeraisin wrote:
| Yep.
|
| 2 factor authentication using 2 simple mechanisms is great.
|
| Password for most cases. And then in high value things, ask
| me for 2FA. For things like banks and anything money related,
| SMS 2FA already exists and is good enough. For normal
| websites, uncommon yet important actions, such as logging in
| (everyone can use long lived sessions these days), repo
| deletion on GitHub, etc, ask for me for 2FA.
|
| TOTP is also a really nice mechanism, especially in
| authenticator apps today that can backup your keys to cloud
| storage.
|
| I know "SMS" and "backup keys to cloud storage" gets the
| security folks off their chairs, but outside a theoretical
| setting they're both a perfectly good tradeoff.
| adam-p wrote:
| Except that TOTP codes are MitM phishable. U2F with its URL-
| checking (via browser cooperation) is needed.
| lxgr wrote:
| To me, they're an annoying half-measure: Not phishing/MITM
| resistant, yet annoying to use in practice.
|
| I'll still take them over SMS-OTP any day, but admittedly
| even that at least offers some technical benefits over TOTP,
| e.g. in that the relying party can tell me _what_ I am
| consenting to in the message ( "by entering this code, you
| approve a payment of $1000 to evilshop.com").
| raxxor wrote:
| Even the closed-system solution pose problems. I think it
| didn't get much airtime, but when Chrome switched their
| approach to save passwords, a lot of users lost access to their
| accounts. A case where a feature wasn't sensibly discontinued.
|
| The workaround now isn't using passkeys, something few people
| understand. Instead most seem to be migrating to an external
| password managers. Honestly, I don't have many arguments
| against this as these at least generate save passwords. There
| are many advantages to this approach.
|
| I believe moving forward, sticking to passwords might indeed be
| more viable. I think explaining users to upload their public
| ssl key is safer and more universal at this point.
| portaouflop wrote:
| I use password as main auth method for everything (via a pw
| manager) - but then I often add passkey or similar for
| convenience. If I get locked out I still have the trad method
| as fallback; for me that's the best of both worlds.
|
| If you don't offer password as method I will not use your
| service. The worst are those that only offer code via
| email/sms or social login - miss me with that ...
| lxgr wrote:
| Passkeys are too complicated, so let's have users _manage
| public keys manually_ instead? You can 't be serious.
| 1oooqooq wrote:
| except passkeys bought you a false sense of security and
| easy. yeah the happy path is easier because you're just
| generating new keys... but if the user ever gets a new
| phone or sit in front of another device, now passkeys are
| more complicated than the alternative.
|
| sadly the world became too dumbly complacent to question
| their devices.
| lxgr wrote:
| Logging in to Bitwarden/1Password/KeePassXC/Strongbox/...
| takes less than five minutes, even when using
| sophisticated 2FA.
|
| Would you argue that loading a public key (load it where,
| actually?) is much faster? How'd you do it practically?
| zcdziura wrote:
| Can anyone recommend a good dummy passkey provider to use when
| developing and testing RESTful authentication services that will
| rely on WebAuthn? Every example that I've seen online for
| interacting with a WebAuthn service assumes that you're working
| within the context of the browser and can use the Navigator APIs.
|
| I like to use regular ol' cURL when testing out API endpoints,
| and it would be great if there were some kind of dummy CLI
| program that I could use to generate the WebAuthn key agreements
| and materials.
| lxgr wrote:
| What exactly are you trying to test? Is there even a non-
| browser standard/protocol for using WebAuthN (which is a web
| standard, after all)?
| pabs3 wrote:
| There isn't even a non-JavaScript way to use WebAuthn, let
| alone a non-browser way to use it. You could manually rewrite
| the JS for each site into curl calls or something I suppose.
| echeese wrote:
| In Chrome Devtools, in the bottom panel, you can select
| WebAuthn, click Enable virtual authenticator environment, and
| create all the test passkeys you desire.
| Zamicol wrote:
| WebAuthn and passkeys are a disaster.
|
| Much of the specs were created behind closed doors and never done
| in a way where we could have had outside input. They're
| completely corporate driven and designed to control users not
| empower them.
| reddalo wrote:
| I agree. I will not use them, not as a user, nor as a
| developer.
| pas wrote:
| Ah yes the closed doors of the world wide web consortium.
|
| https://lists.w3.org/Archives/Public/public-webauthn/
|
| (nb. I'm not saying the folks were easy to work with or super
| open to discussion, but it was not some clandestine black
| kitchen where it was cooked up.)
| lxgr wrote:
| The working group is definitely quite corporate-driven - just
| look at who's most active in it! - and has made some bad
| decisions in the past (my favorite example being [1], which
| effectively either breaks the hardware authenticator
| experience for passkeys or helps Yubico sell more/higher
| capacity Yubikeys, depending on how you look at it).
|
| But I agree that one thing you can't accuse them of is not
| operating in the open. While I don't agree with some of their
| decisions, discussing feedback in Github issues as well as on
| public mailing lists is probably as transparent as it gets.
|
| [1] https://github.com/w3c/webauthn/issues/1822
| Zamicol wrote:
| You're right that WebAuthn was much more public, but passkey
| was not.
|
| I personally tried to stay apprised of passkey's development.
| After asking several developers and poking around the best I
| could, I was told several times that it was being primarily
| developed behind closed doors for corporate interests,
| invite-only, and wasn't ready for release. The only
| information available was the WebAuthn forums.
|
| Even now the documentation is still poor, and there's
| essentially no rationale to understand design and
| architectural decisions. We're just given a spec and expected
| to adhere to it.
| growse wrote:
| Passkey is just a fancy brand/marketing name for a specific
| mode of webauthn (resident).
|
| Saying that "WebAuthn was much more public, but passkey was
| not." shows that you don't really have a clear and accurate
| mental model of what passkeys are. Maybe TFA might help?
| _Algernon_ wrote:
| Just like every other piece on passkeys it does not justify them,
| at all.
|
| Passwords have problems, but less than putting all authentication
| secrets in a single basket or ecosystem is (which is what big
| tech fundamentally wants).
|
| Passkeys are a solution to a manufactured problem, and keeps
| getting pushed because it is a useful big tech honey trap that
| solidifies their user's captivity in their ecosystems.
| reddalo wrote:
| 100% agree. Passwords + OTPs are the best solution, IMO. No big
| tech can control this, and it's easy to keep a grasp on all the
| credentials we have.
|
| WebAuthn? No, thanks.
| formerly_proven wrote:
| How does big tech exert control over your usage of WebAuthn?
| eadmund wrote:
| By enabling relying parties to blacklist or whitelist the
| devices their users are allowed to use.
|
| It's one more brick in the wall preventing general-purpose
| computing. Want to authenticate to Banana Computers? Well,
| you have to use one of their oDevices, because they will
| not let you use a RoboPhone to store your passkeys.
| lxgr wrote:
| You seem to be thinking of attestation, which is not a
| thing anymore with at least Apple's and Google's
| implementation. (They both had it for their non-
| synchronizing device-bound authenticators, but have
| heavily or even entirely rolled that back in favor of
| passkeys.)
|
| And since any solution excluding either of these is a
| non-starter, ironically the passkey push has made
| WebAuthN _more_ open when it comes to client choice.
|
| So while I agree that Apple and Google not allowing
| passkey exports (yet; I am cautiously optimistic that
| they'll eventually be pushed to offer that too) runs the
| risk of locking in non-sophisticated users, the future is
| looking very bright for everybody posting here at least.
| growse wrote:
| Yeah, you're missing the point of why attestation is in
| the spec in the first place.
|
| Show me a widely available service that filters
| authenticators based on attestation attributes?
| pas wrote:
| Those are pretty strong claims.
|
| KeePassXC has support. Many people use Vaultwarden. And so on.
|
| Also, end users are already locked into Chrome and Safari (and
| Meta's webview and even worse fates).
|
| Passkeys right now has upsides and downsides, like all
| technology.
|
| I think they are both too complex/clunky on the data/spec/API
| side, and not complex enough on the UX/lifecycle side. But
| likely both will evolve based on the usage patterns that get
| solidified.
| eadmund wrote:
| > KeePassXC has support. Many people use Vaultwarden. And so
| on.
|
| It doesn't matter if other authenticators could work if a
| relying party refuses to allow its users to use them.
|
| > Also, end users are already locked into Chrome and Safari
| ...
|
| Not this end user; I am typing this in Firefox right now. Not
| coincidentally, WebAuthn is yet another bit of complexity
| making it slightly more difficult to implement a browser.
| From the perspective of the big tech companies, end users
| aren't expected to write software, or to run anything the big
| tech companies haven vetted.
| lxgr wrote:
| > It doesn't matter if other authenticators could work if a
| relying party refuses to allow its users to use them.
|
| You keep repeating that, but that's not possible anymore,
| since both Apple and Google removed attestation from their
| respective passkey/WebAuthN implementations.
|
| For details, see
| https://news.ycombinator.com/item?id=42522490.
| greenthrow wrote:
| This is an extremely bad take. Webauthn and Passkeys do not
| necessitate handing over control to "big tech". They are
| standards implemented by open source projects as well as
| megacorps. Webauthn offers substantially better security than
| passwords, which we should all be moving away from by now.
|
| Disclaimer; I work in security so my opinions are informed by
| actually knowing what I'm talking about.
| eadmund wrote:
| > Webauthn and Passkeys do not necessitate handing over
| control to "big tech".
|
| Attestation enables a relying party to deny users the right
| of using their own software or devices. That hands over
| control.
| lxgr wrote:
| Apple and Google _discontinued attestation_ when they
| introduced passkeys. It 's gone.
|
| There are still lots of problems with passkeys, but it's
| worth staying up to date if you want to contribute to that
| discussion.
| _Algernon_ wrote:
| Appeal to authority does not make a good argument.
|
| We have witnessed the user capturing playbook of big tech for
| decades at this point. Ignoring what they are doing at this
| point is naive at best, malice at worst.
| greenthrow wrote:
| I obviously wasn't doing an actual appeal to authority. I'm
| anonymous on here, so it would hold no weight even if it
| wasn't a poor argument. I was just being snarky because the
| ignorant objections are so very stupid.
|
| I didn't argue big tech isn't doing user capture. I pointed
| out webauthn is a standard and does not necessitate getting
| into bed with "big tech".
| mardifoufs wrote:
| It might provide more security but no, more security isn't
| the only metric when it comes to user facing stuff like this.
| If it was some implementation detail in a b2b service sure.
| But there are a lot more variables to take into account than
| just "how secure it is". As a trivial example, being able to
| recover an account is insecure by definition, yet is almost
| always necessary for any user created accounts.
| eadmund wrote:
| The very first sentence is:
|
| > Passwords are rubbish.
|
| Hard, _hard_ disagree. They're really not. Password _reuse_ is
| rubbish. Passwords human beings can remember are rubbish. But a
| secure password -- i.e., a random value with 128 bits of entropy
| (such as a random 28-letter string) known only to the two parties
| to an authentication -- is not rubbish.
|
| There is the very minimum amount of protocol necessary: one party
| asks for it; the other party provides it.
|
| The end user can pick his own software to manage his passwords,
| or none at all (a piece of paper in a wallet is remarkably
| secure) _and the relying party to has no ability to approve or
| disapprove_.
|
| I do agree that WebAuthn offers very real improvements over
| passwords (principally due to no longer being a shared secret),
| but it makes things worse for the users in a few ways. For one,
| the ability of relying parties to blacklist or whitelist
| authenticators tramples on the user's freedom to use the software
| he wants. Attestation keys and enterprise attestation are user-
| hostile: users and servers are no longer equal parties.
|
| And finally, the user experience of passkeys with, say, a phone-
| based authenticator is miserable: one must interrupt one's
| computer usage, pick up the phone, unlock the phone, open the
| notification and unlock the app, then put the phone down.
|
| All in all, while WebAuthn does offer real advantages, I am
| concerned by how it reduces users to mere consumers, digital
| serfs to their technological overlords.
| hahn-kev wrote:
| The assumption that only one party knows the password is not
| always (maybe even usually) incorrect. Plenty of sites store
| the password in plain text or hash on the server side. Meaning
| it's very possible for both parties to know it.
| hahn-kev wrote:
| Ignore this, I misread what the author above wrote.
| lxgr wrote:
| > But a secure password -- i.e., a random value with 128 bits
| of entropy (such as a random 28-letter string) known only to
| the two parties to an authentication -- is not rubbish.
|
| No, they're still rubbish. Even if you make them 256 bit,
| passwords are bearer tokens which are reused across multiple
| authentications, which makes them replayable (if intercepted on
| the client, in transit, or server-side), phishable, social
| engineerable etc.
|
| > There is the very minimum amount of protocol necessary: one
| party asks for it; the other party provides it.
|
| And that's unfortunately too little protocol to be secure for
| repeated authentications.
|
| > [...] principally due to no longer being a shared secret
| [...]
|
| No, that's not the most important part of WebAuthN. You could
| get most of the benefits, i.e. phishing and social engineering
| resistance, from running it as a symmetric encryption protocol
| as well. Asymmetric keys "only" make server-side storage less
| sensitive (in the same way that hashing does for regular
| passwords).
|
| > The end user can pick his own software to manage his
| passwords, or none at all (a piece of paper in a wallet is
| remarkably secure) and the relying party to has no ability to
| approve or disapprove.
|
| The same is true for WebAuthN! (The only counterpoint here is
| attestation, but that is no longer a thing ever since Apple and
| Google introduced cloud synchronization for their credentials.)
| The difference is that you now need at least some software,
| because the calculations are too difficult to do on pen and
| paper.
|
| > I am concerned by how it reduces users to mere consumers,
| digital serfs to their technological overlords.
|
| Then... just don't do that! There are several open source
| implementations FIDO for you to choose from at this point.
| hooverd wrote:
| Attestation is still a thing. You can still limit it to the
| Apple or Google platform authenticator.
| lxgr wrote:
| Have you recently tried it?
|
| Attestation was most definitely removed from Apple's
| implementation.
|
| For Google, there's still a (relatively obscure) way to get
| a non-synchronizing/non-discoverable credential (which is
| then by definition not a passkey!), which then supports
| attestation, but that's Chrome+Android specific and
| wouldn't work on e.g. Chrome on Windows or macOS.
| growse wrote:
| I think Apple deliberately don't add any attestation data
| in their implementation, precisely to stop services
| detecting (and filtering) on the fact that it's an apple-
| made authenticator.
| jgalt212 wrote:
| Credential stuffing would be a much less effective strategy is
| web apps went back to string-based usernames, and not email-based
| ones.
|
| Also, I hit CTRL-F on this post for the term "portable", and I
| got zero hits. Both passwords and SSH keys are trivially
| portable. Not so much with WebAuthn passkeys.
| lxgr wrote:
| Let's please not. Password recovery flows are hard enough to
| get right and usually suck; adding _username_ recovery on top
| of that doubles the opportunity for locking legitimate users
| out.
| lxgr wrote:
| Hopefully it shouldn't take much to get there.
| Bitwarden/Vaultwarden already allows exporting the private key
| and (as far as I can tell) all other metadata required by
| another implementation to import them.
| 1vuio0pswjnm7 wrote:
| No SNI:
| https://web.archive.org/web/20241223150914if_/https://www.im...
___________________________________________________________________
(page generated 2024-12-27 23:01 UTC)