Similar: On Linux, doing something like this doesn't require patched sudo. sudo uses the OS provided auth framework (PAM), which is pluggable (the 'P' in 'PAM' stands for 'Pluggable'); and fprintd provides a pam plugin.
The `LocalAuthentication` framework this project mentions sounds like an OS X equivalent of PAM — an OS level account auth framework. I wonder why/if the `sudo` on OS X doesn't use it.
Yep, I've used the Yubikey PAM, and it works just fine. My first thought on seeing the title was: WHYYYYYY?
There are some slight usability issues with using custom PAM config. E.g. if you want to unlock the lock screen without password using the Yubikey, you still need to press enter.
> While I am using this as a fun experiment on my personal computer, your security needs may vary.
So yes, this is a toy system. Cool concept, but not something you probably want around in production/secure environment, which I assume most people would know not to do.
To what exact cases are you referring? Do you not use an ide with a test runner? What exactly is desirable about triggering and monitoring this from a second display on the keyboard--where you're looking all the time, naturally--over clicking a button on screen?
Take a good look at the IDE running there. It's Vim. I use that all the time, and so do many other people on HN.
Do you need a button like this on your keyboard? No, you could set up a new Vim bind. But this is more dynamic; what if the test re-run buttons were only visible after having modified a file, and replaced with a deploy or commit button if tests succeed?
If you're vigorously opposed to it, don't buy a Mac. But some people can definitely see use in it. It's like your function row, but with visibly context-aware functions.
Would vim be fun/useful to use on an iPad? Because, I think that is what your argument really says...
>But this is more dynamic; what if the test re-run buttons were only visible after having modified a file, and replaced with a deploy or commit button if tests succeed?
More dynamic in that you have to look away from your work to trigger a re-run? Or more dynamic in that its completely worthless if you use an external display and external keyboard? Or more dynamic in that it's another avenue for show-stopping macOS bugs?
The computer already has a fantastic dynamic display built in—the display. Your eyes even naturally fall there. Why do we need a second display at all, much less on the keyboard where people do not look?
Unless you're touch-typing your function keys, you certainly do look there.
I don't want a "second display"; I want dynamic, context-aware buttons. Focusing on the fact that it's "another display" misses all the benefits of it not being static hardware buttons.
The buttons on your keyboard are already context aware. All this does is make them difficult/impossible to touch type (I touch type my F-keys), forces me to look away from my display to perform operations, and removes the good tactile feedback you get from a keypress.
"Context-aware" as in the applications you use will decide what to do with the inputs, I guess, sure. The applications you use being able to create their own inputs is an entirely different thing and what I meant by "context-aware".
I agree, though, that the lack of feedback was a mistake.
With PyCharm and most Jetbrains IDEs I can remap keys to run test. So pressing two or three keys will run tests AND!!! I don't have to look at my keyboard to run the tests NOR see the results.
Meanwhile, the other 90% of users will probably love it when their IDE, profiler, every browser's developer tools, etc. can display context-appropriate labels so they don't need to remember what F8 does in the current mode of the current application.
My emacs already does that if I want it to. My vim did it before I switched to spacemacs. I still don't understand why you'd want to give up physical buttons for an awkwardly angled small touchscreen that requires using your laptop's keyboard.
Yeah, but you're ignoring the functionality loss from not having the function keys. You may not use them, but many people do.
For example, in Emacs (and I'm assuming most IDEs) I can map a function key to run my tests and have a status bar entry saying how many passed or failed. It's the exact functionality in your screenshot, no touch bar required.
At best the touch bar is a nice gimmick, and it's not adding anything you can't already do, and the trade off is the function keys. They could have just as easily left the function keys alone and added the touch bar above.
> The standard "function keys can do anything" response is getting old.
That "function keys can do anything" is, in my opinion, the exact reason they had to go. They're scary for the typical user. What is F7? You may know, but it's not obvious in any way. That some of them cause destructive actions (e.g. Alt+F4 on Windows) makes it worse - they're scary to many users. And even when after figuring out what some of them do, one is stuck wondering "was that F8? Or F9? Oh! It was F10" (which, includes the worry that a wrong guess could cause problems).
Though, I cannot believe they shipped it without the haptic feedback to make it clear that a button was actually clicked.
^ Also, none of that, to me, includes Esc. Esc seems clear enough in its intent, and I hold no ill-will toward the Esc key.
Exactly. Particularly once you jump between a few apps, and as I said elsewhere, I can't use media/volume/display controls and f-keys without the function key, so I don't use the f-keys on my existing MBP.
The way that for the last couple generations the touchpad hasn't actually "clicked", and been simulated by haptic feedback. That same feeling on the Esc/Cancel/etc. virtual button would alleviate most of my personal concerns.
I'm surprised they didn't include it given how much they've been pushing it on iOS, as well as on the touchpad of Macs.
Adding 'touch' to a UI designed for mouse/trackpad + keyboard interaction is inherently a terrible idea. Even my pinky finger is much bigger than the cursor. I would have zero chance of being accurate with it.
Also, that still requires the actual controls to be on-screen somewhere. With the touch bar, you can opt to not have those controls (e.g. a toolbar in an IDE, or a palette in a visual tool like photoshop) shown on the main display if they're available when contextually relevant, on the touch bar.
That seems entirely unrelated to what you quoted. Regardless of whether the whole screen becomes a touchscreen, or a bar is used, the F-keys in their form are bad UX.
But "full colour multitouch interfaces" are awful compared to keyboard keys! Getting to switch back to my mouse + kb after using my phone is so fantastic.
This bar is all the bad stuff about a touchscreen (limited/no tactile feedback, reduced ability to rely on muscle memory) plus the bad stuff about keyboards (primarily that they are not where your eyes are naturally). There are a few tiny niche uses cases that will be nice, like video scrubbing, but 90% of the time it's just going to be functionality that is more difficult to use than it was previously.
I'm pretty sure I hate the current situation with F-Keys at least as much as you claim to hate multi-touch interfaces.
If you truly use F-Keys by touch (i.e. without looking) forcing the touch bar into F-Key mode should get you pretty close to what you had anyway.
The F-Keys don't have the little identifying lumps (on mine these are on F & J), so you simply have to know where they are by muscle memory. The only difference is you're tapping like a track-pad tap (as opposed to trackpad click).
On a proper IBM-M style keyboard layout, the F keys are in groups of four, with spaces between each group. This makes it trivial to touch-type them without looking.
It's really a very well laid out keyboard design. The worst thing about laptop keyboards is that they are all so non-standard, and every manufacturer does their own special-snowflake thing, so that it is almost impossible to touch-type on an unfamiliar machine.
But they didn't add a dedicated hardware video scrubber. They added a dedicated hardware input device that can present basically any type of input. Those are just examples of what's possible that wasn't possible before.
You're not losing function keys, they're just becoming more powerful. You can still set the touch area to be a row of function keys, if you like that! Or they might become more dynamic, by updating which binds are available based on what's on screen.
It is a nice gimmick. Is there anything wrong with an improvement, even if it's a little one?
First, your F keys already change binds based on what's on screen. Second, you are ignoring all the things that are worse. You can't really touch type any more, you have to take your eyes away from the screen, and you get greatly reduced tactile feedback.
It is a gimmick, but in my opinion it's not an improvement, it's counterproductive.
I have a feeling this is EXTREMELY DANGEROUS to have on your Mac. Using DYLD_INSERT_LIBRARIES and attacker could inject code that swizzles -[LAContext evaluatePolicy: localizedReason:reply] to always invoke the callback block with success set to YES. e.g.
This won't work on SIP protected binaries (n.b. system binaries), but might still work on other binaries while SIP is enabled. It's mostly moot however as many developers have SIP disabled.
This would not work. setuid binaries do not respect these flags, for obvious reasons. But if you're at the point where you can inject environment vars into a devs workstation, it's probably too late for that dev.
You're right. I had a suspicion of this (hence the non-committal "I have a feeling") but a quick Google search before writing the comment didn't yield much. After seeing your reply I looked at the dyld source: http://opensource.apple.com//source/dyld/dyld-210.2.3/src/dy..., see the function pruneEnvironmentVariables.
This sounds amazing, and Id love if Apple allowed touchid for regular account-password prompts in macOS 10.13 (or a Sierra point update but let's be realistic)
If they integrated this down to the built in sudo/su that would be even more amazing, but I imagine that's much less likely.
It is already the case. In the keynote, they demoed Fast User Switch with a touch of finger. If multiple people share a single computer, switching to the right user account is a touch away.
I haven't tried the new MBP but this was how I assumed it worked... On iOS you just need to enter your password when the device first boots, then you can use TouchID to authenticate for almost everything where you would use your password.
Okay, so there's two requirements for any legit authorization to pass: identification, and authentication. For Unix accounts, the username is the identification bit, and the password is the authentication bit.
Now, you don't usually type the username when you run sudo, do you? That's because most of the time, the username can be gleaned from context. For example, "Which user is this process running under?".
So, if TouchID's purpose was just to supply identification and not any verification that the identification is legit, that would be pretty pointless.
I think the gp was alluding to an argument originally from this blog post [1], which posits that biometrics should only be used to identify, and should never be used to authenticate.
And I'd have to agree, fingerprints are a terrible substitute for a passphrase.
I agree. But my thinking is that touch id just shows who the person claims to be (like a username), but it doesn't actually authenticate they are that person.
I know that in practice apple does use it to auth.
TouchID sensor isn't that easy to fool with replicated fingerprints.
If you are afraid that some one will cut off your finger to unlock your computer don't use the touchID, that said if some one is willing to do that to unlock it i wouldn't want to imagine what they'll do to you to get the password.
Starbug (same guy who was the first to fool a Touch ID sensor) demonstrated that he could create fingerprint masks from press photos of a politician. See his very entertaining talk at 31c3: http://youtube.com/watch?v=VVxL9ymiyAU
It's a "something you are" authentication factor, since it is presumed that the cost of faking a fingerprint is too high to be worth it in those cases.
"He used $10 of ingredients you could buy, and whipped up his gummy fingers in the equivalent of a home kitchen. And he defeated eleven different commercial fingerprint readers, with both optical and capacitive sensors, and some with "live finger detection" features."
That article's a little old now and the tech may well have improved since but I wouldn't put too much faith in fingerprint readers. (Also: other attack vectors exist).
They (including Apple) told us once too often that their new fingerprint sensor will now really, really, finally solve all issues. With every new generation they tell us that all flaws of all previous generations have been solved. And once too often, they we proven to be wrong.
So I agree with zwp (not sure why he was downvoted):
I wouldn't put too much faith in fingerprint readers.
Yeah, I'm not an international spy: even if it is 'easy', nobody is going to spend a few hours faking my fingerprint just to get into my phone or my laptop. And if they are so motivated, then there's a much bigger problem at hand.
There are plenty of people still using 4 digit passcode (especially simple ones like 0000 or 1234) which is easy to 'steal' by watching somebody unlock their phone before pickpocketing them.
The bigger issue in my mind is revocation and separation of identities. I only have one set of fingerprints. What's more, I may not want my biological identity connected to online identities. It would be like having to give every website your SSN/National ID to identify yourself rather than merely a unique ID. You are giving out a huge amount of info with your fingerprint.
Now some of the above issues aren't specifically in play with this particular app: It's locally owned/controlled hardware only. Also, as you say most of us aren't international spies (though I do find that getting a bit close to 'I have nothing to hide').
As you point out, there's a right way to do fingerprints, which Apple did. Only the key pair stored in the secure enclave is tied to your online identity.
There is a missing link in the trust chain though, which is attestation of that secure enclave (how do we know it is a legitimate and uncompromised one?) However, privacy preserving attestation mechanisms such as DAA [1] require somewhat expensive crypto.
A sensible approach would be to have a master token which is unlocked using your fingerprint and used to generate one-time tokens for identification - perhaps like Apple Pay.
Lift the thumbprint off of the TouchID sensor itself? That is, assuming the premise of the grandparent comment is valid and fingerprints lifted off of the keyboard would be enough.
You only use your thumb on the space bar, and when you do, it's the side. But when you scan your thumb, it's the face of the print, ergo, impossible to lift thumb print from nearby key.
When done correctly, fingerprints are both something you are and something you have: The fingerprint data should reside in and work only to activate an HSM that then proves possession of an attested key pair. That way the HSM (and the device it sits in) is your something to have.
Could you setup your system to still need "something you know" when logging in, but use your TouchID for additional authentication (like sudo) once already in the system?
I certainly agree that a fingerprint is a much greater claim to an identity than a username. 'Casually' of course fingerprints work fine for auth, but fingerprints can and have been reproduced. Technology may alleviate that issue eventually, and you could argue that all auth methods have their issues.
The bigger issue I see is that 'rrmm' is an identity I assumed. I have many different identities. I only have one set of finger prints. (Fingerprinting to unlock a local store of keys would fix some of this problem, but I am fond of plausible deniablity in identification).
Fingerprints can be separated from their owner and fingers can be controlled by others. They are also duplicable, depending on the sophistication of the sensor.
No need for /s. That's a valid concern that gets mentioned often in discussions like this.
If a biometric sensor can be tricked by a body part that is no longer attached to the body, that's a serious issue. But AFAIK at least modern sensors try to verify if it's still alive and then there's also the biological effect that a body part quickly changes its properties if it is no longer supported by the body.
The biggest danger in that is probably criminals who don't know that it is likely that a detached body parts stops functioning.
The Surface line-up provides a similar feature for User Access Control (UAC) prompts via Windows Hello facial recognition (or the available fingerprint scanner for older Surfaces). It's a pretty slick and natural application of biometric authentication, and this seems a natural for Touch ID as well.
Well they did have login and fast user switching as an example, so that's kinda comparable and probably more practical, considering "people using sudo" is a subset of "people logging in".
Also, I like how you can compliment the feature yet still insult its creator in single sentence.
When an acronym/initialism is ambiguous, you can repeat the last word to make what you're saying unambiguous. ATM machine is easily distinguished from ATM mode. Similarly, you could say a LEO orbit to distinguish from a LEO officer.
No matter what, it's not nearly as bad as "The Los Angeles Angels" :-)
The original PAM RFC defines PAM as Pluggable Authentication Modules (plural – it’s the name of the framework and not one of its components), so it’s fine and more natural to say “PAM module”.
English isn't a programming language; it's OK if some of the things expressed commonly by natural language speakers aren't perfectly regular or logical, as long as everyone understands them. In this case, "PAM module" is totally understandable, and less ambiguous than just "PAM".
It's not as if every 3 letter acronym has one canonical definition. Googling a 3 letter acronym is almost impossible without adding at least one of the full words. The "ATM machine" pattern seems to me to be the most concise way of removing that ambiguity. It's interesting how language evolves.
Isolate your concerns and risks. There's no reason to drop into an interactive root shell for a single command, and your chances of forgetting your current privilege level and running the wrong thing are not insignificant.
What special "wrong thing" can root do? There might os level files that only root can edit or delete. I don't care about those. I can reinstall the os anytime if I should ever mess it up. All the value is in my data.
For most people, accidentally destroying various system files and "only" having to reinstall the OS would be considered a serious inconvenience.
If you want an example of something that could cause lasting damage, it's probably pretty easy to put your Apple product into a non-booting state by fiddling with NVRAM or PRAM settings as root. I'm not familiar with them off the top of my head, though.
If you were running your web browser as root, and a malicious website used a vulnerability to drop some malware on your system, then it would have complete power to do what it liked without needing to escalate privilege using another vulnerability.
Worse than destruction is undetected malicious modification. Say you decompress a specially crafted archieve which overwrites certain parts of the system enabling a backdoor. As a common user this would be blocked, but as root you'd probably not notice the malicious sideeffect.
When you're doing maintenance on a production environment which is serving hundreds or thousands of customers, in many cases you can't just "reinstall the OS anytime". Sure, ideally your environment is set up with redundancy and you fail over nicely, but still...
The `LocalAuthentication` framework this project mentions sounds like an OS X equivalent of PAM — an OS level account auth framework. I wonder why/if the `sudo` on OS X doesn't use it.