[HN Gopher] Ask HN: Why is WebAuthn so slow to take off?
___________________________________________________________________
Ask HN: Why is WebAuthn so slow to take off?
I wonder why I barely see this option on websites altough it seems
so perfect to me. Is the WebAuthn protocol complicated to implement
or are there any other downsides I might overlook?
Author : minipark
Score : 75 points
Date : 2023-04-23 12:09 UTC (10 hours ago)
| edude03 wrote:
| My guess as someone who's been in a position to implement it a
| few times but haven't gotten to:
|
| - "Upstream" Support, For various combinations of stacks I've
| worked on, there has always been one component that didn't
| support it cleanly, (Flutter x Ory was my last attempt for
| example). If it was as easy as "just" enabling it I'm sure it'd
| be more popular, but when your provider or tech stack doesn't
| support it out of the box it's usually not worth the effort to
| implement it from scratch.
|
| - Customer support. This has many sub problems. At my current
| job, customers get confused between social login and
| email/password all the time. Adding a newer more complicated
| technology would be a recipe for disaster.
|
| Similarly, because my job deals with money in a country where
| mobile theft is fairly rampant, the additional burden of trying
| to reassociate a users public key/account/device is problematic.
|
| Finally, I think the concept of managing private keys for a user
| is fairly complicated, though with passkeys and google/apple
| syncing your private keys for you I hope to see this burden fall
| away, and with it the rise of webauthn
| gtirloni wrote:
| This is it, really. Companies have incentives to adopt this at
| the moment.
| weare138 wrote:
| Doesn't WebAuthn require a Trusted Platform Module or an
| equivalent hardware solution, like trusted execution
| environments, for storing keys? This varies across hardware
| platforms and vendors which why I'm guessing solutions like
| WebAuthn haven't become ubiquitous yet.
| fulafel wrote:
| Its a per browser implementation decision, not required by the
| protocol. Chrome family browsers even ship a pure SW one but
| it's in the dev tools side.
| guerby wrote:
| I've asked about it at FOSDEM this year but please when your
| software supports webauthn ask for the following factor in order:
| 1/ login 2/ webauthn 3/ password.
|
| This way webauthn will catch phishing site before you loose your
| password...
| killjoywashere wrote:
| We use it at work and for whatever reason every time I get it
| working one one device, it stops working on another. That and it
| seems to be fragile across the VPN.
| DANmode wrote:
| "the" VPN?
|
| I'd be interested to know which proprietary vendor you're
| referring to.
| vbezhenar wrote:
| I never saw that thing.
|
| How does it work? For example I have Linux, Windows, iOS, Android
| devices and I want to use single HN account on those devices. How
| do I do that?
|
| I think that anything other than email+password will confuse
| users and probably not worth to implement.
| DANmode wrote:
| https://webauthn.io/
|
| https://learn.microsoft.com/en-us/windows/security/identity-...
|
| Exciting that another one of my tech dreams is coming true!
| HopenHeyHi wrote:
| HN gets a public key, that's the account. The private key is
| stored on your device, say on iOS it would be stored encrypted
| in the secure enclave and accessible via TouchID/FaceID.
|
| There is little to no point in stealing the HN user database at
| that point because that's all just useless public keys, it has
| no passwords.
|
| If you wanted to add a device to the HN account you'd login, go
| to the settings, and generate another pub/private key for the
| new device rather than the traditional "change password". As
| there is no password. Most likely you're familiar with a
| variation of this already from sites like Github.
| logifail wrote:
| > If you wanted to add a device to the HN account you'd
| login, go to the settings, and generate another pub/private
| key for the new device rather than [..]
|
| So I'm on my phone wanting to log into HN, and you're saying
| I need to go to my _desktop_ (which is already logged in) to
| generate a key ... for the phone to be able to log in?
|
| Umm, I'm not sure Joe Q. Public is going to view that as
| acceptible.
| aseipp wrote:
| It's basically impossible to answer that hypothetical right
| now, because it depends entirely on the choice of client
| software. And that's still something that's evolving; it's
| just that Apple/Google/MS have the most prominent
| implementations here.
|
| If you have an iPhone and a Mac? No, your iPhone will log
| in via iCloud keychain. You use touchid/faceid to auth as
| usual.
|
| If you have an Android phone and a Chromebook/use Chrome?
| No, it will get sync'd implicitly. You use whatever the
| equivalent of touchid/faceid is to auth, as usual.
|
| If you're using some third party, pure-software, syncing
| solution? No, _probably not_. For example, existing
| password managers will probably just store the key
| material, encrypt it, then sync across devices. Again, pure
| software solution. You use 1Password on Windows 11 and also
| on your iPhone? You 'll probably be fine. (Note: this is
| hypothetical, because 1Pass doesn't support it yet, but
| this is probably how it will shake out.)
|
| If you want to login with your Chromebook using a key it
| has generated and _not_ export /sync the key, and you
| _also_ have an iPhone at the same time you want to login
| with? Yes, you will need multiple keys, one for each
| device, and you will need to provision them.
|
| Realistically this is also a change to login flows on the
| server as well, so there's work to be done for the UX. For
| example many server-side auth packages are still adopting
| Passkeys into their flow, they need to change their schemas
| and frontends. One change to explore e.x. is you can ask
| the user after registering with WebAuthn is to register
| other devices, if they have them. Whether or not that's a
| workable solution remains to be seen.
| logifail wrote:
| > [..] so there's work to be done [..]
|
| OK, we agree _that much is clear_ :)
| HopenHeyHi wrote:
| Sorry if it wasn't clear:
|
| If you logged in to HN using Safari on a Mac the private-
| key (a.k.a "password") got chucked into your keychain as
| part of the account creation flow and is synced across all
| your iCloud devices.
|
| So on your phone when visiting the HN login page you'd just
| be prompted for a fingerprint by TouchID and in you go.
| Actually quite seamless. This would be what 90%+ of users
| experience as normal people don't fiddle with defaults.
|
| I don't use Windows but they have some sort of iCloud
| Passwords thing for Windows now too apparently. Just
| dipping their toe into slowly making it cross platform.
|
| It becomes less seamless and more of a hassle when you are
| using multiple keychains or 3rd party apps which probably a
| lot of people here are. What I described is that case, when
| you have both an Android phone and an iPhone and they are
| completely sequestered from each other (maybe personal and
| work?).
| logifail wrote:
| > normal people don't fiddle with defaults
|
| Just to clarify, these "normal people", they are the ones
| who typically click on links in phishing emails without
| actually thinking?
|
| > an Android phone and an iPhone and they are completely
| sequestered from each other
|
| Q: Why would one not expect to have devices sequestered
| from each other?
|
| Anyway, umm, OK. Sounds like this "solution" means normal
| people are fine, anyone who isn't normal has a new
| mountain to climb.
| HopenHeyHi wrote:
| > Just to clarify, these "normal people", they are the
| ones who typically click on links in phishing emails
| without actually thinking?
|
| Yes? Heh, you know what normal people means, good. Guess
| what, phishing emails tricking people into visiting fake
| websites won't be as effective as with this flow there is
| no password for them to type in and accidentally give
| away to the attacker.
|
| > Q: Why would one not expect to have devices sequestered
| from each other?
|
| Because most people don't carry two phones or bother
| sequestering devices. It isn't the common case so it
| isn't a polished flow. At least not yet.
|
| Don't know about a mountain as you probably use a
| password manager already, it isn't much different.
| vbezhenar wrote:
| > If you wanted to add a device to the HN account you'd
| login, go to the settings, and generate another pub/private
| key for the new device rather than the traditional "change
| password".
|
| I still don't understand how do I do that.
|
| Let's say I registered account using iPhone. Now I want to
| log in with my Linux workstation. So I pick up iPhone, go to
| the https://news.ycombinator.com/settings click "Add device"
| and then what?
|
| I guess something like "recover password" workflow? Like I
| type my e-mail on new device, receive login link and then via
| login link I can register new device?
| watermelon0 wrote:
| This depends on the implementation.
|
| If you are in Apple world, your keys are synced between iOS
| and macOS (and saved in Secure Enclave, so you need
| TouchID/FaceID to complete flow.) In 'Google' world, you
| can use them between Android devices and Chrome browser.
|
| However, if you access from unsupported app/device (e.g.
| use Apple Passkeys and want to access from browser on Linux
| machine), you can always just scan QR code with phone, and
| use it to log-in.
|
| You can try it on https://www.passkeys.io
| mszary wrote:
| > The private key is stored on your device, say on iOS it
| would be stored encrypted in the secure enclave and
| accessible via TouchID/FaceID.
|
| What's important is that even though they are stored in the
| SE, they are no longer tied to the device and can be
| exported. Prior to the introduction of passkeys, all FIDO-
| based keys were minted inside the SE, without the option of
| being exported.
| [deleted]
| 64operator wrote:
| Nobody wants this, it's a big pain in the ass.
| rektide wrote:
| _Passkeys_ is a new FIDO standard that will let the private
| keystore be backed by the cloud. It was added to WebAuthn fairly
| recently. Having keys tied to specific physical devices was a
| terrible & frustratingly limited scheme that never had any hope.
| Now that there's something a little bit looser, there's some
| small hope WebAuthn starts to become interesting & viable.
| https://developer.chrome.com/blog/webauthn-conditional-ui/
|
| Another huge challenge is that there are so very many ways for
| developers to use this tech. There are a truly humbling amount of
| scenarios & flows one can set-up. Many of the most direct paths
| continue to have the user already set up an account via regular
| email/password, so users still end up doing the same account
| management anyways. I'm missing the link to the wonderful
| wonderful guide I spent a couple commute rides reading, but it
| was one of the longest most technical pieces I've read in quite a
| while. "Introducing the WebAuthn API" is perhaps a reasonably ok
| substitute. https://medium.com/webauthnworks/introduction-to-
| webauthn-ap...
| alsdfjkslfheu wrote:
| is passkey any better than a password manager, besides losing
| the option to set your own secure password that you can store
| offline?
| xoa wrote:
| Fully managed passkeys will always have the max needed
| entropy without any need for KDFs, never be reused, are
| amenable to a smooth path to hardware backing, and most
| importantly/fundamentally aren't symmetric factors. You don't
| need to share the private key with the website, and that in
| turn means that even if you stored it in plain text on your
| own computer you're still immune to the most common form of
| leaks which is services themselves getting hacked. Password
| managers make it easier to change a password after a leak has
| happened, but moving to a proper key based infra means that
| leaks simply no longer matter. It doesn't matter in terms of
| auth if attackers get a public key.
|
| While having more hardware backing on top certainly has
| advantages too, it's the symmetric nature of passwords that
| have always made using them in a shared environment a
| fundamentally bad idea. Practical advantages of moving on
| like eliminating all the stupid legacy password policies and
| so on in one fell swoop are nice as well.
|
| > _besides losing the option to set your own secure password
| that you can store offline?_
|
| There is nothing inherent that would stop passkeys from being
| converted to base64 and printed on paper same as any key, and
| part of the point of them is being able to back them up all
| the normal ways and have them secured with a good password or
| other option that never leaves your own control. Which of
| course you can then print out.
| ljm wrote:
| As I recall it, this is more or less what Mozilla wanted to
| do with Persona back in the day. That didn't take off, but
| the approach with WebAuthN is perhaps an evolution of it
| especially in terms of making public key crypto user-
| friendly. Of course, the challenge is different in a multi-
| device world when you want your phone, tablet and laptop to
| all use the same login without using a hardware key.
| rektide wrote:
| If nothing else, it has more bits of security than a password
| has & so is less crackable.
|
| It's also an official standard that should integrate
| effortlessly into apps & websites alike. Password Managers
| are- as far as I know- all bespoke solutions with their own
| custom implementations. Not having a common interoperable
| framing for implementation & extension limits user's control
| & optionality.
|
| The other major advantage is that sites don't need to support
| "Passkey". They support Webauthn. Then the user can use what
| the user wants to use. If they want to use a hardware key, go
| for it. If they have a user agent that implements WebAuthn by
| carving their keys in a stone tablet & using computer vision
| to read the credentials back, they can use that. Standards
| enable flexibility which enables possibility.
| alsdfjkslfheu wrote:
| > Standards enable flexibility which enables possibility.
|
| what?! standards are the opposite of flexible. by
| definition.
|
| here's something that is better than webauthn, published
| and battle tested since 2018, and nobody cares:
| https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
|
| it have all the advantages of webauthn, plus it is truly
| on-device, no middle man, you can easily recover keys
| simply by having more than one device... no server can read
| or data. only silly thing is that firefox insists on
| shipping with the auto-fill option enabled by default.
|
| only feature missing that this thread seems to brings up is
| support for external usb devices (which i personally don't
| care for, but is probably on the roadmap)
|
| --
|
| i'm blocked from adding replies, so replying here:
|
| > it does passwords not keys
|
| well, that is what worked on 100% the internet in 2018 (and
| today, ha!). But it is a data store where you have full
| control. ironically this is what gives true flexibility, a
| well designed system with fully open source implementation
| and apis, not spec by ad vendors as claimed before. anyway,
| The existing browser implementation does passwords (and
| bookmarks!!!) but you can extend to be a distributed
| yubikey if you'd like. nothing is blocking you. as I said,
| it is something better than a hardware store, better than a
| cloud broker for your identity, etc... but nobody cares.
| And now that FIDO has marketing from the big Advertisers
| everyone wants it yesterday.
| tadfisher wrote:
| Firefox syncs passwords, not keys. Passwords can be
| reused, stolen, or leaked, all of which cannot be done to
| WebAuthn keys.
| rektide wrote:
| WebAuthn I think proves quite well how a common
| abstraction can enable constant ongoing growth &
| expansion. This case alone is a clear win for standards
| being a way to get the ball rolling.
|
| Web Standards also tend to define what things look like
| for the page. They're a common interface for the
| developer. This does come with some constraints (but
| often some freedom/extensibility points are baked into
| specs too). What's notable is that implementation is
| replaceable. Different browsers can do different things,
| expose things in differnt ways.
|
| Users can also deploy Web Extensions to modify or
| monkeypatch or polyfill webapis in ways that they want.
| This is another key advantage of standards, that they
| create a common target which is user-instrumentable.
| Without standards, users are forever adrift & subject to
| the mercy of the various proprietary implementations.
| gtirloni wrote:
| 1Password has passkeys in beta.
| JackGreyhat wrote:
| Your password cannot leak, because it does not exist.
| Passkeys can also not be phished.
| jacooper wrote:
| Personally I wont use it as Long as I cant store my keys in my
| own password manager.
|
| I don't use stock android, windows or iOS, and I'm sure as hell
| don't want to be locked to one of them if I did.
| egamirorrim wrote:
| I'm not a huge fan of removing the 'two' from 'two factor
| authentication'. If people can login with just their device,
| which could be stolen, I don't think it's as secure as a
| password+device based 2FA alternative
| Apreche wrote:
| Some people, who are not me, say that it's still two because
| they have to have the device but also have to be able to unlock
| the device.
| vbezhenar wrote:
| That makes sense (as long as device asks for PIN every time
| you use webauthn). Bank card uses the same logic: you present
| both card and PIN code and it counts as two factors.
| somat wrote:
| I have heard arguments that using a password locked ssh key
| is two factor authentication for the same reason, that is,
| what you have(the ssh key) and what you know(the password to
| unlock it)
|
| However I am not convinced, I think it comes down to
| dependency of factors in the auth scheme, if one factor
| unlocks another factor there only really is one factor, all
| factors must independently lock.
| m-p-3 wrote:
| The "something you have" shouldn't be easily replicated. If
| someone could capture your SSH key passphrase and copy the
| ssh private key then it's not an actual 2FA. a device like
| a Yubikey won't let you extract the stored keys, so the
| only way to gain access is to steal the physical key and
| that makes the attack much harder to do stealthily.
| DangitBobby wrote:
| Devices get snatched out of hands all the time.
| drexlspivey wrote:
| Even if they snatch it unlocked they still can't login
| because there's an extra biometrics check required for
| WebAuthn
| [deleted]
| turnsout wrote:
| On Apple platforms, a biometric authentication is required to
| proceed with webauthn, so technically it is 2FA (something you
| have and something you are).
| jameswestgate wrote:
| WebAuthn to either a a hardware key protected by a pin, or to a
| passkey protected by a biometric. Both definitely qualify as
| 2FA
| watermelon0 wrote:
| But there is no password, so we are back to 1FA, with Passkey
| being the single factor.
|
| This is similar to using password manager, with the exception
| that malware cannot steal your keys ... however, if it's able
| to steal passwords from password manager, there is a good
| chance that malware can also access your browser's cookies.
| flangola7 wrote:
| It is still 2FA. Something you have (passkey on a device)
| and something you are (LIDAR map of your face and pulse).
| [deleted]
| bawolff wrote:
| From a practical standpoint, i dont really think it matters.
|
| The real threat 2fa auth solves is the fact people blame the
| site operator when they are hacked. 90% of the time it is due
| to reusing a password. The other 10% it is due to phishing.
| WebAuthn stops both. 2FA works not because it adds another
| factor, but because it removes choice from the user so they
| can't screw it up.
| MattPalmer1086 wrote:
| Interesting take on 2FA. The user not being able to screw up
| is of course important, but the second factor (something you
| have) works primarily because it is tied to something
| physical and therefore local to the user, which is not
| subject to remote attacks.
| markkitti wrote:
| Here's the concept. Perhaps we have the order wrong. Maybe
| the physical factor should be the primary factor. The
| second factor should never be transmitted, but rather is
| used to unlock the physical factor.
| alwaysbeconsing wrote:
| Requiring a password for a hardware key doesn't add much
| to the key already being in your pocket or locked in your
| house/office. It helps against an attack that's
| specifically targeting you as a person but it's basically
| just a nuisance for you when considering generalized
| account attacks.
| ctoth wrote:
| Not really part of what you said but this just caught my
| attention and I thought I'd ponder about it in public a
| bit.
|
| We used to think that
|
| > It helps against an attack that's specifically
| targeting you
|
| would be sufficient, because, like who cares about little
| old me? But in the era of API intelligence, setting up a
| specific agent to target every person seems automatable.
|
| If all that was missing before was a sufficiently-
| motivated attacker who would learn about you and your
| patterns, and that couldn't scale because we didn't have
| enough dedicated bad guys, that seems like it's a bout to
| change pretty quick.
| runarberg wrote:
| Don't most people that this this "correctly" use a password
| manager which stores passwords on the same device as stores
| the totp token and generates the one time code? Doesn't
| this effectively turn your password into a device that you
| have, effectively turning the first factor ( _something you
| know_ ) into _something you have_ , while the second factor
| ( _something you have_ ) is the same thing you have from
| the first factor (your phone)?
|
| Even people that do this incorrectly and reuse passwords,
| probably also store their passwords in their browser, which
| is on the same device as their authenticator app. So I
| would guess by far majority of people are only using
| _something they have_ twice.
| noisenotsignal wrote:
| That's the trade off being made for convenience. It's
| still somewhat multifactor though (I've seen people call
| it 1.5FA); authentication codes have the benefit of being
| resilient to replay. So, you're not pwned even if someone
| steals your password somehow.
|
| Even if someone steals your phone, you should have a
| passcode. If they know or guess your passcode, well...
| someone could steal your house/car keys too, and we still
| carry them around anyway :)
| guerby wrote:
| Be careful to not lump all 2FA together: only FIDO2/webauthn
| second factor is immune to phishing.
|
| evilginx will happily steal most other 2FA (TOTP, ...).
| jackjon wrote:
| [dead]
| smashed wrote:
| I would say because it relies on an hardware key, which few of
| your users are going to have anyway. Any tech requiring an
| hardware component is going to be much slower to deploy.
|
| I know there is still much interest in deploying it for
| internal/employee authentication in large organizations where you
| control the app login and the employee hardware. Some
| organizations that wrongly deployed multi factor auth based on
| SMS have realized that was a poor choice and are looking for
| alternatives.
| acdha wrote:
| > I would say because it relies on an hardware key
|
| This isn't true on Apple, Google, or Microsoft devices which
| have a trusted hardware store - I use my MBP's Secure Enclave
| for 90% of my logins since it's just a Touch ID check.
| tialaramex wrote:
| Well, there _is_ a hardware key, it 's just that it's the
| device you're using.
| acdha wrote:
| Right, but that gets rid of the objection: there's no
| second thing to buy and carry around, it's faster, and it's
| more secure than the alternatives.
| turnsout wrote:
| In other words, having a hardware key is not a real barrier
| to use.
| politelemon wrote:
| The opposite. It's a barrier because most users don't
| have one.
| turnsout wrote:
| ...and yet most users are browsing using a device which
| itself contains a hardware key... and thus it is not a
| barrier.
| cwalkatron wrote:
| I think it's because it's a pain to have one key per device. To
| solve this, you'd need a service like iCloud Keychain (for Apple
| devices), but that only works for Safari and other Apple stuff. I
| think once 3rd party apps (like 1Password - see
| https://www.future.1password.com/) start supporting the syncing
| of keys, you'll see more use. Alternatively, if you could use
| iCloud Keychain with Chrome and Firefox, maybe that would work,
| too. Looking forward to this future!
| guerby wrote:
| The whole point of a FIDO2 USB key is that the secret in it
| cannot be copied.
|
| If it can be copied any malware will just copy it and done.
| evolve2k wrote:
| Not sure everywhere else, but within the Ruby community the
| 'devise' gem is most popular auth plugin.
|
| Discussion are currently underway as to how to refactor the code
| to make passwords second class citizens. And further whether to
| factor in design for MFA or just to bypass straight to adding
| passkey support.
|
| It's major replumbing to essentially move username/password to be
| one of many, within the auth framework.
|
| Once this is resolved in devise thousands of Ruby/rails apps
| could add support overnight, but it seems to be getting a little
| stuck on the question of the best way forward (and someone to do
| all that heavy lifting).
|
| Join the conversation if you have something valuable to add:
|
| https://github.com/heartcombo/devise/issues/5527
| m-p-3 wrote:
| I'm currently looking into deploying hardware keys for some of
| our users at work (mostly through Microsoft SSO which is FIDO2
| passwordless), and one of the roadblock on our end is the
| inability to define our own minimum requirements for the PIN.
| Educating our users about the importance of using a secure PIN is
| indeed a priority, but it would be nice from a security
| standpoint of we could enforce some policies on our end to at
| least eliminate the possibility of settings some obviously weak
| PIN (0000, 1234, etc)
| DANmode wrote:
| > it would be nice from a security standpoint of we could
| enforce some policies on our end to at least eliminate the
| possibility of settings some obviously weak PIN (0000, 1234,
| etc)
|
| If your security model requires you retaining that level of
| control over your user's device security, MDM seems like the
| only option.
| techsupporter wrote:
| > control over your user's device security, MDM seems like
| the only option.
|
| I hope that both the person to whom you are replying and
| their users and bosses remember that once someone has that
| level of control, it's not really that user's device any
| more.
|
| Where I work, we debated this sort of setup, but rejected it
| in favor of NFC Yubikeys largely on privacy grounds. We had
| several employees (doctors and nurses among them, since we
| are a medical practice) object to a device management
| profile, especially because of the remote wipe permission.
|
| Instead, we adopted Yubikeys and an automated provisioning
| process with a break-glass procedure if someone gets locked
| out.
| shawabawa3 wrote:
| Why do you require a pin at all?
|
| The point of hardware keys is to protect against online
| takeover. Physical access is usually game over either way
| michaelt wrote:
| Because Microsoft's implementation is incredibly boneheaded,
| and doesn't allow the Google-style mechanism of
| username+password+Yubikey. They only support U2F/Webauthn as
| an _alternative_ to a password.
|
| I assume Microsoft is hoping to make Windows the main
| Webauthn provider out there, to tie online identities into
| the Windows login process for easier tracking/advertising.
| m-p-3 wrote:
| Since Microsoft's implementation of FIDO2 is passwordless,
| you NEED to use a PIN, which is the "something you know"
| part, the key being "something you have".
|
| And if the PIN is complex enough, bruteforcing or guessing
| won't work as I believe the default behavior is to wipe the
| secure element storage after 8 incorrect attempts (with 3
| attempts per key being initialized at a time).
| turnsout wrote:
| It adds another factor (something you know), which increases
| the difficulty of an exploit.
| jameswestgate wrote:
| 2 factors - something you know and something you have. The
| device is what you have, the pin is something you know,
| otherwise anyone can pick up your security key and use it
| [deleted]
| account-5 wrote:
| I'm glad it's slow, the current "solution" to tie your
| credentials to a device that can be lost, stolen, or broken with
| the option to sync them to a cloud controlled by big tech
| companies is abhorrent. And adding more devices is not the answer
| either.
| perlgeek wrote:
| You're listing only the negative aspects, but in truth it's all
| tradeoffs. What you get is fishing-resistant authentication,
| that's pretty easy to use.
|
| > And adding more devices is not the answer either.
|
| Why not?
|
| What's your ideal authentication solution?
|
| Two things I'd love to see: Something like Mozilla Persona, and
| maybe SSH key authentication in the browser. No idea how I'd
| manage and back up my key though. Don't think it's easy for the
| broad masses eitehr.
| itake wrote:
| As stated, devices fail, or get stolen.
|
| When I'm traveling and robbed, I won't be able to get the
| backup device is hidden in my drawer at home
| fatfingerd wrote:
| You also won't have access to the TOTP backup of emergency
| codes.. If you get hit on the head or have the trauma of
| your life you might not have a password.
|
| These are tradeoffs that people use to balance security.
| Many people will lose to a sim swap despite not needing
| access to their life savings while on vacation with
| absolutely no proof of identity and a fallible memory.
| u801e wrote:
| > What's your ideal authentication solution?
|
| Client side TLS certificates used in combination with
| username/password. Had browser vendors improved the UX
| experience in generating CSRs and storing certificates, then
| it could have been a viable option. The nice thing about this
| is that it's application level protocol agnostic. It could
| even be used for SMTP and IMAP connections instead of just
| being limited to HTTP like webauthn.
| account-5 wrote:
| I really only see the negatives here. This solution offers me
| nothing over my password manager other that way less control
| over my own stuff, more ways to be locked out of my accounts,
| with the slightly added benefit that I don't have to worry
| about a sites shitty security practices.
|
| > What's your ideal authentication solution?
|
| I've said before as soon as passkeys can be managed offline
| and aren't tied to devices I'll be all in. Keepassxc is my
| preferred solution just now.
| sunshinerag wrote:
| does the standard mandate any of that?
| alsdfjkslfheu wrote:
| Kinda of. one very important thing everyone overlooks when
| talking about web standards, is that they are written by
| Advertise vendors. Mozilla was the only W3c contributor that
| was mostly isolated from that conflict, and it was only a
| single degree! You can continue to ignore, but please, try to
| deny if you can before down voting.
|
| The backends are either cloud controlled (hence associated
| with your subscription) or device controlled (associated with
| the serial number, purchase, drm... ignore your fancy key,
| everyone will use the TPM in their laptop/phone). And yes,
| All protocols have similar restrictions to hide information
| from one side and another (publisher, relying party, etc) but
| none are better than the isolation you get today with same-
| origin. And those were put in place by the same advertisers,
| so it will not be a problem either.
| rgreen wrote:
| hard disagree. my favorite workflow for high value accounts is
| webauthn backed by secure enclave with hardware key backups.
| it's really low friction from ux perspective and it frustrates
| me when sites don't support it.
| alsdfjkslfheu wrote:
| what's your key backup/recovery strategy?
| rgreen wrote:
| recovery is easy. i'm a customer of all these companies so
| i have faith i'll be able to convince them i'm me if it
| comes to that. and i keep a handful of hardware keys to
| make self-recovery easier if i lose or break one. most of
| my practices are to mitigate risks i personally know how to
| mitigate, and doing it while causing myself as little
| headache as possible. being able to auth using touch id on
| my personal laptop is great for day to day usage.
| danieldk wrote:
| Also, if you use iCloud for passkeys, Apple has has a
| procedure to regain iCloud access with a recovery
| contact:
|
| https://support.apple.com/guide/security/account-
| recovery-co...
|
| (No, that doesn't mean that the contact has access to
| your account, the encryption key is split between the
| contact and Apple by the device.)
| jbverschoor wrote:
| Let's see how perfect it is when you need to switch devices or
| operating systems.
| xtagon wrote:
| One downside is that it requires Javascript.
| altairprime wrote:
| It doesn't provide any benefit to site operators. There are no
| punishments, drawbacks, or sticks to prevent web operators from
| shrugging off and ignoring WebAuthn in favor of implementing the
| bargain basement choice, user/password.
|
| Sign in with WebAuthn via hardware touch sensors is incredibly
| effective, but is also not an option for a considerable fraction
| of each site's users. So it'll always have to be a _second_
| method, not a first, and it comes with privacy hindrances for the
| greedy (think: Apple Private Relay integrated UI).
|
| Browsers would need to start presenting security warnings for
| classical password autofill to push adoption to the next level.
| turnsout wrote:
| Eventually the goal would be to remove username & password
| altogether. That would be MUCH simpler for developers. No email
| integration for forgot password flows, no need to hash and
| store credentials, etc. WebAuthn is dramatically easier to
| implement than passwords.
| altairprime wrote:
| What will folks accessing sites at a library do? They can't
| access their cloud account, it's a library computer.
| tough wrote:
| Spin up a VM to use ?
| cvwright wrote:
| I don't know the answer, but this is a pet peeve of mine.
|
| It's especially frustrating when sites won't let you enroll for
| 2FA with a hardware token. Instead they require that you start
| with some crap "authenticator" app first. Looking at you here,
| Gitlab and ProtonMail.
| mattrick wrote:
| I believe Gitlab has supported hardware keys for years now. At
| least Gitlab.com, not sure about the self hosted one.
| doodlesdev wrote:
| Also Protonmail supports both U2F and FIDO2. Introduced
| october last year [0].
|
| [0]: https://proton.me/blog/security-keys
| turnsout wrote:
| Fwiw, Gitea now supports WebAuthn!
| falcolas wrote:
| It's not that bad to implement, especially since there are a lot
| of OSS libraries.
|
| The problem IMO is that it will, for most use cases,
| unconditionally authenticate you to a browser, not a physical
| token. And that will confuse a lot of people (and make some
| security engineers twitch).
|
| Why not a token? Lets be frank, pretty much nobody has a yubikey
| style token, and getting average users to use their phone as a
| token over Bluetooth is a recipe for support apocalypse.
|
| For bonus adoption friction, IT has trained a generation or two
| of users to not click on anything that could possibly compromise
| a computer. And webauthn requires actions often associated with
| granting permissions to your computer (Touch ID, Bluetooth
| access, plugging something into usb, etc).
| jameswestgate wrote:
| Passkeys are deliberately designed to avoid the issues with
| Bluetooth pairing. This is why a QR code needs to be scanned -
| devices do not need to be paired.
| falcolas wrote:
| Not all browsers do passkeys.
|
| When I visit https://webauthn.io/ using Chrome on my mac
| laptop, it pops up a bluetooth connection. Firefox asks me to
| connect a device or cancel.
|
| On Windows, Chrome and Edge gives me a QR code. Firefox
| triggers a Windows security popup.
|
| Inconsistency is the only constant so far.
| hooverd wrote:
| What does WebAuthn on Firefox on Linux look like? I got the
| impression it was impossible to use without a blessed bigco
| device and browser.
| aseipp wrote:
| You can use it with Chromium on Linux, but there's two parts to
| WebAuthn: the user-agent, and the client device/software that
| holds the key. So, WebAuthn shows you a QR code which you can
| scan. That happens on the user agent when you try to log in.
| It's no different than Windows.
|
| But the client software is a bit different. The client software
| scans the QR code and then provides proof you're the user you
| claim to be (normal pubkey cryptography) and then the user-
| agent and server do the rest of the dance. You can look at the
| spec, I can't remember all the details. But then the question
| is, what client software do you use?
|
| Most people use their phone for this part. The Phone scans the
| QR code. There's an implementation advantage for most phones:
| they can put the key in cryptographic storage on the device;
| this is one thing most bog-standard PCs are behind on (except
| Apple with the Secure Enclave, which was inherited from
| iPhones.) But again, there's no _need_ for the crypto storage
| here. That 's an implementation detail. Again, it just needs to
| scan the QR code and provide the proof. How that happens is
| totally arbitrary.
|
| So in theory you can use _any_ software that can just scan a QR
| code and abide by the spec, for the second part. You could
| write your own code to store the keys in your GPG keychain, or
| whatever. But in _practice_ , phones have the most mature
| implementation today. Most people use phones. They're the most
| robust and portable solution for most people right now.
| Presumably "sometime soon" things like 1Password, BitWarden,
| KeePass, and all those others -- their software will support
| scanning the QR code and then providing proofs. They'll sync
| your encrypted database or whatever too instead of using a
| hardware crypto enclave, but again: implementation details.
|
| So there's nothing about "blessed devices" here or whatever. I
| think in practice it's just that this is all relatively
| detailed and security sensitive components, both the user-agent
| and client software. So those companies are in the best place
| to implement all that shit. They also tend to have the
| advantage of their moat; it's easy to onboard Android users via
| Chrome or Apple users via Safari. It's relatively new, and so
| the demand for alternative software solutions hasn't reached
| any critical mass, either.
|
| Also: all of this change the login model a bit, so you need to
| be able to e.g. associate multiple keys with one account.
| That's a server-side thing; maybe you need a schema change for
| example. There's some effort to be spent here by all parties.
|
| Firefox does not support Passkeys at the moment on Linux.
| Chrome and Chromium do, I believe.
|
| You could possibly hack some shell scripts to read a QR code
| from a screenshot and then put/retrieve the key from `pass` or
| whatever.
| jeroenhd wrote:
| I use it everywhere I can for the stuff I host.
|
| With how even banks rely on SMS for 2FA these days, I think this
| stuff just isn't on most companies' radars. It adds some
| convenience but until whoever is in charge of setting out a road
| map is convinced this is useful or something users may want,
| there's little benefit to spending the dev time.
|
| I use my phone for this stuff because Linux doesn't really
| support this stuff without faffing about with command line stuff
| and these keys are quite expensive (especially considering you
| need two to be safe).
|
| It's a shame, really.
| turnsout wrote:
| I'm honestly considering changing banks because my bank only
| supports SMS 2FA, and it triggers for every login. They need to
| at least adopt old school TOTP. In 2023, relying on SMS feels
| irresponsible for a side project let alone a bank.
| mszary wrote:
| Authentication is one thing. When it comes to banking - the
| authorization is the key (no pun intended ;) Believe it or
| not, SMS is still one of the best ways to authorize sensitive
| transactions, even when compared to other popular options
| like TOTP or FIDO. The cool thing about SMS is that it gives
| you more context about what you're authorizing, so you're not
| blindly accepting requests from the bank without
| understanding what they're for. It's not perfect, but it's
| still pretty handy
| turnsout wrote:
| I hear you, but the not so cool thing about SMS is how
| trivially easy it is to clone a SIM. My level of trust for
| information passing through the SMS channel is near-zero.
| techsupporter wrote:
| I noticed a couple of weeks ago that First Technology FCU
| allows using a TOTP second factor _and_ deleting the mobile
| number entirely.
|
| Due to this, I'm in the process of changing over all of my
| regular banking stuff to them right now.
|
| (They are also the only remaining US issuer of proper chip-
| and-PIN payment cards, so far as I know.)
| albertgoeswoof wrote:
| It's easy to implement, the reason it's not more popular is
| because services are including support for other 2FA options, and
| users pick the path of least resistance.
|
| I wrote about this here https://blog.mailpace.com/blog/why-we-
| use-webauthn-for-2fa/
|
| In short, we should implement webauthn, and only webauthn for 2FA
| exabrial wrote:
| Please, if you back with Ally bank, email them and tell them you
| want Webauthn, not SMS. Ask to have the email forwarded to the
| head of development.
|
| Please and thank you.
| mszary wrote:
| What about the transactions authorization?
| turnsout wrote:
| Use the mobile app as the channel for any additional
| confirmation.
| okhuman wrote:
| Looking for early feedback on AuthCompanion - a webauthn server
| (w/ JWTs) to make integrating user authentication with your web
| apps simpler.
|
| https://github.com/authcompanion/authcompanion2
___________________________________________________________________
(page generated 2023-04-23 23:02 UTC)