Use TouchID to Authenticate Sudo on macOS | Hacker News Reader

Use TouchID to Authenticate Sudo on macOS

it.digitaino.com

340 pointsDerekBickerton140 comments

Not exactly connected but the same crowd interested in this topic may also be interested in this tool to store SSH private keys in the Secure Enclave, kind of like what can be done with a YubiKey:

https://github.com/maxgoedjen/secretive

I've been looking for something like this for 3-4 years but only found it six months ago (in an HN thread). I use separate keys for every use case, and now know every time a key is used for any purpose, whether it's connecting to source control or my text editor is connecting to a remote VM.

Only thing I haven't figured out is how to do git signatures with these sorts of keys, but I haven't debugged it at all.

I think 1Password's SSH agent does this now, too

I didn’t know that was a thing, thank you!

https://blog.1password.com/1password-ssh-agent/

But it’s not really the same. Having private key material in the secure enclave means that it’s not extractable (except perhaps by state-level attackers with hardware access). With an SSH private key in 1Password there are still many possible software-level attack vectors (vulnerabilities in 1Password, a compromised 1Password update, etc.).

Secretive is great. I use it on my T2 and M-series Macs and feel much better with keys sitting in those machines' secure enclaves than I did back when it was just sitting in ~/.ssh/ for anything to grab.

I just wish there were something as clean as Secretive for using generic PC TPMs or YubiKeys in place of a Secure Enclave under Windows and Linux. Currently have a Linux laptop halfway through setting that up and it's messy in comparison.

For Windows, it seems it's possible[0, see footnote], however there are problems like general incompatibilities [1], and official support status is " We have this in our backlog. At this point it's not prioritized.".

0: https://github.com/tavrez/openssh-sk-winhello

0.footnote: "Windows Hello also supports other types of authenticators like internal TPM device(if they support generating ECDSA or Ed25519 keys, they can be used instead of FIDO/U2F security keys)."

1: https://github.com/tavrez/openssh-sk-winhello/issues

2: https://github.com/PowerShell/Win32-OpenSSH/issues/1804#issu...

Its possible to do, and once set up its a reasonably smooth process.

- Init Your TPM

- Create a key+cert on your TPM using certutil.exe

- Grab your public key

- Use WinCryptSSH (https://github.com/buptczq/WinCryptSSHAgent) as your SSH agent and away you go

These are very simplified steps, but there are howtos floating around (eg https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h...)

It's actually very easy on linux now: You just use the two -sk key types released in Feb 2020 https://www.openssh.com/txt/release-8.2

`ssh-keygen -t ed25516-sk` or `ecdsa-sk` and then you touch your yubikey when unlocking the key, the same time as you would type a password.

Question for anyone else reading: Does it make sense to use a password with -sk keys? I don't think it would make a difference either way.

> Does it make sense to use a password with -sk keys? I don't think it would make a difference either way.

Only if you want to protect your keys from being used by someone that has access to the private key + yubikey (i.e. someone physically present).

In other words, the -sk type private key is useless without the yubikey as well.

Physical presence makes sense. I didn't really think it through but it's just the same as any other 2FA: you want something you know and something you have. Thanks.

Are there any Linux-friendly laptops with a TPM built in?

It's nice not to have to rely on an external yubikey

It's not a perfect rule but anything a generation or two behind and has a GPU that's either integrated (Intel or AMD) or discrete AMD with Intel wifi and bluetooth are going to have a pretty good chance of handling a reasonably recent Linux distro (e.g. Fedora or Ubuntu non-LTS) well. While Nvidia provides official Linux drivers, I've personally had more trouble out of them than I have the stock Linux drivers for Intel and AMD GPUs.

Any laptop that is listed as supported by Windows 11 will have an onboard TPM.

Why those things are not built-in to macOS. I don't understand. It should not be hard to implement for Apple engineers and it could be a good example for corresponding API.

I don't use sudo often enough to warrant system changes, so I don't use those programs, but if they would be enabled by default, I would gladly use them.

Another pet peeve is: why can you auth with your watch but not your phone?

It would be nice, but the phone would have to be unlocked at the same time you try to authenticate on the computer for this to work. Part of why it works with the watch is that you have to have an unlocked (but pin-lockable) watch near the computer. Most of the time when you're wearing the watch it will be unlocked (this is the default behavior, after unlocking it stays unlocked while worn) whereas the phone will relock itself. So it would be useful, if you happened to have already unlocked your phone near your laptop, but probably not as consistently useful as the watch. Most of the time, you'd find yourself unlocking your phone to unlock your computer which is not really convenient, so you'll just unlock the computer itself.

This would be useful in the case when laptop lid is closed. TouchID/FaceID are still very fast

You can do this with a chromebook and an android phone. I find it is more comfortable and faster to just type in the pin vs unlocking the phone, so I don't use it much.

MacOS doesn't believe in PINs. It's passwords or touch id.

I'm glad my windows PC only requires a PIN :)

The Magic Keyboard for Apple Silicon macs has a Touch ID button. Works great.

It’s not that different than initiating an Apple Pay for. Safari on Mac and reaching into your wallet on your iPhone. The framework is there. The UX would be to get a prompt in a similar way and Face ID unlock

small returns on a small market for prioritizing the work. maybe you're unhappy with the profit seeking system

Are software developers really a small market?

There is probably low priority/ignored because most developers can easily do this on their own, so it's not really worth the hassle.

Some googling shows ~20 million software developers around the world. Some googling shows roughly 2 billion households globally and 50% of them have a PC in their household. So let’s say 1 billion PC users.

20 million / 1 billion = 2%

So yes, it seems like a small market relatively.

Remember Steve Ballmer?

Developers are incredibly important for an ecosystem and having them a bit more optimistic about a platform can be quite beneficial (for a very low price, even).

They were a significant portion of getting OSX to the masses, but became less and less relevant to Apple over time.

Just an FYI, 1Password can now manage ssh keys that you can authenticate with TouchID

Maybe.. but it would also make it way easier for 'normal people' to use SSH keys / signing.

Seems like a natural thing to have in keychain.

Still they bother to compile ssh, git, they even got some custom OpenSSL binary. They definitely have some resources allocated for “non-profit” development tools.

It is because Apple will use their own authentication-key approach with Apple passkeys, which stores a key pair on a person's iPhone.

Note that there are some pretty significant caveats to Secretive:

- You cannot import your existing SSH keys

- You cannot transfer SSH keys if you get a new machine

That’s the whole point, no? Tie identity to the machine itself, not a piece of data that can be stolen.

BTW, if you have a key that you copy around to multiple machines, you’re doing it wrong!

It's not sufficient to be the whole point.

With some security mechanism, I'd consider:

1. prevent other people from being able to use it. 2. recover from it in case it gets lost.

If your perspective is "if I lose this laptop, I have some other way to access the systems", then it's good to never access the SSH key secret.

If your perspective is that you want your secret key to be the only way to access some system, you'll want to have some way to recover the secret.

I think in any case, it's understood that having an unrecoverable secret being the only way to access some system is a bad idea.

Exactly, these are precisely the features I'm looking for. They are not caveats, they are the way I want my keys to behave.

If there is some sort of use case where I want to be able to backup a key, or share it with someone else I can always fall back to SSH keys on a hard disk. But those are usually anti-patterns.

Backup and availability is where all of these systems fail. Even the new passkey sync thing is pure vendor lock-in.

I'd prefer for a backup to be a second key on a different hardware device, personally.

I might also be ok if somebody like Apple had engineered a cloud solution for securely keeping backups, but only maybe.

the main problem is the lack of support of rsa keys.

Do you actually have something that can't even do NIST curves? Genuinely curious.

Azure DevOps.

I've been using https://github.com/sekey/sekey for years now! It handles gpg as well

I actually tried this and was glad I left myself an out - I had a kernel panic, after which the contents of the secure enclave where wiped with the rest of the system state (to restart from known good settings???). Bye-bye SSH private key. I would recommend caution if you use it.

The same could happen with a hardware token like Yubikey, if it were to suffer from an irrecoverable software or hardware error. It's still useful, because spoofed authentication prompts will no longer get a chance at plaintext access to your password.

This is also why it's a good idea to have multiple keys instead of having everything riding on one. With a T2/M-series machine it's easy to have at least two (one in Secure Enclave, one in a USB key), and USB keys are tiny enough to hide away another one or two.

I've always felt that the suggestion of having two keys seems kinda cumbersome, especially for webauthn. If understand it correctly I need to enroll both keys, by physically having them present? Then I need to remember to enroll the second one whenever I sign up for something (or keep both keys with me, which kinda negates the backup perspective).

For SSH it's probably easier since I can just have both public keys accessible for adding it to new servers and keep the token somewhere safe.

My preferred solution would be to generate the private key material outside of the secure enclave (but on a offline device or something), write it down on a piece of paper and then transfer it in to the enclave/hardware device.

That way I could just restore the same private key if the physical secure enclave is destroyed.

> If understand it correctly I need to enroll both keys, by physically having them present?

Yes.

> Then I need to remember to enroll the second one whenever I sign up for something (or keep both keys with me, which kinda negates the backup perspective).

Alternatively you print out the backup codes.

> My preferred solution would be to generate the private key material outside of the secure enclave (but on a offline device or something), write it down on a piece of paper and then transfer it in to the enclave/hardware device.

The primary reason why we want to do hardware at all, is that to the best extent we know the key is generated by it and will remain in it. That most of the threat becomes someone in the physical world stealing it from you.

Though some more open-source webauthn tokens would allow you to do what you described. Secure key management procedures are just not something we should encourage people to do themselves, it's difficult.

> Alternatively you print out the backup codes.

But those are per site right?

Re hardware and that above is not something for most people:

Yeah I agree. Something like https://uni.horse/notes/solo-key-backups.html, but it shouldn’t be a solution for most people.

But I still think the backup story is flawed, and could be improved to work in a easy and secure way:

Using some easy vendor GUI tool, with a simple clone button:

1: Generate on-hardware webauthn master key on device A. 2: Generate on-hardware key-par on device B 3: Export B’s public key to A 4: Encrypt A’s private key with B’s public key 5: Export encrypted master key to B 6: Decrypt on B

But I guess we ideally would want some standardized protocol for doing this so you can do cross vendor backup.

Personally I don't think I'd bother with redundant keys for most sites/services, only for those of the greatest importance. I think for most of us that list is short enough that redundancy is manageable.

Probably true. But my point is that if there was some secure/easy way to clone a key you wouldn’t need to think about redundant keys at all. If you create a clone you get redundancy for all sites in one sweep

(Most likely this will be solved by the mobile os vendors who will sync and backup your private key for you. Using your phones HSM instead of an external device)

I know PAM gets criticized here and there, sometimes heavily, but it's actually a super flexible system. The thing that really stands out is that no application actually needs to know about all the various authentication methods possible. That file in /etc/pam.d/ just corresponds to the app's "service name", and you (as the machine administrator) can put in it whatever you want. The app just needs to go "Hey PAM, I want to start authentication using service 'sudo'", and then PAM will send instructions to the app, like "Display the text 'Place your finger on the fingerprint scanner'", or "Display the text 'Password:' and then prompt for masked input".

It's really quite flexible, and despite its age, still works pretty well with current programming paradigms, whether your UI is text or graphical or whatever. The one oddity is that when it asks you to prompt for some kind of user input, it will actually expect you to return the resulting input from the same callback function. So if you're using a modern-ish GUI toolkit, you'll need to run the PAM stuff off on a different thread that's allowed to block while your UI thread is free to do what it needs to do. But overall that's just... fine?

The API for “Pluggable Authentication Modules” (PAM) seems to be earning its name. It’s an ideal adapter layer for adding interoperable authentication to any program. And since so many programs already consume it, it’s a natural target for new authentication providers to implement. If a backend can serialize its authentication model to users and groups, then it can give those lists to a program that consumes them through PAM to authenticate users and authorize actions.

Thanks to open standards (really POSIX in this case), even a small program can immediately benefit from PAM authentication because it will work in any organizational environment, regardless of whatever over-engineered backend system (like LDAP or Kerberos) or SaaS (like Okta or O365) is providing the list of users and groups.

I was really hoping the article would have explained a bit about PAM. Any high school English teacher can Google instructions for enabling sudo with Touch ID, but I’ve come to expect HN posts to have a higher pedigree.

Yes, I thought the same while I was googling to ensure my comment wouldn’t betray the fact that I’ve never actually implemented PAM myself. :D (I’ve certainly benefitted from it though!)

When exploring a technology I like to search GitHub for it, since that should surface a healthy sample of code that uses it. For instance the “pam” topic looks like a fun rabbit hole to click into, with a list of repositories demonstrating a wide array of use cases for PAM. [0]

[0] https://github.com/topics/pam?o=desc&s=stars

What's the connection between PAM and POSIX?

My impression is that PAM assumes it’s running in a Linux kernel with the typical POSIX users and permissions system. I could be misinformed though, I’ve never actually coded anything with it.

That's not entirely true. PAM exists on many systems, wiyh their own codebase. FreeBSD for example has its own build which definitely doesn't presume Linux.

Not sure which one macOS' implementation is based on but considering its history I would bet on one of the BSDs.

Self plug, but here's a PAM module I made for using gpg for login: https://gitlab.com/rendaw/pamgpgr . I've been using it for a couple years for sudo I think (yubikey).

The code is fairly small so it can be an example for doing other PAM things too.

I've also done this on my Framework laptop running Linux, it's really convenient. Have it set up for sudo, user login, etc. Just added this to various files in /etc/pam.d

  auth sufficient pam_fprintd.so

On my ThinkPad X1 Nano, GNOME under Fedora 35 and 36 offer the ability to use the fingerprint sensor for login and sudo in the Settings app. Pretty nice.

Lol, just learned my laptop has a fingerprint reader.

I tried this just over a year ago, but it is quite flakey. IIRC because of how PAM works, you have to wait until this PAM module times out before you can switch to another form of authentication. (E.g. because fingerprint authentication fails.)

This nicely did the trick! Adding the line at the top of /etc/pam.d/system-auth makes sudo authenticate use the fingerprint, which is nicer than always typing my password and gives a streamlined experience between SDDM and sudo.

Every MacOS update, I do run a sudo command and get the password prompt. I cancel, and instead do...

    sudo cp ~/Dropbox/etc-pam.d-sudo /etc/pam.d/sudo

Type the password once and you're done. I've been carrying this around for quite a while. No need to edit the file every MacOS, just copy it.

But once it did utterly go south when Dropbox's "load files on demand" functionality replaced the file with a bunch of zero bytes. That wasn't fun to fix. So maybe Dropbox isn't the best storage place.

Consider storing a diff instead of replacing the file completely. If the patch fails (either because the diff is all zeros or the file has changed in some material way), you can proceed with the appropriate fix.

Here's a single line you can run that'll add the needed line to the file in the correct place for you:

    sudo perl -pi -e 's/(pam_smartcard.so)/$1\nauth sufficient pam_tid.so/' /etc/pam.d/sudo

Thanks for sharing. While tweaking the formatting, I accidentally introduced a typo which led to me spending a few minutes hunting for a fix for "sudo: unable to initialize PAM: No such process" without having to reboot :(

Anyway, here's the version of your one-liner I used to preserve the spacing used in the rest of the file:

   sudo perl -pi -e 's/(pam_smartcard.so)/$1\nauth       sufficient     pam_tid.so/' /etc/pam.d/sudo

Or something like

    printf '%s\n' '/pam_smartcard\.so/a' 'auth sufficient pam_tid.so' . wq | sudo ex -s /etc/pam.d/sudo

I did this when the touch ID macs were first released and very quickly disabled it.

Why? Because asking for a password for su / sudo broke the flow -- not only did I have to move my right hand from the home row (or both, for my watch), but it popped up a modal-like window away from where my eyes were. Basically it impinged on my focus.

Nice idea, not so nice in practice.

Also, with sudo, I think a lot of the value is the inconvenience of typing out a password. Having to stop and think and type is a nice guardrail that I think fingerprint-based auth would remove.

The sudoers file on my Mac is configured to always show the disclaimer (and I deleted the Apple written one so it shows the original disclaimer too). It’s definitely made me stop and think once or twice before brew did something I didn’t want it to (or if I forgot which terminal I was in).

Does watch unlock now work natively with pam_tid? I know as of at least a few months ago it would only work if you could use touch ID, i.e. when the laptop was open. If it was docked, it would fall back to password auth.

I wrote a patcher that changed this behavior, it patched pam_tid directly on your system and just updates the API Apple calls to allow unlocking with watch-only when touch ID is unavailable:

https://github.com/inickt/pam_wtid

Was a fun reverse engineering experience and wrote up some more info in the README.

I'm using this to authorize sudo (and other things) with Apple Watch:

https://github.com/insidegui/pam-watchid

... and my /etc/pam.d/sudo needs to be changed like this:

    # sudo: auth account password session
    auth       sufficient     pam_watchid.so
    (...)

This needs to be applied after every system update. Apart of that, it works really well (I have very dry skin so touch ID works for me 50% on a good day)

Guilherme’s stuff is great. pam-watchid is a reimplementation of Apple’s pam_touchid, but uses the other authentication flag which I patch in to the original binary.

I wonder why Apple haven't made this a default on TouchID Macs?

I mean, practically - probably not a ton of demand for a cooler, better `sudo`

I see this post pop up often so I think there's demand. But Apple only cares about solutions that make money, and this one doesn't. With Apple, I'd expect them more to block free solutions, and require an iCloud subscription to enable it.

Is this just anti-Apple nonsense, trolling, or do you really believe that Apple would add an iCloud requirement to enable auth via fingerprint reader (an authentication method that already works for many other things without an iCloud subscription)?

I tend to be critical of Apple, but the spectre of them charging for sudo is absurd. I suspect that the actual reason is boring: This is a developer oriented feature and these features aren't judged as important as other stuff.

Probably because a lot of damage can be done with sudo.

More than with Touch ID/Face ID that are used in a shit ton of places?

Yeah, one of the things I did once was use sudo emacs to edit the sudoers file (I didn’t know better) and in the process locked myself out of sudo.¹ With sudo you can muck up a lot of permissions/security that shouldn’t get mucked and backing out of that can be challenging.

⸻

1. I was able to fix it using Repair Permissions in DiskUtil. If I were running Linux I don’t know that I could have fixed it at all, although maybe Linux is more forgiving of this sort of sin?

This is why you have visudo which checks your changes before saving.

Ps just mentioning it in case you didn't know about it. I know there's still ways to lock yourself out that visudo doesn't catch.

The command back when I did this was sudoedit but I didn't know better, although I don't think it did any checking of the file for validity, just made sure that the correct permissions were in place when I was done. Now, the default sudoers file on MacOS has a comment saying to edit with visudo. But there are enough footguns possible with sudo that any friction to using it is a good thing.

I believe it makes ssh not work great since if you ssh into the machine and do sudo, there’s no way to put your finger on the sensor

macOS already does fallback for this just fine: if an application requests authentication with the Secure Enclave, I'm prompted to touch the touch ID sensor if my laptop is open, but if it's closed and I'm using a docking station, it just asks for my password instead. No reason why remote ssh can't work the same way.

> Keep in mind that this file is somewhat protected by macOS so after each OS update you will need to add the line to the file. Other than that, it works perfectly!

TIL, I wondered why every time I did this it would reset after a while. Thanks!

I've been wanting to write a simple script or app that just runs on startup to check for and fix this, but I've been so lazy. It is just too easy to edit the file and move on...

I'm even lazier, stole another commenter's script and just have it run on reboot.

Is it idempotent? No, every reboot it adds the line again. Doesn't appear to matter though.

I would never be so cavalier about a security related thing such as this.

See my other reply on this thread.

I use nix-darwin to automate that.

More details please.

nix-darwin currently does not support that directly, but there is an open PR to fix that. For my dotfiles, I added the module from the PR with some slight modifications. You can find the code below.

https://github.com/shinzui/dotfiles.nix/blob/master/modules/...

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"
    fi

To get this to work inside of tmux sessions use this: https://github.com/fabianishere/pam_reattach

Everyone does this, right? It's super convenient except that macOS nukes the pam.d config file every update.

No. I only use sudo in "sudo su" once in a while when I need a root shell (sometimes not even on the local machine), then does everything within that shell. I don't understand people bothering themselves with that command. I also find egregious tutorials in which each command is prefixed with sudo.

sudo -i

Personally, I tend to forget that I'm in a root shell. Also, I don't want to _be_ in a root shell for more than one command unless absolutely necessary. Also also, prefixing commands with `sudo` that need `sudo` shows the potential dangers such command comes with.

Previous discussions:

2021.03.01: https://news.ycombinator.com/item?id=26302139

72 days ago: https://news.ycombinator.com/item?id=31750560

In the same vein, I recently made a tool to use TouchID and the Secure Enclave to protect arbitrary data and env variables from the commandline: https://github.com/pathtofile/toucli

After this setup. What happens when you SSH onto your Mac and run sudo?

It is just an additional authentication mechanism to a list of various ones. If the client (COM port terminal, KVM terminal, SSH client, bare /dev/tty or any other client you can think of) does not support this mechanism, it will go for another one.

UPD: https://en.m.wikipedia.org/wiki/Linux_PAM

Just tried this. It asks for your password via the terminal as usual.

You have to put it below the first line, like in the example.

Huh? I know that. I read the article myself. I was answering OP who was asking "What happens when you SSH onto your Mac and run sudo?".

I like that you can do this and appreciate the knowledge, but it seems slower than just typing in your password, and kind of breaks my flow by removing my hand from the home row.

That depends on how long your password is I guess. I much prefer Touch ID personally it probably takes about the same time as typing my password but there’s no chance of a mistake or typo. It’s pretty seamless in my experience.

I set this up a few years ago and it's been very handy. I can also use my Apple Watch to authenticate certain things on my Mac, so I should try to set this up for sudo. Maybe my Yubikey as well.

I use external monitors now and leave my MacBook closed in a dock, so it would be nice if I could use an external fingerprint reader that I plug in via USB. I guess the Yubikey is sort of like this, but it's probably not as secure as using a fingerprint.

I guess this is as good a time to ask as any.

Is it possible for a process to authenticate a user without root privileges, including setuid/setgid?

I never understood why Apple doesn't do this by default, after all you can elevate to admin by fingerprint in the UI.

And like others said, it doesn't persist anymore. I also edited the sshd_config to enforce public key Auth but this was getting annoying.

I use FreeBSD now which lets me use my computer the way I want to.

Except... is it just me, or is TouchID on MacOS unreliable for mostly everyone? It seems like I have a 25% success rate with TouchID. I have the same fingerprint mapped to three "fingers" and still it's awful.

It is solid for me on my m2 air. I don’t think I’ve ever seen it ask for me to retry.

My work profile is one finger, personal profile a different, both work great.

It's not just you. I give up and enter the password a majority of the time.

I have noticed if I remove my fingerprint then add it back, it's more accurate for a short time. Then over time it goes back to not working as well.

My wife does a lot of garden work. When she set up TouchID in the winter, it worked fine – until the gardening season started. Then it gradually became more unreliable, until it stopped working altogether. Then early last fall, when she went to the police station for a new ID card, their fingerprint reader was unable to read a fingerprint from any finger. She was told that this is not uncommon for people who do garden work, rock climbing, or some other kinds of manual labour. Their fingerprints just wear down enough for the reader not to be able to read them. – But not completely. Burglars beware. ;-)

I was painting a lot of windows and between paint, sandpaper and various minor injuries, Touch ID didn’t work reliably.

I set my nose as a finger and I t worked.

I've noticed people saying this over on MacRumors, but my experience is exactly the opposite. I have a single finger set up as a single fingerprint, on a M1 Air, and it's been 100 % since I got the machine 20 months ago.

Like literally 100 %, I don't think I've ever had to touch the sensor twice or wait more than half a second.

PS: My hands don't sweat much and I keep the keyboard clean and without dust.

I don't have that success rate. But what usually helps is enrolling a fingerprint twice a year. I guess it has to do with having dryer hands in the winter. So I typically redo a fingerprint near the end of autumn and at the end of spring and I am fine, so I am also near a 100% recognition rate.

I also only enroll one fingerprint, because I use a Magic Keyboard with Touch ID when I have the MacBook docked, the Touch ID sensor is always in the same position relative to my hands.

Regardless, I still hope we'll have Face ID on Macs one day.

Weird. For me, it has been working flawslessly since I got my iPhone 6s, and now two macbook pros down the line, I've had it fail maybe 5 times in total?

Mine works nearly perfect. But an ex-colleague of mine couldn't use any interface with fingerprint recognition. Not the laptop, nor the phone, nor the (presumaby fancier) door access systems. There must be something odd about his prints, but it isn't visible to the naked eye.

Note that the order of the lines in /etc/pam.d/sudo matters. Add the "auth sufficient pam_tid.so" line below the pam_smartcard.so line as shown in the article for this to work correctly.

Mine doesn't have a pam_smartcard.so line(?)... It has pam_rootok.so, but adding below that doesn't work. Odd.

Annoyingly my company monitors changes to the file and last time I tried this I got a message a few minutes later asking what I’d been doing. They did let me keep the change once I’d explained.

Fingerprints can be hacked

https://news.ycombinator.com/item?id=29306163

For some reason this often doesn't work for me; it seems to randomly only respond to my Watch to authenticate this, but not TouchID...

Not a great idea, and also not good to use TouchID in general. If you're really keen on having a high level of security, the fact that someone can easily force your finger to unlock your Mac is not great. You don't even need to be conscious to allow ill-intentioned people to take advantage of it.

I wish Mac OS would allow the use of a "stress" fingerprint, e.g. right index fingerprint is to use when you're under duress, while instead another fingerprint is for normal use.

Not a Mac user, but on my Linux system i require password + yubikey (U2F/WebAuthN) for logging in, but then fingerprint is sufficient for sudo (or U2F alone on my desktop which doesn't have a fingerprint reader).

I typically lock my system when away from it so having fingerprint sufficient for sudo doesn't seem so bad.

Interestingly, making this change can trigger a CrowdStrike "privilege escalation" alert.

Fun fact: if your laptop has an IR camera, you can also use face recognition for that purpose.

More details? Is that an included auth mechanism with MacBooks or something you can install from GitHub?

https://github.com/boltgolt/howdy

Never heard of similar stuff for Macs, this is Linux software. Worked fine on my ThinkPad laptop running Fedora.

Either TouchID is really poor fingerprint scanner, or state of the art just sucks. As a rock climber, it stops working after even a light climbing session. Obviously there's some abrasion on the skin when one climbs, but I can't imagine it generates a new, unrecognizable fingerprint.

It’s the rock climbing. See my comment here:

https://news.ycombinator.com/item?id=32616371

I never understood why this isn't enabled by default in the first place.

i remember this was possible on thinkpads and linux with a custom pam library like ten years ago.

it was fun to set up, but not really worth maintaining.

This seems like it should be default behavior

Not to knock on this too hard because it seems cool and useful for 98% of people out there but touch id does have an unfixable vulnerability. If you are security obsessive, maybe no touchid altogether on your mac (I use a token).

https://arstechnica.com/information-technology/2020/10/apple...

What about on apple silicon macs?

Seems like not (but I was just doing lightweight googling out of the same curiosity), the last exploitable generation of AS was iPhone X, which I _think_ predates the AS macs. Also as far as I understand exploitation would require physical access to the target device.

I'm fairly sure that checkm8 doesn't affect apple silicon macs.

Happily the exploit doesn’t exist in any of the arm macs.

That said the checkm8 exploit requires (as far as I’m aware) physical access to the target device, which is a fairly constrained attack vector for any real world attack. Obviously if you are at risk of such attacks though then your risk profile is _vastly_ different and the steps you need to take are also different.

tldr;

"But the T2 also contains a vulnerability, known as Checkm8, that jailbreakers have already been exploiting in Apple's A5 through A11 (2011 to 2017) mobile chipsets. Now Checkra1n, the same group that developed the tool for iOS, has released support for T2 bypass."

"Computers that have the Apple T2 Security Chip": https://support.apple.com/en-us/HT208862

Reply on news.ycombinator.com