[HN Gopher] Guide to Web Authentication
___________________________________________________________________
Guide to Web Authentication
Author : tosh
Score : 133 points
Date : 2022-06-22 15:02 UTC (7 hours ago)
(HTM) web link (webauthn.guide)
(TXT) w3m dump (webauthn.guide)
| [deleted]
| bragr wrote:
| >It allows servers to integrate with the strong authenticators
| now built into devices, like Windows Hello or Apple's Touch ID.
|
| The problem I have with this is that some consumers won't
| understand the degree to which all of their access depends on
| their MS/Apple account. Consider the hypothetical person using
| this for all their access, smacking their finger down on the
| reader habitually for every pop-up. Ok now they lose their phone.
| Do they remember their apple password? Do they know how to
| recover their account? Are they locked out of their digital lives
| now? For some percentage of people that answer would seem to be
| yes.
|
| For example, the Apple account recovery process [1] seems
| particularly vulnerable scenarios where your devices and wallet
| are lost together, so don't get your bag stollen while traveling
| if you don't remember your apple password.
|
| [1] https://support.apple.com/en-us/HT204921
| sebk wrote:
| I agree that this is an important next step in making WebAuthn
| accesible enough to supplant passwords. Note that once you're
| recovering your password, you've already lost access to your
| end-to-end encrypted data like keychain, and that's a good
| thing. It's still a solvable problem, and there are three
| things that I'd like to see in this area.
|
| a) The ability to share passkeys across vendors, including the
| ability to implement a "sync fabric" as some folks in the
| WebAuthn working group have called it, so it's interoperable
| beyond the major vendors.
|
| b) For these vendors to strengthen their own log in experience.
| Apple only allows their own TOTP implementation and SMS
| fallback to authenticate to iCloud. I'd like to use WebAuthn
| exclusively here, so I could back up access to my now-precious
| Keychain that holds all my FIDO credentials with a YubiKey.
|
| c) A better story about backing up security keys. Implementing
| a) would give us that. Devices that can be initialized with a
| given seed like some common hardware crypto wallets would give
| us that, albeit not without introducing changes to the threat
| model -- you have to store the seed and input it somehow -- and
| hhttps://www.yubico.com/blog/yubico-proposes-webauthn-
| protoco... would give us that as well.
| politelemon wrote:
| The external dependency, for there to be organizations
| managing implementations for this 'sync fabric' makes the
| whole thing quite tenuous and subject to political
| manoeuvring and other unforeseen factors that come with
| maintaining hosted solutions.
|
| Based on past observation of large tech companies, I just
| cannot see this happening:
|
| > so it's interoperable beyond the major vendors.
|
| (though of course time will tell.) Instead I only see this
| good-faith initiative being turned into a tool to further
| promote user lock-in to respective ecosystems and platforms.
| sebk wrote:
| I don't disagree that it will be hard, but I think that
| ultimately all that is needed for this to be possible is a
| standard TPM API that lets you export key material wrapped
| in a public key (corresponding to another TPM, presumably)
| only if it's signed by the TPM itself. This would let
| implementers build something equivalent to Apple's circle
| of trust (https://support.apple.com/guide/security/secure-
| keychain-syn...), and use the new API to share 'Passkeys'
| between devices.
|
| Whether having an open syncing fabric is enough for vendors
| to want to interoperate with it I don't know, but if they
| ship TPM comformant hardware, you as a consumer would have
| the option to use either fabric.
|
| I glossed over a lot of details and the implementation
| might not end up looking like that, but I believe something
| similar would be sufficient to kickstart the effort.
| madeofpalk wrote:
| Okay sure, but isn't that also true for password managers which
| Everyone Should Use?
| vbezhenar wrote:
| Sane password manager uses a local database which you can't
| be banned from. You can easily make a backup of that database
| to some usb drive and put it into safe. You can't make a
| backup of your iCloud account and be sure that Apple won't
| ban you because you're living in a place that US does not
| like.
| madeofpalk wrote:
| You definitely, 100% can make a backup of your iCloud
| Keychain and save it offline.
| https://support.1password.com/import-safari/
|
| I'm sure the user who remembers to back up their password
| manager will also remember their Apple (or whatever)
| password. Parent was talking about failure cases of
| forgetting your "master password" - that's problematic
| regardless of the tech.
| pessimizer wrote:
| > the user who remembers to back up their password
| manager
|
| You don't have to backup your password manager separately
| if it is local. You just have to back up your computer.
| vbezhenar wrote:
| > You definitely, 100% can make a backup of your iCloud
| Keychain and save it offline.
| https://support.1password.com/import-safari/
|
| Can you use it with webauthn after that?
|
| > I'm sure the user who remembers to back up their
| password manager will also remember their Apple (or
| whatever) password. Parent was talking about failure
| cases of forgetting your "master password" - that's
| problematic regardless of the tech.
|
| Apple password is not enough to recover access. Apple
| usually uses 2-factor auth.
| mark242 wrote:
| This is already true. iPhones, and Macs for the past few years,
| are so integrated with iCloud that losing access to your Apple
| ID is going to give you a very, very bad day. Apple clearly
| recognizes this with their work on physically pairing devices
| via iCloud.
|
| WebAuthN is, on the whole, a very good thing. Cross-browser
| authentication that gets lifted up to a biometric or token
| level will reduce the vast, vast majority of customer support
| and friction to creating accounts. Additionally it reduces the
| dependence on OAuth2, having to "register" applications and
| requiring customers to remember "did I use Google to sign in
| here? Did I use Facebook?" etc etc.
| dingleberry420 wrote:
| They'll learn.
|
| Apple needs to do better though, as always.
| vbezhenar wrote:
| Does the service have access to your apple id email? I presume
| that it does which means that theoretically I should be able to
| restore access by sending a password link to that email.
|
| That's presuming that user didn't use icloud email for his
| icloud account, of course.
| pdonis wrote:
| I don't see any user verification anywhere here. All I see is
| Javascript calls that create a credential on the client without
| ever asking the user about it. How is this not vulnerable to
| someone else impersonating me?
| sebk wrote:
| It's on the other portion of FIDO2: CTAP, short for Client to
| Authenticator Protocol. Your authenticator (A TPM, a YubiKey,
| maybe a phone) verifies your biometrics, pin, or presence
| before signing a request for the client (the browser, in the
| case of WebAuthn).
| pdonis wrote:
| Ah, got it. Thanks!
| tialaramex wrote:
| _If_ you request User Verification (UV) rather than just User
| Presence (UP) then the authenticator does whatever it does
| verify this is actually the same user, and not just any human.
| That 's up to the authenticator, and is irrelevant to the
| Javascript code.
|
| On the cheapest devices this is typically a PIN entry, so maybe
| a GUI window appears on their PC and they type in some value
| the authenticator knows, maybe it's "FuckGoogle" or "870429".
| But there are devices where it's fingerprint recognition, it's
| entirely up to the device (except that the PIN entry feature
| has explicit protocol support so that your OS can help out)
|
| After it sees acceptable verification, the authenticator signs
| the message it's sending back, it doesn't actually understand
| most of the message, because it is just a very dumb piece of
| electronics, but it does understand a series of bitflags, in
| this case the flags UP and UV which we mentioned at the start.
| So it knows it is signing a message about User Verification (or
| in most cases on the Web, it is _not_ asked for User
| Verification, because for e.g. second factor on the web you
| needn 't have that, "I have the device" _is_ the second factor)
| some_furry wrote:
| The browser APIs in question handle that aspect. Check out the
| linked demos if you're not sure what that looks like.
| overeater wrote:
| I don't understand why authentication usually requires you to
| type in some 6-digit number from your phone. From an ideal user
| experience point of view, why not just pop up a dialog on your
| phone, wait 1 second (to prevent accidental taps), show "decline"
| or "approve" options, and that triggers the authentication to
| proceed? This seems like an experience that Apple would design.
|
| Even better, use a thumbprint to authorize on the phone, to add
| one more layer of security. Then you hit the trifecta of
| verifying 1) something you know (the password entered on the
| website), 2) something you own (your phone), and 3) something
| about you (your fingerprint).
| Hamuko wrote:
| Google does this for their accounts and Twilio/Authy has a
| solution for it, but I find it to be pretty expensive.
|
| https://www.twilio.com/authy/features/push
| marcosdumay wrote:
| The Microsoft authenticator does exactly that.
|
| It is still a phone-based fenced authentication system, so it
| still sucks. But not due to usability.
| CiPHPerCoder wrote:
| The main value-add is to replace passwords entirely.
| t0astbread wrote:
| I'm not an expert in authentication but afaik TOTP (and HOTP)
| work completely offline. That means you could store your keys
| on a device that doesn't have internet access. On that device
| you can do whatever you want. Some TOTP apps allow you to lock
| your keys with an additional passphrase or a biometric factor.
|
| From my (maybe naive) POV as a user I tend to agree, it would
| be nice to have a standard for push-based authentication so
| that I can actually see when someone else has made it past the
| password prompt. Although email notifications would largely
| solve that problem (if more websites used them).
| overeater wrote:
| I"m not seeing a huge benefit of the personal device being
| offline, while you're trying to log into an online service.
| But let's say there was a need for that, what about using
| bluetooth or wifi direct to push to the device?
| t0astbread wrote:
| Like I said, I don't know the standards, so I don't know
| the authors' intentions. But there are actually specialized
| devices which do nothing but generate TOTP tokens, so that
| seems to be a use case. (The keys don't have to be on a
| phone or in a particular app.)
| jaywalk wrote:
| Why? We've already got better standards, there's no need to
| add complexity to TOTP.
| theluketaylor wrote:
| Push notification 2FA certainly has some UX benefits over
| manually entering a TOTP, but there are documented cases of
| attackers gaining access by triggering the 2nd factor push and
| a user dutifully pressing "approve". Office365 is an especially
| bad vector for this risk as it prompts for auth throughout the
| day at seemingly random intervals while using o365 services.
| Users are trained to hit accept to keep going even if there
| isn't a password entry dialog that obviously triggered the 2nd
| factor ask.
|
| WebAuthN makes this a moot point though. All the auth is
| handled under the hood. There is no password or TOTP code to
| enter and yet in the right setup can be 2FA with minimal user
| interaction. The keys are stored resident on your device
| (something you have) and there is interaction to unlock them
| (finger/are or PIN/know). Best of all it's unphishable since
| the keys are unique per domain, so lookalike domains won't
| work.
| WorldMaker wrote:
| For now it is mostly just that "pull-based" TOTP is
| cheaper/easier and works in more "offline" or "partially-
| disconnected" scenarios. Your phone and the website only have
| to directly "communicate" once: that QR code to bootstrap the
| secret key. After that all of the math is independent: the math
| to generate codes is done entirely on the phone and the math to
| verify it is done entirely on the website.
|
| There is a growing support for "Push" style authorization tools
| that more directly communicate between the devices. Up to now
| the tools have been mostly vendor-specific. Google has push
| notification authorization in the Google ecosystem. Apple has
| push notification authorization in the Apple ecosystem.
| Microsoft has push notification authorization the Microsoft
| ecosystem. The growing WebAuthn standards (for which the linked
| post is a Guide to working with them) are exactly the sorts of
| standards that are being built to increase inter-operability
| between vendors and trying to make "push" style authorization
| cheaper/easier/more ubiquitous on the web. (Those standards
| aren't 100% there yet for multi-vendor interoperability as
| other comments in these threads accurately nitpick, but this is
| still a giant step forward in that direction.)
|
| Also, if your TOTP Authenticator app isn't already using your
| device's fingerprint or Face ID biometric locks, consider
| moving to a TOTP app that does. Most of the major ones do,
| exactly for that "trifecta" reason of layered security.
| AgentME wrote:
| Google actually has this implemented for signing into Google
| with desktop Chrome and Android, but I'm not sure it's
| standardized yet. Ideally Google will make this mechanism
| usable with all WebAuthn-supporting sites.
|
| (It seems like there's two different forms of this that Google
| has implemented. One form is done simply: when you log into
| Google, Google tells your phone to show a prompt, but this form
| is still phishable, because if you're using a phishing site
| while an attacker is proxying your login, they could still
| trigger it. The other form involves desktop Chrome talking over
| Bluetooth to your phone to verify what domain you're looking
| at. This method is immune to phishing domains like other
| WebAuthn authentication methods so presumably this is what
| they'd try to standardize. It does involve multiple moving
| parts so it's not too surprising it's not standardized yet.)
| jaywalk wrote:
| > I don't understand why authentication usually requires you to
| type in some 6-digit number from your phone.
|
| Because it proves that the user logging in is in control of a
| device that they've linked to the account. When you add an
| account to whatever app you're using (Google Authenticator,
| Authy, etc.) what it's actually doing is receiving a
| cryptographic key that it uses to generate the 6 digit code
| based on the current time. Without that key, the proper 6 digit
| code can't be generated.
| overeater wrote:
| I think the procedure I described also can do this, but the
| 6-digit code is sent in the background. I don't see why a
| human has to physically write out 6 digits from phone to
| computer, instead of it just happening automatically.
|
| I main difference here is usability. The current process is
| going into an app, finding+choosing the website from a list,
| tapping that website, manually copying from one screen to
| another, checking that you copied the digits correctly, then
| confirming. This is stressful and takes about a minute. A
| process where you just confirm a dialog, or use your
| fingerprint takes 2 seconds, and doesn't require the mental
| effort of memorizing and writing out 6 digits. If the people
| working on security can't see the enormous difference between
| the two workflows, then this is hopeless.
|
| It's the same issue that plagues the security-minded people
| who think regular users will go around copying and storing
| each others' PGP keys.
| throwaway45631 wrote:
| I understand how users register and login on a device - but it
| gets complicated when wanting to allow users to couple multiple
| devices to an account.
|
| Anyone here with recommendations?
|
| Say you registered via smartphone and now want to login on the
| desktop - do you tell the desktop user to grab his mobile safari,
| login and pull up some PIN-No which then to type into the desktop
| client?
|
| And how would people recover accounts if their devices are lost?
|
| I guess technically one can always come up with some solution -
| but while FIDO gives a unified, cross-device way for users to
| login and register - it's the complete opposite when it comes to
| the aforementioned issues
| Hamuko wrote:
| > _Say you registered via smartphone and now want to login on
| the desktop - do you tell the desktop user to grab his mobile
| safari, login and pull up some PIN-No which then to type into
| the desktop client?_
|
| That's basically how it has to be done, at least for on-device
| authenticators. Granted, you can replace the PIN code mechanism
| with some other one, like having the website email you a one-
| time authentication URL that you can then use to access the
| website to add your desktop authentication.
|
| If you use a portable authenticator (Yubikey), then you can
| just use the authenticator on the phone and on the desktop. The
| ones with NFC will perform the same authentication on mobile
| and desktop.
| sebk wrote:
| Microsoft, Google, and Apple recently announced support and
| commitment for multi-device credentials, which you can share
| between devices in the same "sync fabric". See some discussion
| on Hacker News here:
| https://news.ycombinator.com/item?id=31294316
| notlukesky wrote:
| I could never get it to work on Android phones. The FIDO2
| implementation of CTAP, short for Client to Authenticator
| Protocol. I tried registering it on many sites including
| https://webauthn.io/ and it never worked. I tried it last with
| the Google Pixel 4 with the latest software update. Anyone get it
| to work Android phones? If so where?
| [deleted]
| tialaramex wrote:
| I'm not sure what "it" is in this context. I have a Pixel 2
| which is (consults list) registered at Google, Login.gov,
| DropBox and GitHub. Most other places I have only my physical
| Security Keys registered, but those I added the Pixel 2. In
| particular it isn't registered at Facebook because I only book
| faces inside the dedicated Firefox container on a single
| machine in a single location, so as to reduce my exposure.
|
| In my experience as the phone gets older features start to
| "deteriorate". For example, the previous phone didn't make or
| receive telephone calls after a few weeks without rebooting,
| this Pixel 2 ceases to work as a Contactless payment device
| after a few days without rebooting, and FIDO is the same way,
| so, maybe try rebooting? I figure that one day Google will
| rewrite their core systems in Rust or some other language that
| reduces the rate of heisenbugs and they'll have fewer features
| that "deteriorate" in this way. Also I should buy a new phone
| at some point.
| agl wrote:
| Support is not yet available on Android but support for
| syncable passkeys on Android was announced for some time this
| year at Google I/O.
| notlukesky wrote:
| But in every FIDO2 registration there is a pop up for both
| Android phones and USB security keys with the API call. The
| prompt for registering a device shows both "Add a new Android
| phone" or "USB security key". When you click on "Add a new
| Android phone"it leads to a barcode that when you scan
| nothing happens. Seems real confusing especially if they want
| broader adoption.
| agl wrote:
| 2nd-factor WebAuthn should work fine with Android phones
| today. Any Android phone with a current version of Play
| Services and Chrome should be able to scan the QR code, if
| it doesn't work then it's a bug (or, at least, an old QR
| scanner).
|
| When you say "nothing happens": what's the QR scanner? Do
| you have Chrome installed on the device? What are the app
| versions (from Settings) of Play Services and Chrome?
| photochemsyn wrote:
| I for one look forward to the day when you won't be able to turn
| on a phone or a computer or access the Internet without
| submitting to a fingerprint and retina scan so that all your
| activity can be uploaded into the national security state
| database - for the protection of the children, of course. I
| believe China has already implemented all of this? Nice to see
| the 'free world' rushing to catch up.
| capableweb wrote:
| Not sure how this is relevant? There is bunch of hardware
| solutions that don't involve fingerprint/personal data, like
| yubikeys or even software solutions that just requires you to
| generate a key locally that you can then use.
| lxe wrote:
| Why in the world is this API so complex? Devs will continue to
| implement password authentication even when there's general
| browser support until either there's a simpler way to register
| and sign in users.
| tptacek wrote:
| How could it be simpler? You ask the browser for a credential
| associated with an opaque ID, and get back a public key with
| its own ID. To use the credential, you ask the browser to sign
| a challenge (another opaque ID), and the browser gives you back
| a signature, which you check against the key. It's almost the
| simplest thing that could possibly work; it's much, much
| simpler than OAuth2.
|
| This page is an excellent summary introduction to WebAuthn, but
| it makes the API look more complicated than it is, because it
| surfaces a lot of options you probably won't care about.
| tedunangst wrote:
| An API (or guide thereto) that surfaces fewer options seems
| like the obvious way it could be simpler.
|
| Is attestation optional or required? Is there a default? Can
| I not care? What do I read to not care?
| dyml wrote:
| It's available at https://Passwordless.dev.
|
| I've worked on a open source library for fido2 for about 4
| years and we created an API that makes it A LOT simpler to
| get started.
|
| And when ever you want to leave the API/Service you can
| just migrate to whatever self hosted webauthn service
| you've setup.
|
| Happy to answer any questions.
___________________________________________________________________
(page generated 2022-06-22 23:00 UTC)