4 ms·

> There is some new info with attestation, but other than it not being very widespread in practice, attestation keys are shared by a minimum of 100k devices. I

> There is some new info with attestation, but other than it not being very widespread in practice, attestation keys are shared by a minimum of 100k devices. I would question whether 100k devices is actually a big enough pool to protect privacy. Regardless, that is "an expansion of information", right? It's a pretty decent fingerprinting vector to start with when combined with other device information. > For instance, a company might mandate Webauthn with user verification for their internal systems, and they don't want an employee using a software based virtual authenticator that fakes UV and keeps key material in plain text At the point where a company is in that position, they should be supplying their own locked down devices. This is an extremely narrow use case, much more narrow than "I'd like to be able to use this on a Linux machine." And the companies that are in that position have much greater resources to solve that problem by issuing dedicated hardware that's locked down in general. It doesn't need to be part of the spec. In practice, where this will be used most often is with banking apps, which I've argued elsewhere are not nearly responsible enough to be trusted with this extra information and are usually startlingly insecure. They can get on board with basic security techniques that the rest of the industry has already implemented before we discuss giving them more control over my hardware. People keep billing this as a compromise, but it's not really. The attestation proponents are asking for a capability that doesn't exist, they're asking for a level of insight into my hardware that login methods have never provided before. The status quo is "no, of course you don't get that." If they want to change the status quo, asking for "compromise" isn't the way to do it, providing real proof that it's not going to be abused (which, I'll mention in a second I don't think is safe to assume) and that it'll provide meaningful security increases is where they should start. > I have not seen a single instance of attestation being used to gatekeep access to an otherwise public service, but I'd like to see some examples if there are any. Continuing from the above, I've seen both intent (https://developer.apple.com/forums/thread/708982 https://developer.apple.com/forums/thread/708982) and practice (https://arstechnica.com/civis/threads/passwordless-google-accounts-are-here%E2%80%94you-can-now-switch-to-passkey-only.1491776/#post-41840402 https://arstechnica.com/civis/threads/passwordless-google-ac...). Also attestation in the form of SafetyNet (https://developer.android.com/training/safetynet/attestation https://developer.android.com/training/safetynet/attestation) and the more recent Play Integrity API has been used for DRM in plenty of instances, even for very trivial services like Netflix. So it seems pretty reasonable to extrapolate out that services that already use attestation for DRM today are going to use it when it's available for WebAuthn. The default assumption ought to be that this is going to be abused. Every instance of attestation in the past has been abused. Why would we just assume that suddenly companies are going to be nice about it? > However that's the nature of standards and how they come about, there's multiple interests in the working groups. Right, and the way you force that collaboration is by refusing to go along with standards that are harmful. I'm not part of this standards process, it's their job to build a standard that appeals to me if they want me to use it. If they can't do that, then I won't use it. And I'll advise other people not to use it and I'll tell people (truthfully) that I believe it's a harmful standard. As users/stakeholders, we force collaboration by laying out very clearly where our limits are so we can focus on finding solutions that solve multiple use-cases. I'm willing to compromise on a lot of stuff. Not this. If the big stakeholders also aren't willing to compromise on it, then we'll stick with passwords. That's fine with me. The FIDO group doesn't have an inherent right to have people pay attention to them. It's their job to come up with a standard that's good enough that people want to pay attention to it. > All I'm saying is that there isn't an interoperable one currently, and that it's hard to establish interoperability across vendors and without an online sync fabric Some of us would argue that is also entirely the FIDO Alliance's problem to solve given that they exist to build the FIDO standard and are the most invested party in getting the rest of us to adopt their solution. Normally when people get together to build Open standards, they start with an Open implementation as a proof of concept. FIDO Alliance seems to be under the impression that it's everyone else's problem that nobody has built an Open implementation of their "Open" spec for them. That's just not how this should work. > and will have to be primarily OS-vendor-driven It's a good thing that all of those OS-vendors are part of the FIDO Alliance and are currently involved in a process that provides them with a great opportunity to sit down with each other and hash this out then. > What will most likely happen is that credentials generated by KeePaasXC and backed by hardware, will be able to be imported/exported in/out of devices in the same trust circle, using a KeePassXC sync fabric as the sync mechanism. That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys. What does an "Open" sync fabric that restricts keys to specific devices even look like? That's certainly not Open in the sense that I control the sync fabric or can compile/change it myself.

sebk 3y ago
100k devices is the minimum. Also I already agreed that this is an expansion of information, were it to be requested in practice and the user chose to provide it. And I don't believe the use case for attestation in enterprise settings is narrow. For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not. I can't comment on the intent link, as there's no information. But the "practice" link is simply incorrect. Google does in fact allow a Yubikey to be used as a passkey, I have one configured myself. It shows up as "FIDO2 security key". What I assume is happening in that link you sent is that the user's yubikey does not have a PIN set for the FIDO2 interface, which means that it can't provide user verification and therefore is not a passkey as far as Google is concerned. This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation. > it's their job to build a standard that appeals to me if they want me to use it They're appealing to OEMs, vendors and service providers as well. I also don't quite see how merely having attestation in the standard is harmful. RPs and users can chose not to require or provide it. If RPs decided they needed it for malicious purposes, would not having it in the standard suffice for them to be benign? > That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys. It would, because then the sync fabric is free to provide you with an exported version that's wrapped in a key of your choosing. It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.
- danShumway 3y ago
  > This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation. It seems like it does though... correct me if I'm wrong, but attestation is how Google knows that it's a Yubikey and that it doesn't have a PIN/biometrics set. And in practice, it's not allowed to be used to provide user verification; there's a restriction on functionality. Yes, you can use it as a Yubikey, but you can't use it for the new passkey system. > For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not. Good? Attestation should have an overhead. Getting rid of the overhead is exactly what I don't want. You can have attestation today through existing methods, and they're basically sufficient for enterprises that need them. It costs a bit of money, which is good because it'll force enterprises to think about it. And importantly, it doesn't really work for restricting consumer accounts, it's mostly useful for orgs where devices are controlled. Which is again, good, that's the best outcome. Enterprises can restrict their devices, but there are barriers to entry that prevent those restrictions from being applied to general consumers using their own devices. The other thing you can do if you don't want to go the hardware route is you can have a custom login app for your enterprise. You shouldn't, you should provide users with devices if you're going to restrict those devices -- but there's nothing stopping an org from having a custom authenticator that works outside of the standard. The only problem they'll have is if they want general users outside of the org to install that app just to log in. Which again, is very good. It's good that you can build a custom solution for within an enterprise, but that there are significant challenges in front of trying to force that solution on regular users. Heck, you can even use the Play Integrity API to help. Should the Play Integrity API exist? No, probably not. But it does and it's usable for dedicated authenticators, so we certainly don't need another solution on top of it. This is a rare use-case, and it's probably fine for the orgs that need it to use something other than passkeys. There's no real danger to them of lock-out, they're already doing this today so they can just keep doing what they're already doing. > I also don't quite see how merely having attestation in the standard is harmful. Because every single time that we've had attestation in the past -- literally every single time -- it's been used for DRM. Hopefully this conversation doesn't matter because Apple is just blocking attestation, but what do you see in the industry that makes you think this time would be different? Has something radically changed at Netflix over the past couple of years? When has attestation ever not been abused? Here's the Chromium team expressing similar fears: https://www.chromium.org/security-keys/ https://www.chromium.org/security-keys/ Are those fears unfounded? I don't generally assume that Google is going to be leading the charge on user freedom, and if even they are kind of creeped out about the potential here, then I trust that there's a real risk of abuse. > It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor. Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.

sebk 3y ago

100k devices is the minimum. Also I already agreed that this is an expansion of information, were it to be requested in practice and the user chose to provide it. And I don't believe the use case for attestation in enterprise settings is narrow. For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not. I can't comment on the intent link, as there's no information. But the "practice" link is simply incorrect. Google does in fact allow a Yubikey to be used as a passkey, I have one configured myself. It shows up as "FIDO2 security key". What I assume is happening in that link you sent is that the user's yubikey does not have a PIN set for the FIDO2 interface, which means that it can't provide user verification and therefore is not a passkey as far as Google is concerned. This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation. > it's their job to build a standard that appeals to me if they want me to use it They're appealing to OEMs, vendors and service providers as well. I also don't quite see how merely having attestation in the standard is harmful. RPs and users can chose not to require or provide it. If RPs decided they needed it for malicious purposes, would not having it in the standard suffice for them to be benign? > That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys. It would, because then the sync fabric is free to provide you with an exported version that's wrapped in a key of your choosing. It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.

danShumway 3y ago
> This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation. It seems like it does though... correct me if I'm wrong, but attestation is how Google knows that it's a Yubikey and that it doesn't have a PIN/biometrics set. And in practice, it's not allowed to be used to provide user verification; there's a restriction on functionality. Yes, you can use it as a Yubikey, but you can't use it for the new passkey system. > For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not. Good? Attestation should have an overhead. Getting rid of the overhead is exactly what I don't want. You can have attestation today through existing methods, and they're basically sufficient for enterprises that need them. It costs a bit of money, which is good because it'll force enterprises to think about it. And importantly, it doesn't really work for restricting consumer accounts, it's mostly useful for orgs where devices are controlled. Which is again, good, that's the best outcome. Enterprises can restrict their devices, but there are barriers to entry that prevent those restrictions from being applied to general consumers using their own devices. The other thing you can do if you don't want to go the hardware route is you can have a custom login app for your enterprise. You shouldn't, you should provide users with devices if you're going to restrict those devices -- but there's nothing stopping an org from having a custom authenticator that works outside of the standard. The only problem they'll have is if they want general users outside of the org to install that app just to log in. Which again, is very good. It's good that you can build a custom solution for within an enterprise, but that there are significant challenges in front of trying to force that solution on regular users. Heck, you can even use the Play Integrity API to help. Should the Play Integrity API exist? No, probably not. But it does and it's usable for dedicated authenticators, so we certainly don't need another solution on top of it. This is a rare use-case, and it's probably fine for the orgs that need it to use something other than passkeys. There's no real danger to them of lock-out, they're already doing this today so they can just keep doing what they're already doing. > I also don't quite see how merely having attestation in the standard is harmful. Because every single time that we've had attestation in the past -- literally every single time -- it's been used for DRM. Hopefully this conversation doesn't matter because Apple is just blocking attestation, but what do you see in the industry that makes you think this time would be different? Has something radically changed at Netflix over the past couple of years? When has attestation ever not been abused? Here's the Chromium team expressing similar fears: https://www.chromium.org/security-keys/ https://www.chromium.org/security-keys/ Are those fears unfounded? I don't generally assume that Google is going to be leading the charge on user freedom, and if even they are kind of creeped out about the potential here, then I trust that there's a real risk of abuse. > It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor. Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.