I ended up basically following vascocb’s solution. We have now disabled WebAuthn as a second factor and continue to require U2F - we have told our users that “Going forward, you’ll have to use Firefox to connect”.
I did have a dialog with Yubikey support. After a long back and forth, my query eventually got escalated to the right person, and they said, “You’re basically out of luck unless you have control over the server.” That was sort of good news - since our Nextcloud installation is self-hosted, that did offer some hope.
But the answer they gave was over my head, sounds like it would require changes to the WebAuthn code in Nextcloud. If anyone can turn this into a set of instructions for how to modify an installation, that would be wonderful.
Thanks for your patience. Unfortunately, on our end, there isn’t much we can do at this point.
The service provider could force this type of requirement but customers using the service would have no say in this. From the service provider side, you could check AAGUID or request a roaming authenticator through the “Attachment” during create credential (Web Authentication: An API for accessing Public Key Credentials - Level 3), or you can also do a full attestation check and limit to cross-platform authenticators only (similar to the AAGUID restriction, like what Vanguard does to selectively only allow certain models of YubiKeys). The service provider could play around with the “Attachment” parameter on the Azure WebAuthn test site https://webauthntest.azurewebsites.net/ for an example. From the discussions linked, it doesn’t look like the service provider sees a tangible benefit to implementing this functionality so it doesn’t sound like they’d be interested in exploring this.
On instances without CLI access you’ll have to remove your U2F device manually in the webuUI before you disable the U2F app and then register the device again as WebAuthn device with the WebAuthn app.
And if you are using a hosted Nextcloud, you obviously have to use the options offered by your provider. Ideally, the providers would do the migartion for their customers, so that their users can simply continue to use their U2F keys as if nothing had happened.
Thanks for your reply. Yes, the things you say are true, and our U2F devices work under WebAuthn.
Our issue is that, once we do that, Windows users are able to bypass the requirement to use our provided U2F Yubikeys.
In more detail, the issue (see the original post at the top of this thread) is that when we migrate to Two-Factor WebAuthn, users are able to log in using their Windows Hello credentials, bypassing the Yubikey which we want to require.
The answer to your question is “mostly no”. In most cases, users are using a PIN with Windows Hello.
So they simply type their PIN (or use their face or fingerprint or whatever they’ve configured) and they’re in to our server.
That’s good security but not great - the PIN is basically just a second password. We want to require that the users have the physical key.
We have been advised to require users to use their Yubikey as their Windows Hello authentication option, but we do not have that level of admin control for machines that are outside of our organization (such as for vendors that access our CAD files).
Yeah that’s what I would have suggested too. But oviously that’s only possible if you can restrict access to locked down corparate devices. If your Nextcloud is publicly available and they can login with whatever devices they want and from wherever they want, you can’t do that.
Well if Windows Hello in itself is a Webauthn device there is not much you can do. In that case they can add it to their Nextcloud accounts just like they could add any hardware Webauthn device. Maybe you could open a feature request in the GitHub repo of the twofactor_webauthn app for implementing a restriction of how many devices a user can add to his account or even for a limitation to specific devices. But I don’t know if the latter is even possible with the FIDO2/Webauthn standard.
The reply I got from Yubikey support (pasted into my message from last night) makes it sound like it is possible to implement restrictions that would accomplish this. I will be curious to see what the development team has to say.
this is a really interessting post and I support the possibility for making restrictions in kind of the use case.
Now the long thinking if I should buy nitrokeys for my family (like fun present for more security) is rendered useless since they all will use Windows.
@florom@stratege1401 Why are the keys useless.? You could use them with Windows Hello. If you use the keys for Windows Hello instead of fingerprint or face recognition, it would not be inherently less secure than using it directly. And in addition to that you can still add the key directly to your Nextcloud, in case you want to log in from another PC.
@stratege1401 37000€ for keys is 600-1500 keys, depending on which keys the customer bought. This means the client mangages at least 300 - 700 accounts, asuming he bought two keys per employee. Maybe your client should think about a support contract with the Nextcloud GmbH. Also, why wouldn’t the customer test this extensively before spending 37’000 Euros?
@ChristophWurst useless because windows-hello bypass them with pin code !
I have set-up my Ykey in NC23. When log-in with w10/w11, the physical hardware Ykey is simply ignore, and i have just to type in the WH pin.
@florom Having such keys is a good security education for your kids, but i am more focus on the pro side.
…and 37000 euros is “nothing” compare to having lost 4 years of archives and his full network/desktop and Windows based POS to a ransomware 9 month ago. This is why this company step-up server-security access with hardware keys, pfsense everywhere, white towers archives every 15 days… Just missing Tom Cruise playing spider-hacking
That’s because Windows Hello is the security key device in that case. But if you enforce Windows Login with hw key only, this would not be inherently less secure than using the key directly with Nextcloud.
Yes you are right. It seems indeed only possible with AzureAD. But with a local AD there you could use SmartCard login, maybe even with the already existing HW keys. If this is also not feasible, there is probably nothing left except to disable Windows Hello and enforce very strong passwords. If there is no AD at all, there is not much you can do. Respectively you would have to implement another SSO solution that works with Nextcloud, that suports these features. But I think this is out of scope of what a community forum can help you with.