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:
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 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.
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)
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.
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.
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.
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
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.
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).
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.
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.
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.
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.
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.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)."
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.).
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.
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?
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.
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]
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.
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
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.)
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.
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.
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:
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.
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:
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 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.
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.
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?
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.
> 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!
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
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...
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.
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.
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.
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
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.
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.
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.
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.
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. ;-)
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.
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?
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.
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.
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.
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.
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).
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.
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.
"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."
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.