Everything comes at a cost. If a company has breaching issues to leak passkeys they will have bigger troubles. As many suggest the main problem this attempt of FIDO alliance tries to solve is "Passwordless accounts". Trusting passwords to password managers is a problem at raise. I guess this solution would mitigate password mess for next 10 years. Then by moving forward I believe tech sector would also be able to satisfy security guru's too, hopefully.
Passkeys will come at a cost
41–50 of 600 posts
Re: Passkeys will come at a cost
#42Earlier quoted context omitted.
This doesn't really change much, though? My keys can only have 25 resident keys on them, and I also have more than 25 passwords stored in my password manager.
Password managers can store passkeys. I plan on storing passkeys in a password manager for most accounts, and then moving the few that matter to be resident keys. The theoretical advantage here is twofold: - Passwords are not guessable any longer - Password managers don't expose secret material in normal operation, because they sign requests with keys stored in TEEs (i.e. most modern devices have an embedded security…
and this is already messed up
password managers are a security liability which only exists because of how flawed password are
the original design of WebAuthn was all about taking both password and password manager out of the equation noticeable reducing the attack surface
instead how it now looks they will make password managers mandatory
until they make "blessed" storage mandatory basically now controlling the password manager and HSK industry (by deciding which ones work with their products) and then maybe kill the whole industry by only allowing the storage build into Android,iOs,Windows, etc.
And while stuff like this sound like a crazy conspiracy theory in the past the more I look into how passkeys developed in recent years (especially how they where represented) the more stuff like this sound quite viable. I mean big coperations which frequently have been found to abuse their power and try to get vendor locking wherever they can afford to, pushing a technology which looks like an improvement but can easily be abused to facilitate vendor lock-in and control over parts of an industry with the goal to abuse that... that isn't anymore conspiracy territory, that is what Microsoft has been doing in the past non stop and only stopped doing because it was no longer monetary beneficial for them. But in this case it would be. For them and Apple and Google and a few other huge companies.
Re: Passkeys will come at a cost
#43Why are organizations that aren't NIST trying to do anything fundamentally in cryptography?
Re: Passkeys will come at a cost
#44> rk=required why does that even exist, that shouldn't be an option this stuff is why I have been so worried/skeptical about Passkeys and the people related to it. They have the responsibility to design their protocols to not be a tool well suited for big coperations like Microsoft to seriously mess up security, compatibility and enact all kinds of "bad faith" market practices to kill competition. But instead again a…
> how attestation is handled (and can be trivially abused to kill companies)
What's this issue?
Re: Passkeys will come at a cost
#45> rk=required why does that even exist, that shouldn't be an option this stuff is why I have been so worried/skeptical about Passkeys and the people related to it. They have the responsibility to design their protocols to not be a tool well suited for big coperations like Microsoft to seriously mess up security, compatibility and enact all kinds of "bad faith" market practices to kill competition. But instead again a…
I think this is not as bad as attestation abuses.
My guess of what will happen is if a service sets `rk=required` and you are on a platform that doesn't want to (or can't) enable/support it, the process would always fail and you wouldn't even be able to register. Which seems like a shoot-yourself-in-the-foot kind of move if the goal is to onboard users and get more business...
Re: Passkeys will come at a cost
#46> rk=required why does that even exist, that shouldn't be an option this stuff is why I have been so worried/skeptical about Passkeys and the people related to it. They have the responsibility to design their protocols to not be a tool well suited for big coperations like Microsoft to seriously mess up security, compatibility and enact all kinds of "bad faith" market practices to kill competition. But instead again a…
> how attestation is handled (and can be trivially abused to kill companies) What's this issue?
In the limited set of attestors anyone would use/accept, no one would attest for you. It could target clients, services, or both.
Re: Passkeys will come at a cost
#47Is 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…
Yeah, this is basically my take. At this point, the idea everyone is converged on is that you have a locally encrypted secure "vault" of some kind, that you can trust, and you need to verify identity with that system, perhaps with a password and perhaps with a key. It is easier to have some trust that your password manager of choice is more secure, rather than having to assume that every service in existence you create an account for is secure (or unphishable.) So, by the time you use a passkey, you're quite often in a more secure context where you've already established that identity: to your operating system, to your password manager that owns your passkeys, etc.
It also seems likely that places that didn't support hardware keys now or recently probably wouldn't have supported them in the near future. But the ROI for a Passkey solution is likely much higher since the buy in (just some software support) is much easier for people to achieve. Of course, this is only true for websites mainly; a Passkey is basically the equivalent of "Standardized SSH keys" for a website.
I see hardware keys as more useful for second factors like actually unlocking your vault with your passkeys inside of it, which might also want a password. I suspect hardware keys still have a bit of life left in them.
The Passkey login flow is actually super, super nice now that I can use it on GitHub, Gmail, etc as a primary method.
Re: Passkeys will come at a cost
#48> rk=required why does that even exist, that shouldn't be an option this stuff is why I have been so worried/skeptical about Passkeys and the people related to it. They have the responsibility to design their protocols to not be a tool well suited for big coperations like Microsoft to seriously mess up security, compatibility and enact all kinds of "bad faith" market practices to kill competition. But instead again a…
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.
Re: Passkeys will come at a cost
#49I wonder if there could be a middle-ground software solution here? E.g. A piece of software (like a passkey manager or keychain service) that transparently simulates a resident key store by using an encrypted database that resolves services to credential IDs which are then forwarded and unlocked by a non-resident hardware key. One could then conceivably still sync the database around (using whatever services or metho…
We absolutely need to allow soft implementations to exist. The platform providers are already doing this. You should be able to use your password manager as a passkey manager. The RP shouldn't dictate any of this and the protocol should actively resist platforms locking people in to (their) blessed implementations.
Re: Passkeys will come at a cost
#50This raises a question for me. Why are hardware keys so limited in storage? How much extra would it cost to have a secure processor that could access a mass storage device also built in to the key. This mass storage device would of course be strongly encrypted by the secure processor with a key that would be erased at the same time everything else is erased.
Because secure tamper resistend storage is expensive. I would even go as far and say from a security POV the best security key is the key which has 0 storage. Because in my experience any protocol which injects and stores a secure token into a security key/enclave/whatever instead of deriving it from shared secrets etc. has serious flaws. Sometimes it's fundamentally security flaws (like TOTP). Sometimes it's complex…
Why not just store the master key in the tamper resistant storage and then have some regular old consumer grade storage to store all the derived keys?