They really just can’t get out of their own way in screwing this stuff up… Resident keys allow the browser to query the secure element for a list of usernames for a domain. It’s a nice feature, but you have to setup the protocol to reliably fallback to non-resident keys on secure elements that are space constrained. But then they came up with these resident key “preferred” and “discouraged” keywords which are sent by…
Passkeys will come at a cost
121–130 of 600 posts
Re: Passkeys will come at a cost
#122Earlier quoted context omitted.
Apple opened up OS integration for other applications. 1Password is currently doing beta testing of their Passkey implementation. Besides that, the whole idea of Passkey (in contrast to what this blog claims) was that the key material can be synced between devices, so I am not sure how only the phone would be 'a passkey'. iCloud Keychain syncs my Passkeys between all my devices, including to my MacBooks.
The problem with cloud-sync-based managers like the iCloud Keychain is bootstrapping. Since you need to be able to log in to the services themselves to provision access to the passwords. This makes travelling a bit risky, since it's not that hard to lose/break/have your devices stolen during a random trip. This makes it immensely hard to recover, since you cannot just hop onto a public terminal and authenticate (whic…
If Google or Apple implements this, they can design a solution too.
Re: Passkeys will come at a cost
#123Earlier quoted context omitted.
Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. For "important sites where security matters" they are literally better in every way than a password, it doesn't matter how weak or strong. You can use a pure software solution, and soon probably even your existing password manager, to handle them. Again, you should think of them as replacing passw…
> Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. Let's assume a "passkey device emulator" written in software; quite realistic IMHO for someone to use, considering the cost of hardware authentication devices (phones, YubiKey etc.) If someone using such emulator gets hacked and has their passkey emulator data stolen, is there anything preventin…
The particular case I was referring to (and probably should have been clearer about) was 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. But like, that's actually a major issue in practice, because the value of hacking a service operator is often far greater than just one user. That exact scenario was one of the motivations for using password managers in the first place, too, to mitigate operators getting hacked and common passwords getting reused between users, thus turning a single compromise for many users into multiple compromises for many users. So, it all has come full circle in a sense; now we've finally recognized that instead than shoehorning passwords into becoming psuedo-random strings that might as well be base64 encoded bytes from /dev/urandom, you might as well go "all the way" and just get those raw bytes from /dev/urandom directly and then use them as key material for a public key exchange.
Again, the best analogy is to just imagine that you used SSH keys to log into a website. That's all this is. It's software. Then you remember: oh yeah, SSH key synchronization and enrollment across machines sucks ass, and normal people would hate doing it. Hey, you know what, we already use passwords to encrypt SSH keys -- so what if we added a storage synchronization layer between your machines to keep those SSH private keys synchronized, encrypted with that password, and stored using $FAVORITE_SERVICE_PROVIDER? That's pretty much it, in a nutshell. You just reinvented modern Passkeys. Most of the threat models at that point are well understood: what service provider or software to choose, how secure is the local encryption, should you use two-factor authentication to further improve unlock safety, etc.
Re: Passkeys will come at a cost
#124Earlier quoted context omitted.
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…
Maybe I'm getting tinfoil-y here, but I think the horribleness is the point: consider how eager Apple in particular is to get people fully enmeshed in their services ecosystem. You're a lot less likely to try to roll your own backup, or otherwise exit the walled garden, if doing so means your entire auth story is irredeemably fucked. The thing that strikes me about this whole story is that during a lot of the initial…
Re: Passkeys will come at a cost
#125Is 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…
If you think about it, the core problem can be described as "authentication of the biological being with an electronic system". When passwords are used, the authentication interface is a keyboard and you don't have any actual guarantees that the person typing the password is the person who claims to be. The passwords could have been extracted in so many ways because it depends on easily transferable knowledge. Moving…
That seems a dubious assumption.
It's far more often that debit/credit cards are physically lost/stolen than digitally lost/stolen.
(The only thing preventing cards from being a massive day-to-day issue are very aggressive fraud-detection systems and financial controls.)
Re: Passkeys will come at a cost
#126Earlier quoted context omitted.
When I use a Yubikey for passwordless authentication (FIDO2), it challenges me for a PIN before asking me to touch the device. If I give it too many incorrect PINs, the Yubikey locks up and requires a device reset, which invalidates all previous registrations to use that key for authentication. It doesn't seem like a big deal if someone steals my hardware token. https://support.yubico.com/hc/en-us/articles/4402836718…
It means though that your secure hardware token has a reliable way where the secrets all self-destruct. That someone can easily do if they get even brief hardware access. For people who have a problem keeping sufficient backups (almost everyone on earth) this seems like a horrific blocker, a show stopper for this entire intiative. I personally think these things absolutely should be able to be exported & backed up se…
For me allowing a weak 2FA that moves you from the pool of people that can be trawled to the people that need to be specifically targeted is a huge improvement, but my fear of losing access to critical systems because I lose my phone fills me with dread.
Re: Passkeys will come at a cost
#127Earlier quoted context omitted.
It means though that your secure hardware token has a reliable way where the secrets all self-destruct. That someone can easily do if they get even brief hardware access. For people who have a problem keeping sufficient backups (almost everyone on earth) this seems like a horrific blocker, a show stopper for this entire intiative. I personally think these things absolutely should be able to be exported & backed up se…
> I personally think these things absolutely should be able to be exported & backed up separately. I agree. The usual response is that you don't need to do this because you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup. But managing that sounds like a real pain in the butt to me (honestly, the entire passkey system sounds like a real pain in the butt to me --…
Requiring ongoing physical access to your crucial backups to do any account enrollment or changes seems like a way to make sure you have your crucial backup way too close to potential disasters. Ideally I wanty backup keys many states away from me. But then I can enroll them!
But it feels like there could be some kind of pubkey for those keys that I could also enroll at the same time as I'm getting my first device.
Except these devices don't have just one pubkey cause that wouldn't be secure. Maybe they pre-make & share 20 keys with a peer device or something. Somehow though data needs to at the end be able to get into the backup/other device too though. Ugh it's wild.
Re: Passkeys will come at a cost
#128Earlier 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…
Yes, those recovery paths are also susceptible to phishing, scam attacks, and they should be designed with that in mind like, for instance, with ID verification, notifications from multiple channels, process delays.
Everyone should go over their Authenticator app and check their recovery options with every account they have there to make sure they don't fall into this trap.
Re: Passkeys will come at a cost
#129Earlier quoted context omitted.
Have you not heard of "SIM swapping?" [0] The FBI (US) receives thousands of complaints, which I'm guessing means it's orders of magnitude more common. [0] https://blog.mozilla.org/en/privacy-security/mozilla-explain...
There are two separate problems - the first one is to make sure others don't have the access you don't want them to, while the other is to make sure that you/others have the authorized access. SIM swapping means someone else might be able to have my phone number, but I'll eventually get this number back via legal means. So the number itself is something I own (at least in my country). Now if a site assumed this and p…
I think most people wouldn't risk that unless they are pretty messed up and an average legal system to deal with that unless it is pretty messed up. A past residence in a mediocre city in the US provides all the crack heads needed for such a torturous comedy.
Re: Passkeys will come at a cost
#130Earlier quoted context omitted.
i think they could be great for websites i don't really care about and already use weaker passwords. but for important sites where security matters? nope
Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. For "important sites where security matters" they are literally better in every way than a password, it doesn't matter how weak or strong. You can use a pure software solution, and soon probably even your existing password manager, to handle them. Again, you should think of them as replacing passw…
to follow the ssh analogy, you (should) only use SSH keys to gain access to a unprivileged user account at which point you elevate permissions via sudo and another factor (password/MFA) and really theres an argument to be made the unprivileged account should have MFA for login as well.
nobody puts their ssh public key in the root account of a server and pats them selves on the back that its secure so why would passkeys be any different for accounts you truly need to be secure?