51–60 of 182 posts
This way webauthn will catch phishing site before you loose your password...
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.
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.
Earlier quoted context omitted.
> 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.
Well, there is a hardware key, it's just that it's the device you're using.
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.
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 anot…
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 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 stu…
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.
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.)
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…
> 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.
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.
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.
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.
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.
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 anot…
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.