751–760 of 816 posts
Earlier quoted context omitted.
This would be an argument to support keeping the passwords, instead of pushing for not adding passkeys in the first place. And I would agree with that argument.
Which is exactly what I said.
Earlier quoted context omitted.
>Why would BigTech care about the dozens of users using an open source password manager? Because big tech loves control. Just because you can't see the angle yet, it doesn't mean there isn't one now, or won't be one later. It has been shown time and time again that they will take all the freedom away from you that they can.
What instance have you seen where BigTech opted for control with no monetary incentive?
Even if there wasn't already an example, it's easy to turn control into a revenue stream at a later time.
Earlier quoted context omitted.
That's fine, but Chrome has 67% market share, and the majority of people will pick the default option for passkeys if prompted. For passkeys to replace passwords it's got to be seamless and easily recoverable without compromising security.
So we need to make a new open standard, and then somehow prevent Google from implementing it? Too badly they implemented TOTP too. I’m not sure what you’re proposing here.
Earlier quoted context omitted.
The Fido2 folks really really want things to be so secure and centralized, with so little user freedom, and they want to use attestation to do it. Here's a Fido2 member (Okta) employee saying "If keepass allows users to back up passkeys to paper, I think we'll have to allow providers to block keepass via attestation." https://github.com/keepassxreboot/keepassxc/issues/10407#iss... All because passkeys backup is deeme…
Hi, since you mentioned me, that's not what was said and putting it in quotes as if I did is really inappropriate. I'll post the same response I replied to other on a different thread: Wild that you (and a few others) continue to make these accusations about me in these comments (and in other venues). 1) I've been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the cre…
>which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
This is exactly why we need truly open standards, so people who believe they are acting for the greater good can't close their grubby hands over the ecosystem.
Earlier quoted context omitted.
Ah, and even if you can turn it off as the administrator, you still need to include the attestation, it's just not checked. Gotta love Microsoft...
Yeah Microsoft is so annoying. It's also kicking me out every day now (with this passive aggressive "hang on while we're signing you out" message). On M365 business with Firefox on Linux with adblocker. I hate using their stuff so much.
Earlier quoted context omitted.
> The issue at hand is the requirement for client attestation while using passkeys. There is no attestation in the consumer synced passkey ecosystem. Period.
Can you say "There will be no attestation in the consumer synced passkey ecosystem. Period."? That seems to be the concern, not what exists today.
How do you expect a single person to be able to make an authoritative statement like that?
Earlier quoted context omitted.
> Passkeys will be the way to go if we get them to remove the "attestation object" field from the protocol. I don't think you understand the protocol. The attestation object does not mean there is an authenticator attestation. There is no authenticator / credential manager attestation in the consumer synced passkey ecosystem. Period.
Is this not the protocol we're talking about? https://w3c.github.io/webauthn/#sctn-attestation It seems pretty clear that "where possible" parties besides the user are provided with information about the user (ostensibly about their device, but who knows what implementers will use this channel for)... so they can make a trust decision. It's going to end up being a root-of-trust play, and those create high value targe…
Folks seem to be hung up on the term "attestation" being in the response of a create call. If you look inside that object, there is another carve out for optional authenticator attestation, which is not used for consumer use cases.
I will keep repeating what I've said in the other comments. There is no credential manager attestation in the consumer synced passkey ecosystem. Period.
Earlier quoted context omitted.
No, that's not what I meant. There are cases where bitwarden doesn't work but chrome for example does. Easy to Google up. For passwords however, I never heard of a case where a website only accepts passwords from a specific password manager - and how could they even do that right?
I don't think your reasoning holds. You say "I know situations where one passkey client works with some websites and not others, but I don't know situations where a website works with some clients and not others". If the website accepts a password, then it can't prevent you from using the password manager you want. But if the website accepts FIDO2 passkeys, it's the same thing, isn't it?
For example: https://www.w3.org/TR/webauthn-2/#dictdef-authenticatorselec...
> If the website accepts a password, then it can't prevent you from using the password manager you want. But if the website accepts FIDO2 passkeys, it's the same thing, isn't it?
Unfortunately not...
Earlier quoted context omitted.
You should really re-read the entire discussion. It wasn't about passkeys being able to be exported. It was specifically about clear text export. > The fact that that possibility exists, The possibility does not exist in the consumer synced passkey ecosystem. The post is from a year and a half ago.
A year and a half ago doesn't really matter; that this was ever even a concern from the industry, something that the industry could make happen at all , or even just was thinking about doing at some point in the past, poisons the entire effort. In a world where password+totp already exists and requires almost no hoops, no dependencies and is incredibly secure vs basic password flows, it's no wonder that folks remembe…
This is already possible today. And since it's a completely open ecosystem, you can even build your own credential manager if you choose!
Earlier quoted context omitted.
No need to write like that. I know, understand and use passkeys for quite a while now. I don't love them. I don't love passwords either. But while I don't fear passwords, I fear passkeys. The reason is that it makes the tech even more intransparent. My password manager stops working, completely dies or I can't use it anymore for other reason? No problem, I can fallback to a paper list of passwords if I really have to…
Why not keeping passwords AND passkeys? Most of the time I want to use passkeys for different reasons, but if I lose my passkeys I can go back to my printed list of passwords.