Quick Tip: Enable Touch ID for Sudo (2020)
sixcolors.com
sixcolors.com
From that day on, I’ve never used biometrics system used as authentication.
With a increasing use of biometrics on phones, should I think differently in 2022?
Blanket statements like that are never true. It's usually about threat modelling, i.e. build your defences according to who might want to access your stuff and what are their capabilities.
Why? Because you will have to target a balance between convenience and security. If you don't use biometrics you might end up to have "QWERT1234" as a password to compensate for the loss of convenience.
Even if you have a strong password and you are ready to give up some convenience, you also risk false sense of security. Your password might be strong but there are many ways to extract passwords. As a result you might want to switch to certificates - which are convenient and secure to use but now you are responsible for it's upkeep or you might loss access to the systems when you loose your certificate. Also, you might think that certs are super secure but just yesterday it was revealed that there's a way to extract certificates from Intel and AMD machines through an attack called hertzbleed.
Hmm, maybe you need something even more secure. How about air gap? If your device doesn't have a network connection, you must be %100 protected, right? Wrong, there are multiple demonstrations about extracting information through sound, magnetic forces and light.
%100 security is impossible, better choose the right kind for you.
Except in cases where they are, like this one.
Just cause you want convenience doesn't change the fact your fingerprints aren't good passwords.
For the vast majority of users, the threat model looks like "I don't want that creep who just stole my purse to be able to log in to my iPhone", not "I am guarding state secrets and a potential target of Kremlin agents".
Passwords get stolen and used all the time, but I have yet to hear stories of everyday thieves breaking into iPhones with stolen fingerprints.
Checking for a fingerprint match essentially means that the administrator of the device is present and authorises the action, assuming that their fingerprints are not copied by an attacker and they are not physically forced to comply with an attacker.
Checking for a password match essentially means that the administrator of the device might or might not be present but authorises the action, assuming that the password was not obtained through a post-it, coercion, phishing, guessing or any other password extraction method and they are not physically forced to comply with an attacker.
If a credential cannot be changed then its confidence as an identifier is significantly reduced.
Fingerprints are useful in cases where the effort of copying a fingerprint is greater than the value of the target. They're great for almost everyone with low value systems, like your average easily pickable front door lock. They're good for keeping honest people honest.
Fingerprints are a problem for high value systems.
Fingerprints are also certainly a shared secret identifier, and we typically call shared secret identifiers "passwords" even when they aren't literally a typed word.
Namely: if you are forced to comply, it doesn't matter in either case.
If your password can be "obtained through a post-it, [...] phishing, guessing" etc. (key logger), then you might be better off with biometric authentication.
If your fingerprint can easily be extracted (and the sensor be fooled by it easily), then you might be better off sticking with the password.
Those clarifications give you a good way to think about the tradeoffs.
From elsewhere on this thread: https://www.schneier.com/blog/archives/2015/08/mickens_on_se...
No it means only that the fingerprints are present. Your finger can be cut or you might be forced to unlock the device.
The gist is, a password and a fingerprint are not the same thing. Fingerprint is not a weaker password or anything like that, they have different properties and as a result they have different pros and cons. For example, no one can copy your fingerprint by looking over your shoulder - unlike a password.
How common is this scenario? I imagine it is a lot less common than passwords getting stolen or cracked.
Contrary to how some people here are acting, most people aren't targets of foreign foreign espionage.
You can also be forced to reveal or enter the password.
I remember reading about one school which implemented "live finger" readers.
How did kids hack it?
Polymer clay and a gummy bear.
Put your finger on clay and wait for it to dry. You will have your permanent mirrored fingerprint.
When required fingerprint press gummy bear against clay and then against the reader. As gummy bear holds charge, can even be cut thin etc. there is little chance to detect that it is not a real skin.
The biometric system (sensor + algorithm) used by Apple, as well as other competitive biometric vendors, detect blood flow, pulse in the finger. This is done as a mitigation against fake fingers as well as the (always presented) gory "cut off the finger" attack scenario.
A gummy bear may be lifelike, but normally lacks a beating heart and circulatory system.
“Normally”?
> assuming that the password was not obtained through a post-it, coercion, phishing, guessing or any other password extraction method
If we're happy to make such assumptions, then we can remove security entirely: just assume that actions are authorised!
Less tongue-in-cheek: we should try to avoid making such assumptions in the first place. For example, saying "this action was authorised by the presence of an administrator" is setting us up for failure: that's a hard thing to ensure, and also relies on fuzzy concepts like "presence".
Instead, there's nothing wrong with saying "this action was authorised by the fingerprint scanner matching the admin account": it's a more accurate statement, it doesn't hide any vulnerabilities, and it doesn't rely on any fuzzy concepts; e.g. we're not talking about humans, fingers, etc. we're only talking about accounts and hardware devices.
>"this action was authorised by the fingerprint scanner matching the admin account"
Okay, so? It's the same thing as "this action was authorised by a keyboard entry sequence matching the admin account prerecorded sequence".
How is this any more useful? If anything, you better know and understand your assumptions and introduce other measures if you suspect that some of those assumptions are no longer true.
"keyboard entry sequence" is just a long-winded way of saying "password"; there's nothing wrong abbreviating.
However, even this facetious example was useful, since it's exposed a security problem: you're storing passwords ("prerecorded [keyboard entry] sequence"). You should be storing password hashes instead (using a slow hash function).
:)
The storing password part is relevant for extraction of password from an already compromised system and fingerprints can be hashed just as well(and on Apple's implementation, they are). It's just irrelevant implementation detail that doesn't make difference for the security of the system in question.
In fact, fingerprints are actually more secure because you don't have rainbow tables for hashed fingerprints but you have it for passwords.
You seem to be missing my point: that it's better to think about security issues in terms of the components and actions that actually exist in the implementation (e.g. "when the given password agrees with the stored hash, then XYZ"), rather than the real-world concepts they're crudely trying to approximate (e.g. "when the administrator is present, then XYZ").
If you want to use fingerprint scanners as part of a security system, that's fine; I really don't care. What I do care about is that "fingerprint scanner says yes" does not imply "Alice is currently holding her thumb against the phone screen", or other such real-world scenarios.
Alice holding her thumb against the screen might cause the fingerprint scanner to say yes; and it's perfectly fine to make that assumption when designing a UI (where failure is mostly an irritation). Yet security design should not make that assumption, since it may hide all sorts of vulnerabilities.
As an analogy: a "Keep off the grass" sign is not the same as there being nobody on the grass. It's good enough for something inconsequential, like turning on a sprinkler system (if you get wet, you should've followed the sign; similar to a UI breaking if the user doesn't use their phone in standard ways); yet it's not enough to, say, store our valuables on the grass, in the hope that nobody can get to them.
Which is why GP carefully qualified his statement that "administrator is present" with the appropriate assumptions.
You're technically right that fingerprints aren't "good passwords", in fact they are not even passwords at all. But for most people, most of the time, they cover most of the same use cases at a better convenience price point.
For general use (i.e. unless you work in security or journalism) that's what matters.
Mark Twain once said "All generalizations are false, including this one."
Eh, they're all pretty bogus though, with ridiculously contrived scenarios I mostly can't imagine happening in the real world.
USB sticks and the like pose a more realistic danger to air gapped machines, but they're also easy to avoid if you're conscientious.
Air gaps are really, really good and we should be using them more.
It should be obvious to anyone who has used a QR code that it's possible to transfer data over other channels, but it's pretty obvious it's happening.
fascinated by this. where could one learn more?
Otherwise for most people it's probably better than easy to guess passwords or not using a password at all. Especially if it's annoying to type every time (iPhone passkey). Many people didn't use a passkey before, since there's TouchID or FaceID everyone uses something and it's better against a random thief than nothing at all.
What the attacker was able to do was take a high resolution photo of the defence ministers thumb and then produce a "fingerprint" that they could use to register as a "fingerprint" on their own phone and then unlock that phone with the "fingerprint".
It could be nothing like the defence ministers actual fingerprint but just look enough like any real fingerprint to register with a fingerprint scanner on a phone.
The most sophistication would probably be something like a PPG (optical reflection changes due to blood flow in certain bands). If the fake is thin enough the PPG would likely just shine through it. Skin resistance/humidity can be easily faked as well.
I mean... Wouldn't there be a bunch of my fingerprints on the phone itself?
And if my bag gets stolen along with the laptop and possibly the phone, wouldn't there be fingerprints on pencils, water bottle and the phone charger?
https://hackaday.com/2015/11/10/your-unhashable-fingerprints...
>My point is that security people need to get their priorities straight. The “threat model” section of a security paper resembles the script for a telenovela that was written by a paranoid schizophrenic: there are elaborate narratives and grand conspiracy theories, and there are heroes and villains with fantastic (yet oddly constrained) powers that necessitate a grinding battle of emotional and technical attrition. In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, they’re going to hold a press conference and say “It wasn’t us” as they wear t-shirts that say “IT WAS DEFINITELY US,” and then they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them. In summary, https:// and two dollars will get you a bus ticket to nowhere. Also, SANTA CLAUS ISN’T REAL. When it rains, it pours.
https://www.schneier.com/blog/archives/2015/08/mickens_on_se...
Child support here, while I agree it should be being paid but people can run into hard times, is sort of like this but more ridiculous. If you are.behind on child support, they jail you indefinitely until you can pay it.... But you are in jail indefinitely and likely have lost your job if you had one. So....
IMO is clearly a violation of the 5th amendment, but the Bill of Rights in the US has been soo watered down at this point they may not even be considered rights any more....
I would say 5th because divulging the contents of ones mind is testimony which one should not be compelled to do, the 5th profits you from being a witness against yourself, reveling a password is being a witness against yourself
For comparison, Windows default configuration is a yes/no dialog (UAC).
If an attacker had unelevated access they probably stand a pretty good chance of getting elevated access on a workstation (replacing files, putting a shim in front of sudo, stealing SSH keys, access tokens, cookies, etc) anyway (if the regular user has those privileges)
If you're at all concerned about being targeted, this is a very valid concern. On the other hand, I think using fingerprints/biometrics is "good enough" to prevent non-targeted attacks (theft, lost device) from retrieving sensitive info, and is far better than no password or a short numeric PIN.
Obviously, using a rotating alpha-numeric-symbol password is more secure, but unless you only very sporadically use your mobile device, is pretty inconvenient.
(of course, it'd probably be best to use MFA here and have a PIN code along with biometrics, but I'm not aware of any consumer devices like that)
The biometric information never leaves the device.
While you can't change your fingerprint, you can change which token is registered with the end application, so that concern is mitigated.
The secure enclave holds biometrics, these are used to generate ordinary key pairs which are revokable.
If you have a device like this, try it! Register a finger, then un-register the finger: congrats, you've changed your fingerprint.
They can’t see it if you use your fingerprint or FaceID.
That’s actually a security improvement for some threat models.
Just a thought :)
touchid is actually better than a password here, as it prevents malware from using sudo without physical confirmation from you.
I can't imagine a circumstance where I would not voluntarily give somebody a password if they were in a position to physically force me to provide biometrics
To use touchid/faceid as an example:
- it requires that the password was recently entered
- it's not the password, but a means of accessing a temporary token
- that token is easily purged from memory by triggering SOS or failing touchid/faceid repeatedly
- a range of conditions will also automatically purge the token, such as usage that doesn't match the user's behaviour, unusual movement such as scuffles, certain combinations of location/time/movement, and of course not being used for several hours (this also seems to vary based on certain conditions.)
In this sense a biometric read can provide a useful level of security for most scenarios and definitely better than entering a 4-digit pin repeatedly, and infinitely better than gestural passwords which are comically easy to guess.
For secure applications it's not useful, nor is a 4 or 6 digit pin, but such implementations also engage a range of security enhancements such as internet/voip via an encrypted VPN, locked down device profiles, limited access to networks and so-on. Sometimes the discussion about biometric data use in authentication tends to over-borrow from this level of security need.
So you're making a tradeoff and with phones it works out slightly better if you unlock with biometrics most of the time; but you should know the five clicks method for disabling the biometric unlock temporarily.
Yes, like any session-based access, it is a compromise between convenience and security. For frequent usage like phone access, I feel like it is a reasonable compromise.
When you reboot a Mac you have to type in the password to login still.
The easiest way to authenticate to a Mac is actually your Apple Watch.
I think this is a good compromise - at worst if I were to lose the device and someone were to cut off my finger at best it would only work for a few days. But that scenario seems quite rare.
I’ve never understood this argument.
I could just as easily say “someone else can use your password, but they cannot use your fingerprint”.
I think it's silly to have a security measure that can be passed while you're not even conscious
The use of a password only known to you cannot be physically taken from you as your mind controls that authentication mechanism.
And it's not just people standing behind you, it can also be the security camera in that coffee shop. It can be someone looking through your office window with a telescope from the next building over.
Same goes for your phone. There are ample opportunities to see someone type in their PIN code to unlock their phone, especially if you use it for payments which are generally done in public places. No need for violence, no need to draw attention to yourself, just watch them enter their PIN and then pickpocket the phone afterwards.
It all depends on the exact threat scenario, but biometric authentication can be preferable to passwords when used in public places.
Maybe a bit weird if you start doing that in trains and coffee shops though.
On the other hand, in a few countries police can force you to use biometric authentication, but not to release your passwords. In the end, you really need to think about your threat scenario and act accordingly.
If people home-jack me at night, my 24/7 alarm system/monitoring company calls me in the following 45 seconds at most and asks me for my password. If I say "monkey" it means everything is fine, if I say "beetle" it means I'm under duress. When I give either password, the company answers: "OK, sleep well, all is good". But in the later case they call the police and tell them a home-jacking is ongoing. (obviously my two words aren't "monkey" and "beetle", this is just an example).
(as a bonus my alarm system has an anti-jamming system and communicates using several channels)
Banking apps should be the same: they should have one PIN to do regular business and another one where everything looks legit, but you'd only be making fake wire transfer or only allowed tiny withdrawals, showing a small balance.
Some companies (for example my alarm system) and websites (very few but I've seen some) and some HSM (for example cryptocurrencies hardware wallets can decode using two keys, one of them showing a smaller balance than the real one) have seen the light and have such a feature.
I do believe we're still in the stone age when it comes to security. Most people like to post that disastrous XKCD and think the bad guys have forever won thanks to their $5 wrench. I'd hazard a guess: people thinking with that victim mentality aren't the ones coming up with better security systems.
Who show up three hours later and shoot your dog.
Plus you can have multiple keys. Plus you can use them for gpg and ssh. Plus you can back them up. Plus you can print them on paper.
I don't know if you can do the same (forwarding over SSH) with Fido2 but I still use traditional SSH keys anyway (stored on the yubi with OpenPGP). And the pam_ssh_agent_auth module.
I'll only consider switching to Fido once everything supports it (eg my iLO devices too) and it can offer at least the same features like forwarding. For now the former is very far from being realised anyway.
https://wiki.archlinux.org/title/Fprint#Login_configuration
This also helps if you want to use the touch / Yubikey / Whatever to unlock the machine, but you need to type in the password when opening the session so that all the wallets unlock, too.
I wrote a small tool to mitigate this by configuring PAM on system startup: https://github.com/YuriyGuts/persistent-touch-id-sudo
System updates are not frequent. I prefer doing it manually, and just automating a notification that it needs to be redone. I added this to my `.bashrc`:
if ! grep -q "pam_tid.so" /etc/pam.d/sudo ; then
echo "touch ID no longer enabled for sudo. Insert the following line as line 2 in /etc/pam.d/sudo:"
echo " auth sufficient pam_tid.so # enables touch id auth for sudo"
fiI think you overstate this tradeoff in this case since there is a win-win solution.
Patches are harder to use than plain files, since you need to maintain a source and a destination to diff against, and applying them can occasionally fail, requiring the user to resolve.
I think overriding configuration in /etc is one of those cases where the user's intent is very clearly "I know what I'm doing, please get out of my way", and other unices are built to respect that. macOS assumes it's the other way around, and ends up doing crazy stuff like overwriting "PasswordAuthentication" to "yes" in sshd_config on every upgrade.
Running rsync to just overwrite the configuration is probably too simplistic. Maybe the tool could detect that a file was overwritten by an upgrade, and make a backup (sshd_config.upgrade, and so on).
I think I'm just going to write it now.
That's probably a good compromise between giving the user the power, but not letting them shoot themselves in the foot!
# sudo: auth account password session
auth sufficient pam_smartcard.so
auth required pam_opendirectory.so
account required pam_permit.so
password required pam_deny.so
session required pam_permit.so
So if for some reason you want to have both Touch ID and the smart card authentication as options you might want to do this: # sudo: auth account password session
auth sufficient pam_smartcard.so
auth sufficient pam_tid.so
...
It will ask for smart card first but if a smart card is unavailable or authentication fails the touch mechanism will be requested. If you invert those parameters the order also gets changed.But one annoyance is that on macOS Monterey, the authentication pop-up dialog doesn't have focus when it appears. You first need to click on it before you can use Touch ID. That slows the whole process down to the point where it's probably just quicker and easier to use your password.
Is there any way to make the pop-up automatically get focus, or is that itself a security risk somehow?
(Side note: the same module enables authentication by Apple Watch too! But again, having to take your hands off the keyboard to tap the Apple Watch to approve the request slows down the process so much that it's hardly worth it)
Good.
Focus has really become a problem on Macs.
When I switched from Windows to Macs, programs were not allowed to steal focus from what you were doing. To me, it was an amazing thing to not be interrupted for every little piddly thing that some background process deemed to be the most important thing in the world. I was so much more productive when I wasn't being constantly interrupted, as I was in Windows.
Then, not too long after Snow Leopard, that changed. Programs here and there started asserting themselves. Now it's like Windows days, and it's awful.
Even Apple is guilty of this. A few days a week, I plug in four encrypted drives. It takes about five minutes for them to mount, so I go work on other things. I'll be happily typing away at something, and then suddenly find what I'm writing is being typed into the password field to unlock one of the drives.
Finder — perpetually awful — can't even keep focus on itself in the middle of some tasks. Even on a brand new M1 machine, 90% of the time, when I Shift-Command-N to create a new folder, focus will land in some random window or pane. The new folder was created, but it's just "untitled folder" all by itself, because Finder decided to go scratch its butt. Or sometimes the name of the folder is the first few characters I wanted it to be, because in the middle of typing the name, Finder switched focus to something else. Or when I switch to some other program, and then switch back to Finder a good percentage of the time, I find out that none of the windows are in focus, and none of them are focusable with Command-~ at all. So, I have to go back to the trackpad to select the right window. The window I was using twelve seconds ago, the last time I was using Finder.
I think allowing any pop-up to demand focus is a serious security flaw. I've sometimes found myself typing a password into a browser, or a word processor, because they've decided that they are the most important thing in my life at that moment.
[1]: There's so many things named warp these days, so here's a link to ease searching lol https://www.warp.dev/
Windows and macOS pop up the default browser (or on macOS, a webview) with the captive portal when they detect one. iOS doesn't have windows, so if it wants to get the user to do the captive portal without them sitting there in confusion it has to pop it up. It could pop a notification, but if the user misses it (as one could, with all the notifications that come in these days), then they are stuck.
0: https://support.apple.com/en-us/HT205296 (which has kicked in for me sometimes when my LAN doesn't have internet for whatever reason)
It does, they're just normally fullscreen ones.
The point is that that captive portal windows persist in the app switcher, and they can't be splitscreened on an iPad. So if you need to look at your email or text messsages to find your user credentials or the login page is badly coded and doesn't pick up your password manager you're screwed. It's really, really annoying.
The current situation is incredibly badly-engineered on so many levels. It’s maddening, really. One of the worst parts is that the modal disappears as soon as you attempt to switch apps (or god forbid you try to respond to a message you received)
Notification + real internet connectivity indicator + a regular Captive Portal/Internet App would go a long way.
That would make it faster than Touch ID and having to first click on the authentication pop-up.
I had "Secure Keyboard Entry" turned on in Terminal.app. Apparently this prevents the authentication pop-up (or anything else, presumably) from taking focus away from Terminal.
Turning it off solves the focus issue!
1. Copy /etc/pam.d/sudo to /etc/pam.d/customsudo and add "auth sufficient pam_tid.so" to that file instead.
2. Create the directory /etc/sudoers.d/ if it does not exist
3. Create the file /etc/sudoers.d/customtouchid with the following content:
Defaults pam_service=customsudo
You may need to set the right permissions on /etc/sudoers.d/customtouchid before sudo will accept it. sudo: account validation failure, is your account locked?
sudo: a password is requiredAs a result, I just enable passwordless sudo.
However I like having a password (or some other form of confirmation), just so that I can stop to think for a second, whether what I'm about to do is a good idea.
What's annoying is that I effectively need two different policies on workstations and on servers, since I still want to be able to escalate privileges from maintenance scripts[1].
Spoiler alert: Essentially nobody’s threat model includes that.
[1] https://akrabat.com/add-apple-watch-authentication-to-sudo/
No need for the third party pam module!
$ cat sudo
# sudo: auth account password session
auth sufficient pam_tid.so
auth sufficient pam_smartcard.so
auth required pam_opendirectory.so
account required pam_permit.so
password required pam_deny.so
session required pam_permit.soIs there a permanent solution, that does not involve cron scripts or other hacks?
The touch id part is once per iterm session so overall it's not too bad and reasonably secure as it uses built-in keychain to store passwords I think.
https://opensource.apple.com/source/pam_modules/pam_modules-...
Mine looks like
```
auth sufficient pam_smartcard.so
auth sufficient pam_tid.so
auth required pam_opendirectory.so
account required pam_permit.so
...
```
> That line basically tells the sudo command that the Touch ID authentication module is sufficient to authorize the user
might still do it.
(Edit: I guess the latter is also doable via fingerprint if a different finger is used as the suicide pill, seems a bit risky for normal use though!)
By... rewriting or modding sudo AND the login screen of macOS? Doesn't seem like a realistic option.
I think that's far more important.
> Mashable repeatedly asked Apple, Google, and Samsung for comment on the matter, but received not a single response to our numerous inquiries. We also reached out to a host of biometric security experts, hackers, digital law experts, and forensic pathologists in an attempt to get to the bottom of what has passed from the realm of dark thought experiment to serious inquiry, but the responses (or lack thereof) only further muddied the waters.
The articles I find claiming touch ID rejects dead fingers seem to be written by people who have no idea what they're talking about, so I would not take claims about its liveness guarantees (hah) seriously. People mostly seem to be confusing credible claims about rejecting e.g. pictures of fingerprints with incredible claims about detecting if a piece of tissue is alive or not.
the problem is, you cant really say "ignore less than 70% saturation as that is most probably a carrot" because covid patients got as low as 50% so i don't know what to make of it
related discussion (from 2013!) https://news.ycombinator.com/item?id=6477505
echo 'auth sufficient pam_tid.so' | sudo tee -a /etc/pam.d/sudo
authorization authorization_la chkpasswd login.term screensaver screensaver_la su authorization_aks authorization_lacont cups other screensaver_aks smbd sudo authorization_ctk checkpw login passwd screensaver_ctk sshd
So if you edit the sudo file it will only affect sudo. Likewise sshd will only affect sshd. Unless of course it contains an entry that includes another file which is common for Linux.
Now even if it causes problem for say sudo over ssh that page recommends that you add a "sufficient" entry. That means that method will be tried and if fails or its unavailable the next one will be tried.
Fingerprint authentication for sudo was enabled by default on my Manjaro install after I enrolled a fingerprint so I guess popular Linux distributions configure it automatically. If yours doesn't, try the configuration methods on this page: https://wiki.archlinux.org/title/fprint or here: https://askubuntu.com/questions/1015416/use-fingerprint-auth... or consult your operating system's documentation.
The big difference is that you need "pam_fprintd.so" instead of "pam_tid". On Ubuntu (or derived, probably), running "sudo pam-auth-update" will allow you to configure fingerprint authentication without needing to manually edit system files.
Do note that if you use a more exotic window manager, any fancy visual sudo prompts may not know how to deal with such a system. I don't know how gksudo and i3 work together on this, as visual sudo tools often try to block access to other windows.
If you're on Windows and want WSL with Windows Hello, there's this tool: https://github.com/nullpo-head/WSL-Hello-sudo which is a PAM library that will call into Windows Hello from WSL. Windows Hello should in turn support your fingerprint reader or other biometric authentication system configured for your PC.