771–780 of 789 posts
Earlier quoted context omitted.
The services that I use passkeys for (MS, AWS) do. I have separate passkeys for 2 browsers and on my phone.
The trouble is if it is on the service to do the support, they can revoke support at any time. They could use start tightening the screws on device attestation tomorrow for business reasons and drop support for your browser or phone.
The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials bu…
As I understand it the workflow would be: * get a new passkey * enroll the new passkey with all existing services * unenroll the old passkey with all existing services
That is certainly onerous for the "can my mom do this?" test. Like, I'm not even sure I want to deal with this myself and I have a Solo key (in a box).
Further, seems any service I'd want to protect with a passkey, is also a service that would be very difficult to lose access to, should I lose the passkey (or it fails). Therefore I need to enroll two passkeys with each service, to have one as a backup.
Uhh, OK. So now if I were to change passkey vendors/services - it's enroll two replacements, unenroll two? I haven't ever done this so maybe it's not as onerous as it sounds?
Earlier quoted context omitted.
I’m a security engineer, I’m pretty fluent on the topic. And phishing comes in beyond the methods you describe -> malicious attachments downloaded, etc etc.
I do agree but in this discussion we're talking about the general problem of logging in to a website. That's the case where phishing is the most devastating. Solving that problem is a huge step in making people's online lives more secure. Just because we didn't solve all problems, doesn't mean we shouldn't solve what we can solve. If you're a security engineer, it's your job to promote ways for people to be more secu…
> Finally, a lot of people in this thread are missing that passkeys prevent phishing, and are basically the only way we know to prevent phishing. And phishing is extremely high in the ranking of security issues we currently have to try to solve.
And I can point out several ways phishing is currently prevented without passkeys. And several ways it occurs without logins, such that it’ll still be around after passkeys. And phishing is difficult, but per defense in depth concepts, it is not the mission critical focus you label it as.
So to turn it back around, I don’t think you understand phishing threat vectors well haha.
Earlier quoted context omitted.
I've always wanted a decentralized solution that lets me trust my friends instead.
You can use a threshold secret sharing scheme to distribute your keys amongst your friends (and amongst companies). This way you don't need to trust any single one of your friends to be 100% honest nor 100% available.
Earlier quoted context omitted.
That's a fundamental problem with cryptographic security: you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) but you cannot trust yourself doing that either, because you can, and will, make mistakes.
> [...] you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) [...] Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contr…
It is, because no company is ever going to give you the convenience you want at their own expense ;)
Earlier quoted context omitted.
That's a fundamental problem with cryptographic security: you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) but you cannot trust yourself doing that either, because you can, and will, make mistakes.
> [...] you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) [...] Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contr…
Would you really trust your lawyer with your bitcoin seed? If they stole everything from you, how would you even prove it?
Earlier quoted context omitted.
I've always wanted a decentralized solution that lets me trust my friends instead.
You can use a threshold secret sharing scheme to distribute your keys amongst your friends (and amongst companies). This way you don't need to trust any single one of your friends to be 100% honest nor 100% available.
you could rsync files before you could Dropbox too, but there was still a need for a Dropbox.
Earlier quoted context omitted.
> [...] you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) [...] Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contr…
> Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. Would you really trust your lawyer with your bitcoin seed? If they stole everything from you, how would you even prove it?
But the whole thing depends on how much you own in bitcoin.
If it's a whole lot, check how other people in more traditional domains are dealing with their lawyers or notaries handling these sums. (For one, it's a bit easier with bitcoin, because you don't need to tell your lawyer or notary what you are giving them. And you can encrypt the private key data with something derived from an easy to remember password. It doesn't need to be 100% cryptograhpically secure, it just needs to lower the temptation for your lawyer.)
Btw, I think the bigger problem in practice wouldn't be your lawyer stealing from you, but your lawyer somehow losing your data.
Earlier quoted context omitted.
> [...] you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) [...] Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contr…
> However, the way to get convenience is not via regulation. It is, because no company is ever going to give you the convenience you want at their own expense ;)
Earlier quoted context omitted.
> However, the way to get convenience is not via regulation. It is, because no company is ever going to give you the convenience you want at their own expense ;)
Well, obviously the customer only gets the convenience they are willing to pay for. Competition should help keep those costs down.