Around 2014, I read a security researcher's article stating that biometrics should be used as an identifier at best, but never as a password.
“You can change a password, but you cannot change your fingerprint”.<p>From that day on, I’ve never used biometrics system used as authentication.<p>With a increasing use of biometrics on phones, should I think differently in 2022?
Speaking from personal experience, don't do this on a machine you'll ever access remotely, because then you're stuck waiting for the biometric check to time out before you can authenticate via another method.
I love using sudo with Touch ID and have been using this trick for years. The only inconvenience is that the PAM configuration always gets reverted by OS updates.<p>I wrote a small tool to mitigate this by configuring PAM on system startup: <a href="https://github.com/YuriyGuts/persistent-touch-id-sudo" rel="nofollow">https://github.com/YuriyGuts/persistent-touch-id-sudo</a>
Order matters. Lets say you already have a registered yubikey or similar smart card. The /etc/pam.d/sudo file might look like this:<p><pre><code> # 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
</code></pre>
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:<p><pre><code> # sudo: auth account password session
auth sufficient pam_smartcard.so
auth sufficient pam_tid.so
...
</code></pre>
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.
This is pretty neat.<p>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.<p>Is there any way to make the pop-up automatically get focus, or is that itself a security risk somehow?<p>(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)
For people complaining that this gets reset by macOS updates, I think this should work (I haven't tested this on macOS, but it works for me on Arch Linux):<p>1. Copy /etc/pam.d/sudo to /etc/pam.d/customsudo and add "auth sufficient pam_tid.so" to that file instead.<p>2. Create the directory /etc/sudoers.d/ if it does not exist<p>3. Create the file /etc/sudoers.d/customtouchid with the following content:<p><pre><code> Defaults pam_service=customsudo
</code></pre>
You may need to set the right permissions on /etc/sudoers.d/customtouchid before sudo will accept it.
I lock my computer when not near it. If my computer is breached, having user level access of the one account permitted sudo is pretty much Crown Jewels. If you really wanted to privesc you could sniff X11 keystrokes or back door bashrc, but either way even user level access screws me so whatever do what you want after that.<p>As a result, I just enable passwordless sudo.
ITT: “Ackshully if your threat model includes James Bond level tradecraft this is a bad idea.”<p>Spoiler alert: Essentially nobody’s threat model includes that.
Does anyone know why Apple doesn’t make this standard? I’ve been using this on and off for many years and only stop because I get frustrated after an OS update reverts it. Are there licensing/security/compatibility reasons this may be the case? Seems like an easy fix.
If you want to do the same but auth with your Apple Watch, you can follow this[1] guide.<p>[1] <a href="https://akrabat.com/add-apple-watch-authentication-to-sudo/" rel="nofollow">https://akrabat.com/add-apple-watch-authentication-to-sudo/</a>
For some reason, this only seems to accepts my Apple Watch as authentication, but not the fingerprint sensor... any idea why? (fingerprint works to authenticate in System Preferences, etc.)<p><pre><code> $ 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.so</code></pre>
This is a similar project for WSL. I love it.<p><a href="https://github.com/nullpo-head/WSL-Hello-sudo" rel="nofollow">https://github.com/nullpo-head/WSL-Hello-sudo</a>
It’s very cool, but every update of mac OS resets it! After a while I didn’t bother to reactivate it…<p>Is there a permanent solution, that does not involve cron scripts or other hacks?
I think it's a much better guide with iterm support: <a href="https://austencam.com/posts/using-touchid-with-sudo-in-terminal-or-iterm" rel="nofollow">https://austencam.com/posts/using-touchid-with-sudo-in-termi...</a>
This is what I'm trying to do but under Windows and Debian + preferably with a mechanical keyboard. Well the mechanical keyboard w/ fingerprint reader is the bigger ask cause there aren't many choices. There is a decently good one with Cherry MX switches from Taiwan but pretty much impossible to order one to Europe (they sell their other keyboards but not the one with fingerprint reader) <a href="https://www.i-rocks.com/web/product/product_in.jsp?pd_no=PD1550820469030&lang=en" rel="nofollow">https://www.i-rocks.com/web/product/product_in.jsp?pd_no=PD1...</a>
If you're like me and you got the order wrong, this will completely break your PAM configuration. To fix it, I had to temporarily enable the actual root user[1].<p>[1]: <a href="https://superuser.com/a/1357253" rel="nofollow">https://superuser.com/a/1357253</a>
Surely very convenient but idk, I still feel a li'l icky using my fingerprint for authorization. What if one day the fingerprint sensor acts up a little, as can always happen with such sensitive hardware? Then you 're just completely screwed?
So I've run into issues with this in the past, which seems to relate to using DisplayLink. Seems to be in how MacOS treats the DisplayLink driver, and can't be fixed unless Apple makes some changes in the OS level
1Password forces users to enter the master password at least every 2 weeks, super annoying and insecure. Eg my master password is super hard to enter, even more on smartphones, so I’m considering moving to a less secure one to avoid the PITA. All this technical innovation with Touch Id is great but then companies keep reverting to old annoying approaches when facing innovation…
reminder: biometrics are not protected by the fifth amendment. use strong passphrases.<p><a href="https://www.eff.org/dice" rel="nofollow">https://www.eff.org/dice</a>