Webauthn is a beauty. A relatively easy to implement way to allow users a secure 2-Factor experience. (easy enough that I could re-create my Webauthn Sandbox after losing it in my migration, FUN!
Well, sarcasm aside, there are a few things I dont like with it, and one of them is the default state of the userVerification Flag.
For anyone who isnt all-aware in Webauthn and stuff: more modern Fido2 devices are generally capable of a feature called userVerification, in other words unlike the relatively simple U2F devices, which only verify that A user is present (e.g. by using a little button or a touchable area which has to be interacted with in the real world) to make sure that malware cant just trigger a connected U2F device and go ham on the accounts it found, user Verification goes another step by actually verifying (hence the name) whether you are an allowed user of this device.
This allows for fun stuff like passwordless logins, as the webauthn can singlehandedly handle 2 factors, one being obviously possession, aka the device, and the other being either usually knowledge (aka a "PIN" which by standards is in fact also capable of being a password or passphrase, but marketing can't really use "password" when "passwordless" is thrown around, lol) or more rarely biometrics like your fingerprint.
Webauthn allows for 3 states of UV:
- discouraged
- basically tell the device not to use UV, it still can, if it really wants to, but generally most devices wont.
- required
- basically what it says. no UV equals YOU SHALL NOT PASS, while dumb clients not capable of UV can try to push an auth through without UV, required usually means that clients deny devices incapable of UV (like classic U2F sticks) or if a device can do UV but hasnt set it up, helps the user in setting it up.
also a big hint that the server will be making sure that UV is actually used. - preferred
- the sad default state of UV when the parameter is not used. basically it means that if an authenticator is
1) capable of UV
2) has UV set up (technically this is not required but last time I checked most clients [save for W10] refrained from asking if it isnt set up)
it will use UV, otherwise it wont. it can be used for some hybrid approaches where devices with UV can use it but U2F devices wont explicitly be blocked.
The Problem
as a server doesnt really have psychic powers it cannot predict whether any given device is capable of doing UV (and even if, as said many client dont just force UV if it isnt set up) so in case preferred is used I doubt that many servers actually verify whether UV is actually used.
This leads to a potential security issue where if the key can be used to bypass passwords or be used in other ways alone without the server actually verifying that UV is used (potentially this can even happen in required, but ideally most libraries are aware of a required request so this wouldnt happen as often), an attacker with the key in hand could use any computer he wants, go to the log in, and swap out the "required" for a "discouraged" on the client side, and the device will let him through with the push of a button and no UV. This would obviously suck.
And the reason I know that, I've done this at least on 3 sites (was my own account, so no harm done), although only 2 allowed using WebAuthn as a substitute for passwords. (although granted unlike on my sandbox, many sites request the challenge on the fly and minified JS is a pain to navigate to check where/when you can alter it using breakpoints and all)
The Solution
(or at least one of the possibilities)
an Idea I had for a while was to keep track of each credential going around and have an internal UV flag which starts being false, (or 0 or whatever indicating that it isnt used UV in the past) and if any of those EVER spawn a request with UV (of which a flag exists to let the server know), set that internal UV flag to true (or 1 or whatever, you get the idea) and in the future, if a credential with an internal true UV flag is logging in again, turn on the server-side UV validation, this a thief cannot just spawn a discouraged UV prompt and abuse it.
Also there is no scenario a UV-enabled device can have UV removed while the credentials stay intact, so there's no harm in doing this as a only activate style of function since you can only remove UV with a reset which removes the credentials.
Conclusion
NEVER trust user data