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...
In short I don't think PINs should be allowed for use with webauthn and these devices should have a very user friendly configurable timeout so that users don't have to enter it nonstop. If I logged into my bank 5 seconds ago, maybe it's okay for me to also log into my second bank without prompting for my master password aka PIN again.
It's an intelligent trade-off, of course, in threat models that involve access to the physical device for threat models that involve remote access of websites and other resources. Yes, if everything uses the same PIN on a device then that adds to the risk of someone snooping your PIN, stealing your device, and accessing many things in the process. If that is the threat model that most concerns you, then yes, this makes things worse. But PINs can't be used remotely at all and never transfer across a wire. They can't be brute forced remotely over the internet. Having someone's PIN but not the specific device that the PIN unlocks doesn't unlock anything (because you still don't have access to any of the private keys on the device without the device). Websites only know your device's public keys. If you use entirely WebAuthn, breached websites only leak public keys. If your threat model involves concerns about internet hackers or the daily breaches we see in services like haveibeenpwned, device-specific PINs are a massive improvement.
The entire point of two-factor authentication is to have, well, two factors: something you know and something you have. Using the PC itself as token was already problematic enough as it has a massive code base and runs all sorts of untrusted code so it is likely to be compromised at some point - but at least that was somewhat excusable due to convenience making it accessible to way more people. But getting rid of the rest of the credential and solely relying on the OS is just insanity.
If I could make a backup of those keys, I would have been happy with physical devices.
But every time I make an account somewhere, I have to go add devices in triplicate? Ugh it was such an abysmal terrible experience. Physical devices are just too unreliable & too constrained as systems.
Passkeys, to my knowledge, are an extension of FIDO Alliance standards. My hope is that one can bring your own provider. This would avoid the vendor lock that has you quaking.
I was ready to give up until I realized that maybe "internal sensor" means Windows Hello on my machine and yep it does. But no real user is going to click through these security sensitive popup dialogs until Windows Hello shows up as an option. My verdict is that it's still clearly only for techies. And when I cancel the dialog it prompts me to "setup my security key". Just terrible ui, nonstop popups.
Edit: Firefox shows me the Windows Hello option immediately, that should be the default on desktop.
One of my daughters assignments required her to log into an app. At school they do so by scanning a QR code they keep in the classroom. The teacher sent a picture of the QR code.
I found myself in the hilariously absurd situation of needing my laptop to scan a QR code it was displaying on its own screen. I took a picture with my phone and then presented the QR back to the computer.
Your comment reminded me of this.
But that doesn't sound like something I'd ever want. Obviously I want to be able to log in on my computer too?
I disagree. I think it's great having it all under my own control. What's important though is to be able to add multiple keys which many sites don't offer.
Having my keys under control of apple or Microsoft sounds to me like a terrible and frustratingly limited scheme.
But passkeys doesn't rule out physical keys so if people want to get deeper in bed with big tech they can, while I can keep my physical keys.
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.
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.
> 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.
> 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.
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.
When I’m traveling and robbed, I won’t be able to get the backup device is hidden in my drawer at home
Passkeys is relatively close to being a proper successor to Mozilla Persona. The UX isn't quite as polished as Mozilla Persona felt, but Passkeys is a multi-vendor coalition with Apple, Google, and Microsoft all throwing marketing weight behind it, so maybe the UX will never quite be perfect due to the intersection of all that, but the underlying tech is really close to what Mozilla Persona proposed, in a long, round-about away.
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.
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:
- "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
Ory provides a javascript bundle you load to do webauthn, which (again IIRC) didn't work inside the browser inside the app, and although we figured out some workarounds, would have conflicted with how we implemented the native auth.
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.
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.
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.
evilginx will happily steal most other 2FA (TOTP, ...).
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.
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.
Nearly everyone I know has less tolerance for annoying security than me, so I don't see how WebAuth can possibly succeed.
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).
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.
They should have just created this around client certificates like another poster said and then the browser lets people pick and save the certificates to disk and now every user understands that websites will ask for his certificate files and that's okay because those aren't his real OS login.
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.
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.
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.
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.)
If your security model requires you retaining that level of 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.
The point of hardware keys is to protect against online takeover. Physical access is usually game over either way
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.
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).
A) Passkeys / WebAuthn require a completely different user behavior (compared to passwords which everyone is familiar with) and thus a lot of user education. Many product managers see the benefits with less friction, but are super cautious to introduce passkeys for existing systems, especially when users are not too tech-savvy (if you're building a new system for a technical audience, then things look different). Besides it's a huge product management effort to cover all cross-devices/-browser/-platform flows and all edge cases that are involved. Due to the device-boundness of passkeys and the different UI patterns on different device/browser/platform combinations, it gets quickly complicated. Besides you still have to support all your existing login methods: passwords, MFA, social login, SSO. So many product managers looked for larger companies to show best practices for passkey / WebAuthn flows, but so far there's just a handful of these companies, so product managers rather wait for broader adoption.
B) When talking to developers, many have heard of WebAuthn or the FIDO alliance, but integrating passkeys into your existing auth flow is not a 60 minutes task. You have to maintain your own WebAuthn server, deal with different forms of recovery and have to stitch everything together with the existing accounts & login methods. So far there's not many providers who offer easy WebAuthn / passkeys out-of-the-box and many like FusionAuth or Auth0 charge quite a lot for it. Moreover, passkeys / WebAuthn authentication is not anymore a backend-focused form of authentication, but a lot more frontend-loaded, as the UX plays quite an important role and the WebAuthn flow requires JavaScript to call the OS-native APIs. This makes things way more complex than just calling an email-password-auth endpoint. Besides, passkey implementations for native apps (Swift, Kotlin, Flutter) are very basic and good documentation for cross-device flows is lacking here as well.
Nevertheless, there's a lot in the work under the hood and I'm still bullish that things will look pretty different in the near future.
This way webauthn will catch phishing site before you loose your password...
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
I'm always happy to be proven wrong with this. Let me know if I can today (not maybe in the future, but right now) pull down an Open Source codebase onto my Linux computer, compile it myself without submitting some kind of validation check to a 3rd-party that will sign the code, and then batch export from an iPhone/iCloud account into that program so I can use it as provider without individually signing into any of those accounts.
If not, then it's not portable. And that's why people (at the very least people like me) aren't using it, because it's transparently an opportunity to increase vendor lock-in and to allow services to dictate that I can only log into previously client-agnostic accounts using a small set of proprietary platforms. I know that's not the intention of the FIDO Alliance, but their intention doesn't matter if the end result is the same.
Passwords do legitimately have a ton of problems and there is a theoretical version of Passkeys that would be amazing that I would be praising if it existed today. It's not that the idea is bad, there are changes to the standard that could be made that would make this good -- some of them would be controversial, some of them would make security purists upset. We'd need to have a conversation about what hardware attestation is actually going to be used for on a mass-market. But it could happen, it's not that passkeys are inherently bad.
But you will have to drag me kicking and screaming away from a format that is client-agnostic and inherently portable into an authentication mechanism that trivially enables vendor lock-in. Don't tell me about what companies might do in the future, the companies launched products in the present that don't support migration. Fix that, and then I'll listen to conversations about how Passkey/WebAuthn is better.
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.
https://learn.microsoft.com/en-us/windows/security/identity-...
Exciting that another one of my tech dreams is coming true!
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.
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.
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?
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.
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.
If it can be copied any malware will just copy it and done.
https://blog.millerti.me/2023/01/22/encrypting-data-in-the-b...
It needed two things: browser free credential management that didn't need special hardware and a way to move around creds between devices effortlessly.
The security improvements are great but outside of people who care a lot about this (similar to fido2) it makes things more difficult without making other things less difficult.
Please and thank you.
On the client side, support for WebAuthn can be implemented in a variety of ways. The underlying cryptographic operations are performed by an authenticator, which is an abstract functional model that is mostly agnostic with respect to how the key material is managed. This makes it possible to implement support for WebAuthn purely in software, making use of a processor's trusted execution environment or a Trusted Platform Module (TPM).
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.
I'd be interested to know which proprietary vendor you're referring to.
