211–220 of 600 posts
Earlier quoted context omitted.
That's not how my YK works. When I go to a new computer and login to my Google account, it asks me to insert it and press the button. Did I configure it wrong?
Something I noticed after reading this thread is that Google basically converted my YK from a 2FA security key to a Passkey. I'm so confused.
Earlier quoted context omitted.
I'm pretty sure the goal here is to turn your phone into your passkey, _and nothing else_. Everything written in that article makes sense if you keep that in mind.
This is a terrible idea though. I had the misfortune of getting into a cycling accident which broke my phone display (completely lost display output and touch input), and it meant I lost access to all my OTP 2FAs for a couple of days (which is actually kind of scary). I was able to fix it myself by getting parts and going through an ifixit guide (right to repair anyone? ;-), after which I promptly exported my 2FA see…
Bitwarden, too. I no longer have to worry about not having my phone on me, or even having to take it out of my pocket.
Earlier quoted context omitted.
That would certainly be very convenient, but it would also retain/reintroduce several of the security weaknesses that passkeys are intended to mitigate. The reality is that security is really, really hard. And it remains as true as ever that increased security comes at the cost of decreased convenience. My personal attitude is that I make different security/convenience tradeoffs for different things. I do have and us…
I can see how remote enrollment makes it easier for a user to share a key in a way they shouldn't, but not all that much easier. What other weaknesses will be introduced?
Right now, the public key from one token is unique to that site (and specifically your registration attempt with the site, so you can have multiple unlinkable accounts using the one FIDO2 key). If you could do an offline and remote enrollment, you'd need to work with a single static public key (and corresponding private key) for all sites.
Despite all this, I still think this is a use case that's important - both the ability to have an offline backup key (even pairing all your tokens together at setup time to use a common internal root AES key wouldn't help as there's an anti replay counter in FIDO authentications from what I recall), and the ability to use passkeys portably across vendor ecosystems, without relying on a single ecosystem as your trust root.
Earlier quoted context omitted.
The software you're describing is called a "Password Manager", and several do support passkeys already in newer versions. There's no real "emulation." 1Password 8 supports them just fine, your browser has APIs so third-party software can integrate exactly for that. So, the answer to your question is pretty much "exactly the same scenario as your password manager getting leaked", which is basically unsurprising and al…
> when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use. How is that different from situations where a website gets hacked and all the attacker gets is a well-hashed version of a unique password? In either case it isn't doing the attacker any good.
And if passkeys were only equal to passwords in practice, it would still -- IMO -- be worth upgrading to passkeys because they're, for this case, a better foundational basis to work around (public key cryptographic authentication versus sharing symmetric keys), and less error prone for users and operators. But in practice they are aiming to actually be better, faster to use, and more secure since every Passkey implementation is basically designed around syncing (iOS 17 TBD) and device authentication, and they are phishing resistant, which seemingly nothing else can hope to solve so we just gave up on solving it and don't ever mention it because it's the users fault that they did it. (No, seriously, did we all just give up on that entirely?)
I will keep invoking the SSH key analogy, here. Very few people are paranoid about SSH keys being some weird psychological "trick" to take Freedom Loving Passwords away from them or whatever (not referring to you), and most people aren't splitting hairs over "Well, you know, if /etc/shadow and /sbin/login the system is set up correctly, and the machine is secure, then there's no real point to using an SSH key, because my password is safe on disk, and you can just trust that." OK, and? It doesn't matter whether you're logging in as root or a normal user, on your VPS or a friends box. People just use SSH keys instead. Everything works around SSH keys today. People do not want to deal with your secret key material. Passkeys are in many ways just SSH keys for the browser. There really isn't much here to think about when you look at it like this, because the whole basic idea has been around for decades now.
Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. IMO physical security keys are better left…
In reality - the majority of leading organizations use Yubikeys to secure authentication across their company. While it's likely not as common for consumers, it is probably the most trusted solution in the enterprise today.
It's all about the FIDO2 hardware attestation. I'd rather use a FIDO2 authenticator with attestation. Call it a passkey or not, I don't want the to use the syncable passkeys without hardware attestation.
Apple doesn't do attestation so if you require that you're already leaving out the biggest platform. But it's a bad thing for self hosters anyway. Because parties will make exclusive deals or only wish to deal with authenticators they trust (eg that pay them for 'certification')
Some companies are comfortable with the idea of a two-factor method that can be airdropped to friends. Major organizations (AWS, among others) are not huge fans of passkeys for enterprise use. When passkeys released, our initial response at AWS was to give organization admins the ability to disallow passkeys.
Overall, I think there are fixes coming across the board from Apple and the FIDO Alliance to address some of the early shortfalls of passkeys.
Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. IMO physical security keys are better left…
Password managers have already made passwords obsolete. I literally don't know any of my passwords except my master one. Passkeys are an insanely overcomplicated solution we don't really need. Browsers just need a simple HATEOAS API for password managers to hook into, and web apps expose some HTML that triggers the browser. The password manager can then determine how to authenticate the user (however the user wants!)…
This is simply not true. WebAuthN is not overcomplicated needlessly (I wouldn't even call it overcomplicated, it's literally just a signed challenge/response dance). It improves on Passwords+2FA in a few notable ways:
1. It prevents shared secrets from traversing the wire.
2. It naturally enforces that users are all using secure authentication keys without password rules nonsense.
3. It kills 2FA by allowing Relying Parties to request user presence verification as part of the primary challenge.
4. It is origin-bound which mitigates phishing.
Passwords don't have any of these properties. And since your password manager handles the details for you, why wouldn't you want it to improve its implementation under the hood making things better for you with zero effort on your part?
Passkeys are wonderful for consumer use, because they're meant to enable your own ability to break glass, by backing up the credential to other devices. You can do this via iCloud (by default) or via things like Airdrop.
Technically, the devices you share this credential to, cannot provide "attestation" - attestation is the "proof" that the keypair was created by a specific device (like a Yubikey, Apple Machine, etc). Manufacturers (like Yubico) ship a keypair / certificate onboard your key, that can't be extracted. There are no external methods to interface with this keypair - granting admins high confidence this is a real Yubikey.
You can see where this starts to become a problem without attestation, and the ability to share the keys. Enterprises are not willing to inherit the risk of an airdroppable credential exposing access to a privileged employees' account. There is a non-risk of digital theft when it comes to a Yubikey.
Ultimately - passkeys can't even be used to unlock your machines, or servers. FIDO2 (more importantly, OS developers) have a long way to go before we're done with passwords for good.
Today, Yubikeys are filling this gap for most of the enterprise market, some of whom have spent multiple millions of dollars on hardware. Passkeys in their current state are going to be a hard sell.
Earlier quoted context omitted.
> The security community really needs to get a grip and start designing systems that are compatible with the extremely low-tech-interest population if we even have a hope of securing systems. If I knew what the solution was I'd be rich. Most of that population seems to do fine managing house keys, car keys, locker keys, etc.
> Most of that population seems to do fine managing house keys, car keys, locker keys, etc. I’m gonna have to disagree with you there. People are constantly losing their keys prolly about as much as people reuse the same password for multiple services.
If the implant fails, you can just go back to the government office / mega corp, show your DNA, and get a new one.
On further reflection, person a) has an evil twin who steals their identity, and person b) doesn't trust the government / mega corp. Back to the drawing board.
Earlier quoted context omitted.
I can see how remote enrollment makes it easier for a user to share a key in a way they shouldn't, but not all that much easier. What other weaknesses will be introduced?
The ability to do auto-enrolment would break the per-site uniqueness of credentials (which makes them pretty strongly phishing resistant under most sane threat models where the browser isn't totally compromised) Right now, the public key from one token is unique to that site (and specifically your registration attempt with the site, so you can have multiple unlinkable accounts using the one FIDO2 key). If you could d…
For one, you could generate a new unique private key for the site login, and then encrypt that with the other device's public key. And you could sign it with the active device's key, so that third parties can't try to send you enrollment data.
If desired, you could handle this encryption in a way that makes it impossible for anyone else to tell what keys are being used.
Or instead of generating a private key, you could securely send a single-use token to the other device, and that token allows it to register.
Either way the fixed public key would only be used once, and only directly between the two devices. It doesn't get tied into the site authentication process. And you could replace or augment it with a symmetric key that's unique to that device pair.