[HN Gopher] Use Touch ID for Sudo on Mac
___________________________________________________________________
Use Touch ID for Sudo on Mac
Author : syck
Score : 410 points
Date : 2021-03-01 12:31 UTC (10 hours ago)
(HTM) web link (davidwalsh.name)
(TXT) w3m dump (davidwalsh.name)
| zuppy wrote:
| Does anybody know if there's a solution for keychain password
| copy too? I have a very complicated vpn password that I change
| often (so I don't remember it), but each day, when connecting to
| the vpn, I have to open keychain and type my user password to get
| the vpn password. I couldn't find a way to use touch id for that.
| nikisweeting wrote:
| You can use your power button as a shortcut to autofill it from
| 1password or another password manager:
|
| https://docs.sweeting.me/s/power-button-password-manager-sho...
| hannibalhorn wrote:
| Kinda close - I use Hammerspoon to setup a hotkey that runs
| security(1) via popen to retrieve and paste passwords into some
| apps. /usr/bin/security find-internet-
| password -wgs mydomain.com
|
| It requires the keychain to be unlocked, which can be handled
| with touch ID, and you can have it confirm with a "are you
| sure" dialog box every time.
|
| If you really wanted to be prompted for a fingerprint basically
| every time, you could probably use a separate keychain that
| locks after 1 minute of inactivity.
| dylan604 wrote:
| Out of curiousity why do you change a complex password
| regularly? Is this something your evilCorp policy forces you to
| do, or something you do out of habit because of something you
| read on the internet, or even rote habit from something picked
| up at previous evilCorp policies?
| zuppy wrote:
| The evilItDepartmentPolicy forces me, but I would do it by my
| own will (less often) too, if not forced. I have acces on a
| lot of sensitive places and I don't want to risk it.
| dustinmoris wrote:
| > Since you expect to be be typing in a command line, moving your
| finger to touch the key is probably not very efficient.
|
| Why is this not very efficient? Isn't moving my finger to touch
| the key equivalent to a single key stroke? How is a single key
| stroke less efficient then many key strokes?
| jedimastert wrote:
| Admittedly I've never used Mac's implementation but I could see
| a slowdown if it takes longer for the fingerprint to register
| that it takes to type your password (which is probably the
| fastest combination of characters you can type)
| wtetzner wrote:
| Normally I can type my password faster than pretty much any
| other activity. But on my MBP (with the terrible keyboard) I
| never know if all of my keypresses registered (or if some of
| them were duplicated).
| austhrow743 wrote:
| If you're touch iding everything you normally password for,
| you can afford to have a less fast to type password.
| dustinmoris wrote:
| From my experience it's much faster. Just the tiny fraction
| of a second that it takes me to look at my caps lock key to
| verify that it's not on takes longer than my fingerprint scan
| and at that point I haven't even typed a single letter yet :)
|
| Also it's arguably not the fastest combination of characters
| I can type, because my password is not "test1234" and I don't
| get much opportunity to type it at all anymore since
| everything can be unlocked via TouchID except the terminal,
| or so I thought at least :)
| wtetzner wrote:
| > Just the tiny fraction of a second that it takes me to
| look at my caps lock key to verify that it's not on
|
| I always just re-assign the caps-lock key to CTRL.
| robertlutece wrote:
| CTRL when used as a modifier, escape on its own
| vincentmarle wrote:
| > it takes longer for the fingerprint to register than it
| takes to type your password
|
| You mean the black void where there's no feedback on how many
| characters you typed? I always have to write my password a
| couple of times to get it right.
| garettmd wrote:
| I think it depends a lot on how long your password is, as well.
| isatty wrote:
| Interesting, I hacked a small pam module together 4 years ago for
| the first generation of touch id enabled macbooks[0] and I wonder
| if pam_tid.so was always present and I just missed it. D'oh!
|
| [0] https://github.com/spaghetti-/pam-touchid
| sigjuice wrote:
| You missed it by just a couple of months or so :)
|
| pam_modules-159.50.4/modules/pam_tid/pam_tid.c appeared in
| macOS 10.12.4
| https://opensource.apple.com/release/macos-10124.html
|
| And macOS 10.12.4 was posted on Mar 27, 2017, according to
| https://support.apple.com/kb/DL1911
| softawre wrote:
| Doesn't seem to work with iTerm
| k_sze wrote:
| What happens when your Mac has multiple user accounts, some are
| admins and some are not, but all have Touch ID set up? Would that
| inadvertently give sudo power to users who shouldn't have it?
|
| (I don't have a Touch ID Mac to find out.)
| _joel wrote:
| No, it's bound to the user requesting sudo access.
| nikisweeting wrote:
| You can also use the Touch ID / power button as a shortcut to
| autofill a 1Password password:
|
| https://docs.sweeting.me/s/power-button-password-manager-sho...
| soheil wrote:
| You also need to remove the line below, otherwise, you'll be
| asked to authenticate twice using both methods:
| auth sufficient pam_smartcard.so
| djrogers wrote:
| Only if you currently have a smartcard configured. If not, you
| won't be.
| oezi wrote:
| Similarly for WSL2 using Windows Hello:
|
| https://github.com/nullpo-head/WSL-Hello-sudo
| superkuh wrote:
| You still have to provide a password. Fingerprints are not
| passwords. They are usernames.
| lenocinor wrote:
| Technically you are correct and I used to complain about this
| myself for years. But it seems like at least for consumers
| they're often content to have authentication equal
| authorization so I feel like mostly this battle has been lost
| in the consumer space.
| samatman wrote:
| This is correct only in the instance that a biometric is stored
| on the host.
|
| In TouchID, the biometric is stored only in the secure enclave,
| and is used to generate a private key signature, which serves
| as the password.
|
| Additionally, it's always possible to reset TouchID to an
| unauthenticated state, where it will refuse a fingerprint read
| until the password is typed in.
|
| There's no sense cargo-culting this bit of conventional wisdom
| without understanding where it comes from, and what sort of
| attacks it is meant to prevent.
| andr0x wrote:
| huh? fingerprints are not 'usernames' (you don't just provide a
| 'username' for an applepay authorization for example).
|
| and yes, adding this in you do _not_ have to type out your sudo
| password and can grant permissions using only touch id.
| bogomipz wrote:
| Does anyone know if similar can similar be done for Keychain
| access?
| wyuenho wrote:
| I wish there was a way to use the regular password dialog to sudo
| on older macs, and persist that credential just like the touch ID
| pam module does.
| ponyous wrote:
| Next step: SSH automatically paste password from
| Keychain/OnePass/LastPass after Touch ID.
| metafunctor wrote:
| Use sekey: https://github.com/sekey/sekey
| _joel wrote:
| Don't use passwords in SSH login at all and add your private
| passphrases to the keychain to unlock the key. The keychain can
| be unlocked with touch id
| ddalex wrote:
| How does SSH knows my password is **** ??!
| Galanwe wrote:
| As a side note, there's also the wonderful pam_yubiko module that
| allows you to require touching your yubikey to sudo or login.
| tomxor wrote:
| pam_yubico yes.
|
| You can also use this to secure SSHD on servers by delegating
| to PAM with keyboard-interactive.
|
| I'm waiting for U2F OpenSSH support to trickle down to stable
| distros but in the meantime pam_yubico is pretty damn good...
| not to mention you don't have to worry about terminal support
| since it relies on the yubikey OTP emulating a keyboard.
| sdoering wrote:
| wow... thanks for that. Didn't know that. Will need to read on
| that as well...
| sammorrowdrums wrote:
| Yes, use this on my Linux machine. Works seamlessly.
| ivrrimum wrote:
| Doesn't work on MacOS bigSur
| mdavidn wrote:
| Obligatory reminder: Don't run your text editor as root. Instead,
| try sudo -e /etc/pam.d/sudo.
| Simplicitas wrote:
| Author admits 'probably not very efficient', but still a great
| SHORT article to consider something interesting. Thanks
| nindalf wrote:
| I'm not sure about the "not efficient" part either. My password
| is 10+ characters, random alphanumeric with special characters.
| I sometimes mistype it. Whereas I'm yet to make a mistake
| tapping my finger on the finger print reader.
| macintux wrote:
| My current passphrase for work is 55 characters, so yeah, I
| could definitely see using this hack if I had to use sudo
| often.
|
| (I'll probably shorten it soon, but it's a slightly mangled
| lyric from a popular song, so it's easy enough to remember.)
| sigjuice wrote:
| What type of work or activity on macOS requires sudo repeatedly
| enough that it needs to be automated in this way? I mainly need
| sudo for the occasional dmesg or for adjusting routes after
| activating my VPN for work.
| lucideer wrote:
| Not that I install new software all that often, but macports
| requires sudo for quite a lot of operations.
| nunez wrote:
| Add this to your .bash_profile so that you always have Touch ID
| and Apple Watch support for sudo:
| https://gist.github.com/carlosonunez/5b67afb9fd720bef6385e94...
| okl wrote:
| I thought a fingerprint is to be used like a username and not as
| password?
| bitlevel wrote:
| The article will not allow sudo changes on Big Sur - at least,
| not without changing permissions of the sudo file first:
| 1. sudo -Si 2. chmod 644 /etc/pam.d/sudo 3. vi
| /etc/pam.d/sudo 4. Add the 'Auth sufficient
| pam_tid.so' line 5. chmod 444 /etc/pam.d/sudo 6. ...
| 7. Profit!
|
| Very handy tip though, thanks!
| philsnow wrote:
| s/vi/visudo/
|
| visudo will lint the resulting file and (should) reject the
| change if it would break your system.
| ArchOversight wrote:
| This isn't modifying the sudoers file, it is modifying the
| pam file.
| ivrrimum wrote:
| Still didn't work for me
| cprecioso wrote:
| I usually just `sudo nano` it, works fine
| mkskm wrote:
| `sudo --edit` also works
| mega_dingus wrote:
| Or when using vi, just use :wq!
| cyberge99 wrote:
| shift Z Z is faster.
| malobre wrote:
| Here comes the `:x!` clan
| rectang wrote:
| [offtopic] zoinks fam that's some next-level bikeshedding
| asidiali wrote:
| Debatable and depends on length of time shortcut has been
| in use. I can type :wq like a madman. My finger can slide
| straight from w to q, whereas with double-z, I have to pick
| my finger up and put it back down. So much movement! What
| next, you want me to run a marathon?
| exikyut wrote:
| I guess it's a learned dexterity thing.
|
| :wq = <move finger of right hand to Shift> <depress
| Shift> <move finger of left hand to ;> <press-release ;>
| <release Shift and move finger of left hand and press w
| and q>
|
| ZZ = <move 2nd finger of left hand to Shift> <depress
| Shift> <move index finger of left hand to z> <press-
| release z twice>
|
| As someone with mildly poor dexterity (and I don't touch-
| type with all my fingers, I mostly use my index fingers),
| the second approach looks somewhat more interesting to
| test.
| asidiali wrote:
| Interesting, I will add flexibility too, or maybe hand
| size. I find it slightly uncomfortable to hit shift and Z
| simultaneously with solely my left hand, so I hit shift
| with my right and z with my left. Alternatively, I will
| simultaneously hit shift + colon with my right, and then
| do the wq slide as mentioned above. Nice that all hands
| can be accommodated :)
| toyg wrote:
| That's all over the place from a touchtype perspective.
| 2nd finger? That's a pinkie. And you're supposed to use
| modifier keys from the opposite hand when available.
|
| So it should be <move right pinkie to hold right Shift>
| <move left pinkie to hit Z twice>.
|
| I honestly didn't know about ZZ, seems very convenient.
| :wq! on a qwerty forces the pinkie to travel all the way
| up to the top row, which is hell. On my home keyboard I
| use a layer for special characters, which helps, but
| still I guess I'll stick to ZZ from now on.
| nxpnsv wrote:
| This is going to save you seconds, every year!
| Florin_Andrei wrote:
| You are all wrong. The Emacs shortcuts are far superior.
| /s
| ed25519FUUU wrote:
| I've typed in :wq! so often I sometimes accidentally type
| it in when trying to do things like close browser tabs or
| exit programs.
| [deleted]
| zaphirplane wrote:
| I don't get it, the article shows it in 2 steps why the 5 step
| verbosity??
| philote wrote:
| It seems in Big Sur the file you need to edit is not
| writable. So you need to make it writable first, edit it, and
| then change permissions back to read-only.
| angulardragon03 wrote:
| This doesn't seem to be strictly true - the two-line
| solution worked exactly as expected for me on 11.2.1. I
| used nano instead of vi (personal preference), but it
| worked nonetheless.
| bitlevel wrote:
| Maybe that's the difference. I was using vi, and not
| nano.
|
| Have confirmed that using 'sudo nano /etc/pam.d/sudo'
| works fine.
|
| No need for the verbosity when nano works I guess. :S
| [deleted]
| helsinkiandrew wrote:
| :w!
| toyg wrote:
| :wq!
| MatekCopatek wrote:
| Was pleasantly surprised when Gnome on latest Fedora enabled this
| out of the box simply because the fingerprint reader on my laptop
| was supported.
| soheil wrote:
| Really surprising that Apple didn't include this by default.
| float4 wrote:
| Touch ID is awesome, but I semi-regularly use the APFS snapshot
| rollback feature and it erases my finger prints.
|
| Does anyone know why this happens? I was very happy when I found
| out APFS is CoW but it kind of sucks that restoring an old
| snapshot apparently erases the secure enclave in my M1 chip.
| dkonofalski wrote:
| More than likely because that's a security risk. If it didn't
| do this, an attacker could likely roll back your machine to
| before you had Touch ID set up and then roll it forward again
| to access your data, now without a Touch ID restriction.
| wil421 wrote:
| The system will notice changes and disable certain features. I
| noticed my Apple Pay stopped working after a restore and there
| are additional settings that can turn off Apple Pay. Such as
| allowing boot from an external drive.
| egberts wrote:
| no, No, no, noooo, please, God. Nooooooooooo.
|
| Biometric are non-revocable.
| dustinmoris wrote:
| Yes, it's terrible. Every time I walk through passport control
| and the person validates my identity through a biometric check
| by looking at my face and looking at my passport I cringe and
| tell them that it's terrible and they should instead let me
| type a password.
| egberts wrote:
| for things that you own, not for government-owned biometric.
| soheil wrote:
| You might need to make the file writable before editing it:
| sudo chmod +w /etc/pam.d/sudo
| nneonneo wrote:
| I just have a setuid root sudo binary (compiled from sudo-
| touchid: https://github.com/mattrajca/sudo-touchid) in my home
| folder ~/bin. This has worked a treat across OS updates, without
| hacking PAM stuff. It's extremely convenient and has probably
| saved me cumulative hours in typing out my long password :)
| cprecioso wrote:
| This is amazing -- but every. single. update. disables it again
|
| Why does the sudo file not persist between updates? This case is
| quite minor for personal computers, but what about companies that
| log in with yubikeys or smart cards? Do they have to reconfigure
| after every update too?
| amrrs wrote:
| Did this work on iTerm?
| zzzmarcus wrote:
| Yes
| m463 wrote:
| Apple needs a solution to this.
|
| People getting their pf rules thrown away each time - it is
| like unlocking your front door each time you run the vacuum
| cleaner.
| beyondcompute wrote:
| I've just added this to my .bash_profile:
| enable-sudo-touchid() { sudo sed -i -e '1s;^;auth
| sufficient pam_tid.so\n;' /etc/pam.d/sudo }
|
| But probably automating the check (if the automated checker has
| the correct permission) would not be that hard.
| jmarcher wrote:
| A step further so you don't have to think about enabling it:
| sudo() { unset -f sudo if [[ "$(uname)" ==
| 'Darwin' ]] && ! grep 'pam_tid.so' /etc/pam.d/sudo --silent;
| then sudo sed -i -e '1s;^;auth sufficient
| pam_tid.so\n;' /etc/pam.d/sudo fi sudo "$@"
| }
| mkskm wrote:
| Here's another function in Fish that incorporates the other
| suggestions offered in this thread.
| function sudo --description "Execute a command as another
| user." if [ (uname) = "Darwin" ]
| set --local needle
| "^auth\b.*\bpam_\(reattach\|tid\|watchid\)\.so\$"
| if ! grep $needle --silent /etc/pam.d/sudo && \
| [ -f /usr/local/lib/pam/pam_reattach.so* ] && \
| [ -f /usr/local/lib/pam/pam_watchid.so\* ]
| command sudo sh -c " cat << EOF
| >/etc/pam.d/sudo auth optional pam_reattach.so
| auth sufficient pam_tid.so auth sufficient
| pam_watchid.so \$(grep -v '$needle'
| /etc/pam.d/sudo) EOF"; or return $status
| end end command sudo $argv
| end
| beyondcompute wrote:
| Thanks! That looks good!
|
| Thought on the second thought, I'll continue to use the
| more "manual" method for now. As it gives me more control
| and it would be easier to switch off when touch ID sudo
| will be supported more officially.
| ed25519FUUU wrote:
| The hard part with these kinds of fixes is that they evaluate
| every time you create a new shell or tab, which for me is
| very frequently.
|
| It's already starting to add noticeable latency from all of
| the various eval statements in there.
|
| Edit: I missed it's a function def which should be fine speed
| wise.
| fwip wrote:
| That's a function definition, the only overhead will be
| parsing, not evaluation.
| ethanpil wrote:
| Why not run a launchd script on boot that does the update?
| Does it need to be in the .bashrc?
| jeffbee wrote:
| This is a very macOS problem. Why does it reset every
| preference on updates? The one that kills me is wake-on-lan,
| that gets turned back on regardless. Hate!
| derefr wrote:
| Because, like ChromeOS/CoreOS, modern macOS now does image-
| based updates.
|
| A macOS update isn't "whatever was previously on your OS
| volume, plus arbitrary patch X"; rather it's "a new, fresh OS
| disk image, written to a separate APFS volume, with a fixed
| SHA, with update transfer-size optimized by _composing_ said
| image partially from files in your current OS, but only in
| such a way that the volume will still hash the same in the
| end."
|
| (In many ways, macOS's update system now reuses the logic
| from iOS's IPSW firmware-update system. You can even now
| download macOS updates from Apple _as_ IPSW files, and then
| use Apple Configurator to push them to macOS devices.)
|
| Unlike ChromeOS/CoreOS, _after_ the first-round SHA
| verification of the volume, macOS will then _patch_ the new
| OS-base-image volume with certain files from your current OS-
| base-image volume, if 1. they're distinct from the ones it
| expected to be there, and 2. they appear on a whitelist of
| known-safe files.
|
| If any of this patching happens, the OS volume's metadata
| tree will then be re-hashed, and the new hash will be blessed
| by the volume-signing utility.
|
| (If you've seen a "Recovered Files" directory on your desktop
| after an update, and it's contained a "foo.system_default"
| file, that's a copy of the file that macOS _would have_
| composed into the OS volume if it hadn't found your known-
| safe customized file to use instead. /etc/shells is a usual
| trigger.)
|
| _Some_ preference files in /System/Library are known-safe;
| but others aren't. It's a whitelist, and it's a conservative
| one.
|
| Preference files in /Library live in the user volume, not the
| OS volume, and so will never be wiped. This is why most of
| the "trivial" preferences stick around.
|
| Note that by "known-safe" here, I don't mean "can't be
| customized to malicious ends." This isn't a security thing.
| It's an ABI stability thing. These files are safe in that
| they're known to _have the same ABI format between OS
| versions_ , and so keeping a customized version of them
| around won't confuse newer versions of system daemons.
|
| It's about the same as if Linux had a set of known-safe DKMS
| modules that use interfaces that the kernel intentionally
| doesn't change between releases, such that the kernel module
| files composed from those DKMS modules could be reused by the
| new kernel without requiring decompilation, rather than being
| tossed out at every single kernel update.
| curt15 wrote:
| >Unlike ChromeOS/CoreOS, after the first-round SHA
| verification of the volume, macOS will then patch the new
| OS-base-image volume with certain files from your current
| OS-base-image volume, if 1. they're distinct from the ones
| it expected to be there, and 2. they appear on a whitelist
| of known-safe files.
|
| Red Hat CoreOS (and other Linux systems managed with
| OSTree, such as Fedora Silverblue) now do something similar
| by merging the current /etc directory with the "upstream"
| version.
| IgorPartola wrote:
| Debian based systems use dpkg which has the option of
| confold and confnew. Difference is that the default is to
| ask the user what to do and unattended upgrades default
| to confold.
| jwiley wrote:
| This is great info I've never seen referenced elsewhere. It
| would be awesome if you would write a blog post explaining
| this in more detail!
| IgorPartola wrote:
| This is an excellent explanation. One last piece to
| clarify: there is no way to edit the known-safe list, is
| there? And/or there is no way to add a script after the
| update process that copies files like this, correct?
| jeffbee wrote:
| The thing that doesn't make sense here is that macOS
| discards randomly your settings, but it is also the only OS
| I use that regularly gets in a fucked up state where
| settings have to be nuked. I mean, here we are in year 37
| of the mac and people are still zapping their PRAMs. The
| only improvement is you don't have to physically pull out
| the battery.
| chipotle_coyote wrote:
| Purely anecdotal, of course, but:
|
| - If macOS is the only OS that you use regularly that
| gets in a fucked up state, then either you're not using
| Windows or it's gotten a lot better in the last few
| years. :) (I mean, it undeniably _has_ gotten better, but
| I have Windows-using acquaintances who still kvetch about
| this issue pretty regularly.)
|
| - I've been using Macs since 1999 and I don't think I've
| had to reset the PRAM to fix a problem since my Titanium
| MacBook Pro circa 2007. I've had to nuke _other_ settings
| on occasion, but still generally have markedly fewer
| problems than I did in my Windows-using days. (Which were
| more recent than 1999, but still not that recent, so back
| to the "I'm sure it's better now" disclaimer.)
|
| But, Apple definitely needs to have a better mechanism
| for managing config file updates than "yeah, we've put a
| few old config files in subfolders of this
| 'RecoveredFiles' folder, maybe they're useful, maybe
| they're not, good luck."
| lispm wrote:
| In year 37 you can't manually zap the 'PRAM' on Apple
| Silicon Macs.
| jeffbee wrote:
| True, but I guess 95% of mac users are still on Intel
| macs, are still being told by "genius" bar frontline
| support to reset the SMC / zap PRAM for any kind of
| issue, and this usually works, too. Jury is still out on
| whether the M1 auto-zapping architecture is better, or
| will just be more prone to being permanently messed up.
| easton wrote:
| Well, the fact that nobody ever has to zap PRAM on an iOS
| device means that they've probably fixed that (or, since
| you can't zap PRAM anymore, people just restore the
| device instead...)
| wizzwizz4 wrote:
| > _but it is also the only OS I use that regularly gets
| in a fucked up state where settings have to be nuked._
|
| Windows gets into this state fairly quickly, too, but the
| failures are less dramatic so we just live with it.
|
| At least with Debian, it only happens when I
| _deliberately_ change stuff! Though the `xorg-server-
| video-intel` driver _breaks_ features of post-2007 Intel
| cards, and it 's installed by default, so... perhaps it
| isn't the perfect OS either.
| samstave wrote:
| Why cant Apple use their TimeMachine tech to take a
| snapshot of the prefs on the existing, then do their image
| based update, then have it automatically apply the prefs
| from the timemachine mod-integration?
|
| The richest company in the world can't think different?
| olyjohn wrote:
| Just my opinion here, but I feel like Apple again doesn't
| really care about power users. 98% of their users won't
| be making any customizations like this, so they don't
| care to spend money working on those "edge cases." Their
| primary mission is to sell devices and apps to average
| people who aren't tech geeks. And I don't think Apple
| cares about general purpose computing. I see MacOS
| getting closer to iOS with every update, and I'm betting
| that at some point we'll lose filesystem access and sudo
| access.
| samstave wrote:
| Have you ever been FORCED to upgrade/update against your
| will for a new release whereby you say NO NO NO - then
| you make the mistake of falling asleep with your phone
| plugged into the charger to wake to a forced update to
| your device?
|
| Yeah - fuck apple - and fuck Jonny Ive - they claim to be
| the masers of all aspects of designs, but really they're
| they masters of /r/assholedesign
|
| Their hardware is in the top 70th % - but their UX is IMO
| <25%
|
| (just look at how many clicks you need to do certain
| tasks, such as bluetooth. They have a slide-up menu to
| toggle BT and WIFI - but you have to go to
| desktop->settings->bluetooth->(toggle it on
| off/refresh)->find the device-> "cant connect" - Toggle
| BT on both phone and device -> attempt to connect...
|
| But you cant up-swipe hit BT and have it show you the FN
| menu on screen.
|
| You cant backup and manage all your prefs via icloud -
| such that you can apply profiles, save profiles, etc from
| your device to your linked cloud account and say "I
| always want my privacy to be thus, these are the networks
| I trust.
|
| Their photos library mgmt is absolute garbage. You have
| no photo details available to you.
|
| Their albums are garbage.
|
| There are so many interactions that require like 5x more
| clicks than they should.
|
| Their screens suck.
|
| Their device accessory ecosystem sucks and punishes you
| for profit with impunity.
|
| They exploit chinese slave labor.
|
| They try to charge you for flaws in the HW provided
| (recall the balloon battery problem?
|
| I had a macbook pro CATCH FIRE while I was asleep in bed.
| They said they "recognize that was a safety problem, but
| because our engineers (after two months of having the
| machine) determined that at one time the liquid sensor
| was set off, we cannot replace your machine EVEN THOUGH
| IT WAS UNDER RECALL FOR THE CLASS OF PROS THAT WERE
| RECALLED FOR CATCHING FIRE.
|
| FUCK APPLE.
| orf wrote:
| That's a lot of anger and words over something that, in
| the grand scheme of things, is so utterly unimportant and
| almost contemptuously irrelevant.
|
| Things are always a trade-off. There are big positives to
| keeping the ecosystem on a consistent, new and secure
| version of iOS. Similar positives apply to MacOS.
| wizzwizz4 wrote:
| Maybe the first point or four. The subsequent ones? They
| actually seem pretty serious.
| samstave wrote:
| The problem I have with your argument, is you assume that
| my frustration is just over a single device from Apple.
|
| I have literally had every single apple product since the
| Apple ][e -- aside from their server systems.
|
| I have had every iPhone (even had pre-launch phones from
| them) since launch up until I stopped at the 6s+ which is
| the only phone I will ever own from them.
|
| I have a history with apple that is not shallow and I
| have had ~35 years of judgement against them.
|
| I recall getting into a talk with a fellow engineer at
| Lockheed where I said "Trust me, Apple will switch to
| intel procs - and this apple boi almost had a heart
| attack saying that would NEVER happen...
|
| https://en.wikipedia.org/wiki/Mac_transition_to_Intel_pro
| ce ssors
|
| Yeah that happened ~2 years before it actually occured...
|
| (I used to work for intel and have stories about trend
| prediction there as well...)
|
| So yeah, I'm solid in my position of what I know to have
| happened...
| derefr wrote:
| They know exactly what files were customized in the
| previous OS-base-image. There's a reason the whitelist is
| a whitelist, rather than a blacklist. Just guessing here,
| but it's probably something to do with "iteration speed"
| vs. QA SLAs made to large enterprise customers like IBM.
|
| In my hypothetical, there's a set of preferences
| overrides Apple have been forced by contract to guarantee
| they'll validate during their QA process, and then allow
| the OS to retain between updates. For any other file
| _not_ forced by contract, they _don't bother_ with that
| QA process ("takes too long!"), and so default-distrust
| the ABI-stability of the file, and so don't let the OS
| retain it between updates.
| [deleted]
| Demigod33 wrote:
| What if one file was written by a malicious program?
| azinman2 wrote:
| Ya I think saying it's not for security is making a lot
| of assumptions.
| samstave wrote:
| You know =what would be cool: If all apps had to register
| their pref config files into a single dir and that would
| be tracked and snapshotted - and then you could just have
| ALL apps look to the same dir for where their configs
| come from and you could have a single repo for ALL apps
| on your or ANY system - and then you could walk up to a
| terminal and plug in your "license key" which said what
| apps you had access to and what ones you had configs for
| and you could just run that app with all your input and
| prefs and mappings etc...
|
| I actually wrote a white paper on just this in ~2003 or
| so - and met with several engineers from google and they
| said it was impossible.
|
| The idea being that you only carried around with you your
| profile, and you could just come to a dumb terminal, plug
| in your key, three factor auth - and the terminal would
| give you access to the apps and resources they had...
|
| (I should write ((again)) a short story on this)
| unilynx wrote:
| This was basically the idea behind the Windows registry -
| a single configuration store. With mostly the same tree
| structure on Machine and User level, so your local prefs
| could override machine-level prefs. The 'user' part was
| portable between machines on a domain. And you have a
| single API to access or change settings
|
| Opinions may differ on how well it was executed in
| practice. I'm not sure /etc/ with its hundreds of
| different file formats and Ansible or Chefs as an 'API'
| is that much better
| derefr wrote:
| > This was basically the idea behind the Windows
| registry.
|
| Was it? I got the impression that the original (Windows
| 3.1) registry was a Windows-internal thing--a store of
| _Windows_ settings, and a set of APIs to read and modify
| those _Windows_ settings, e.g. COM /OLE class
| registrations. (See https://devblogs.microsoft.com/oldnew
| thing/20080117-00/?p=23...)
|
| But then, third-party ISVs found the registry, and
| exploited it to store their own settings. And Microsoft
| being Microsoft, they accepted that unilateral design
| change and continued on with it.
| Demigod33 wrote:
| > they said it was impossible
|
| What reasons did they name?
| samstave wrote:
| OK, disclaimer - I am going on over a decade since this
| happened:
|
| There was a phone that came out (nokia??) that had a
| docking station and you could have a screen on it and a
| keyboard attachement etc...
|
| I presented this in ~2004-ish as a white paper... (lost
| to hundreds of machines since, and poor data mgmt over
| time)
|
| I met with a few engineers friends from google over this
| idea and they said they didnt think it was possible
| (which at the time it was not - even though I wrote about
| it in 2001) - and then there was that phone that came out
| which allowed you to have a phone docking station and use
| it as your primary computer.
|
| This was at the same time whilst I was talking to my
| buddies at Intel about stacked procs - and they were
| doing 64 cores in ~2004 in test dies... and they worked.
|
| It was in 1998 when I was at Intel that I asked "Why cant
| we just stack multiple CPUs on top of eachother?" and was
| laughed at...
|
| I sat right next to Andy Grove, but I only spent all my
| time in the DRG Game lab testing games on AMD and Celeron
| procs to get subjective results on game perf.
|
| Anyway... I posed a lot of things that were laughed at,
| which then became reality later.
|
| I worked with a MIPS proc eng about Slot-Rack-Servers, in
| 1995 - this was deemed impossible... later we have HPE
| based systems... His name was Kent... he was one of the
| chief MIPS designers...
|
| I was saying "lets make 'slots' that we can install a
| switch, a server, storage or whatever on the
| backplane..."
|
| Yes - I am not lying - these were just things I imagined
| in the early-mid-late 90s....
|
| I had a good career - but I cannot take any credit for
| these taking production due to I didnt ever implement any
| of these ideas... aside from expressing them earlier than
| others who were far more capable of executing.
|
| Its just like IFTT - I literally whiteboarded IFTT for a
| bunch of engineers from Lockheed a few years before that
| existed... They have built a lot of what you interact
| daily with (netflix) among others...
|
| My soul flaw - is that I think of something early, I have
| no ability to bring it to fruition and even though I have
| exceptional famous engineers as friends, I cant bring my
| ideas to market...
|
| and then a few years later - things I designed hit the
| zeitgeist and hit market...
|
| I have, as a consultant, made people MANY billions of
| dollars - and havent received anything in return.
| derefr wrote:
| You already have to reboot into the Recovery environment
| and disable both System Integrity Protection (with
| csrutil) and OS root-volume signing (with bputil) in
| order to even (persistently) modify any of the files in
| /System now.
|
| Malware can't do that, because there's no way for any
| executable that runs in the regular OS--and isn't signed
| by Apple--to get anything to automatically happen over in
| the Recovery OS.
|
| (That's not to say you can't have persistent malware in
| macOS; just that it can't persist itself into the OS boot
| volume. It has to persist into the user volume--which is
| great, because that means the OS can, on boot, mount the
| user volume noexec and scan it for malware while running
| in a known-good base state. That's even _without_ needing
| to boot into the recovery OS.)
|
| So, other than OS updates, basically the only reason
| these files get modified is when people modify them
| manually. And the only people doing that are 1. people
| developing kernel extensions (or their friends, the
| Hackintosh community); and 2. enterprises burning low-
| level configuration changes into OS images for image-
| based deployment.
|
| And both of those cases involve modifying things that are
| effectively "underneath the OS API abstraction", and
| therefore don't have the same ABI guarantees that the OS
| APIs themselves do. Thus the whitelist.
| Demigod33 wrote:
| Thorough explanation, thank you.
| nullserver wrote:
| Back in the day I used to tweak my Linux box, win3.1/95, vim,
| android phone, etc. endlessly.
|
| After awhile they would all become unusable, and I would
| reinstall everything back to default and try again. Great for
| leaning, lousy for day to day work.
|
| Resetting things back to a known state can make life lot
| easier.
|
| In 10 years I can't recall needing to reset a Mac.
| Daho0n wrote:
| Because it does so itself. It is even worse to have lost
| settings than having windows rot. At least in Windows rot
| is the problem, not the fix.
| TheKnack wrote:
| It may be an unintentional side effect, but doing this may
| prevent some degree of "Win rot", which Macos (and iOS) has
| also suffered from to a degree in the past. A huge number of
| mysterious iOS and Macos problems are caused by an
| accumulation of issues when config files of various types are
| "upgraded" along with the OS from one version to the next. If
| you look at all of the minor and major versions that come out
| in a year, small issues become large issues after being
| compounded by a couple of dozen updates.
|
| There was an issue with iOS a few years ago that caused
| higher than normal battery drain when I was managing a
| department that supported a lot of iOS devices. A lot of
| users thought they needed a new battery. The battery drain
| issue was resolved for 100% of our users by doing an "Erase
| all data" and NOT restoring the backup. This process will
| still fix an amazing number of weird iOS issues in 2021,
| especially issues with the device slowing down, getting hot,
| or draining battery. It works because you end up with default
| config files that were designed for that version of the OS.
| If you restore the backup, often it will "restore" the
| problem you were trying to fix because the iOS restore
| process puts some OS config files back.
|
| It will be interesting to see if Macos becomes less
| susceptible to win-rot type issues because of this config
| file reset behavior, as annoying as it may seem.
| ktapcnbje wrote:
| Does `sudo chflags schg /etc/pam.d/sudo` work?
| yrro wrote:
| Does OS X not have /etc/sudoers.d?
| bmurphy1976 wrote:
| It does, but this is a PAM configuration, so I'm not sure how
| /etc/sudoers.d would help...
| yrro wrote:
| Good point! :)
| draugadrotten wrote:
| curl -sL
| https://gist.githubusercontent.com/RichardBronosky/31660eb4b...
| | bash
|
| This helps.
| IncRnd wrote:
| Seems secure.
| envy2 wrote:
| This "download random script from internet and execute" thing
| is a terrible idea, even moreso to put in bash_profile...
| throwaway8581 wrote:
| What exactly is the point of sudo/UAC these days of single-user
| machines? I think https://xkcd.com/1200 put it well. Anything
| running as an unelevated user account can access my browser
| sessions where it can steal my passwords, emails, other other
| private info. It can turn on my microphone and camera. It can
| read all of my documents. Those are the things I care about
| protecting, not whatever special things root can do like install
| drivers and create virtual network interfaces.
| antonio-ramadas wrote:
| Having the ability to use Touch ID for sudo is handy. I've been
| using it for a while.
|
| Coupled with `expect` I use it to authenticate through SSH (that
| is the only feasible option I got to connect to hosts I've got
| limited access). I even wrote about it: https://antonio-
| ramadas.github.io/blog/2020/10/30/ssh-login-...
|
| Here is the gist of it: #!/usr/bin/expect
| # Connects via SSH to the host passed as argument
| set timeout 60 set server [lindex $argv 0] set
| username <USERNAME> set password [exec sudo cat
| <PATH_TO_YOUR_PASSWORD_FILE>] spawn ssh
| $username@$server expect { "yes/no" { send
| "yes\r" ; exp_continue } "\*?assword" { send "$password\r"
| } } interact
|
| Edit: Please remove all permissions from the password file with:
| chmod a-rwx <PATH_TO_PASSWORD_FILE>
|
| I'm also assuming you run this script on an environment you
| control and trust. Be wary of your password.
| 7ewis wrote:
| Make sure you put it at the top, added it to the end... caught me
| out. (It asks for both)
| PureParadigm wrote:
| For my accounts I usually just allow sudo to work without
| prompting for password by using the NOPASSWD configuration
| option. This saves _a lot_ of time if you need to use sudo
| frequently (in my case I use it for system upgrades).
|
| Unless I'm missing something, the security cost of this should be
| negligible, especially if you're in the habit of locking your
| computer screen when you're not using it (and this typically
| happens by default after a few minutes even if you forget). And
| if you're relying on the sudo password prompt to protect you
| against untrusted scripts, I'd argue you have bigger problems.
| toxik wrote:
| This is absolutely terrible advice!
| PureParadigm wrote:
| Can you explain why? I'm genuinely curious in case I've
| missed something!
| madjam002 wrote:
| I'm guessing they meant because malware can now run
| commands as root without prompting for a password, however
| I'd argue that if you have malware running as your user in
| the first place then that will likely be more damaging to
| you than it getting root and modifying your system, as it
| will be able to access browser session cookies, personal
| documents, etc.
|
| Personally I don't have passwordless sudo but I'm also
| curious as to what the attack vector might be here if you
| were to enable it.
| metafunctor wrote:
| If you run things under tmux, you'll also need this:
| https://github.com/fabianishere/pam_reattach
| antihero wrote:
| Ah, thanks! Was wondering why it wasn't working in tmux.
| parhamn wrote:
| This made me realize my usage of sudo has gone down quite a bit.
| It seems like things mostly get permissions right these days,
| brew and ports were the main culprits back in the day.
| eyelidlessness wrote:
| I was thinking the same thing. Since I got my MBP16 I think the
| only times I've typed a password at all have been when the
| Touch ID session expires or whatever it is that requires
| reauth.
| rmathot wrote:
| Using biometrics instead of a secret-based authentication is
| always a bad idea.
|
| Secrets can be changed easily when they get compromissed, your
| figerprints/iris/whatever cannot.
|
| https://www.csoonline.com/article/3330695/6-reasons-biometri...
| jrockway wrote:
| On the other hand, you can't type your fingerprint into a
| random link that you receive in your email.
|
| I think modern devices that use biometrics to unlock a secret
| key are different from the old-school case of biometric
| authentication. If someone is storing a picture of your
| fingerprint, then of course they can replay that to impersonate
| you. But that's not what TouchID is doing -- it's just a chip
| that will only give up the private key if it detects your
| fingerprint. You have to have physical access to that chip, and
| a finger analog that will fool the chip into giving up the
| secret key, and then you can use that key to compromise things.
| But if you detect that, you just revoke the key, get a new
| device, and are good to go.
|
| I don't have a great analysis for sudo. You want root on MacOS
| to do something like install a long-term compromise. Your
| regular user account already has your GMail session cookie and
| bank information, so sudo isn't really good for anything else;
| if you leave your unlocked laptop around somewhere, your
| Internet life is over. But if someone physically steals your
| finger so they can gain access to sudo and install a keylogger
| or something, you already know you're compromised -- your
| laptop and finger are gone, so you know something's up,
| defeating the purpose of a long-term compromise.
|
| This attack can't be done remotely; if someone sshs to your
| laptop and wants to sudo, they can't just take a picture of
| your fingerprint and upload it... they have to physically touch
| the sensor on your laptop.
|
| Overall, I think biometrics like TouchID / FaceID / U2F /
| WebAuthn are strictly better than passwords. They are super
| convenient. They can be revoked. They can't be phished. That's
| a huge win over passwords.
| dustinmoris wrote:
| How often has your mother given money to someone else who
| pretended to be you? Because parents identify their children
| through biometric authentication. They look at you and can in a
| matter of split seconds verify that you are actually you.
| Biometric authentication is the oldest and most sophisticated
| form of authentication. I can enter my work place and nobody
| asks me to type in a password at the door because the staff can
| immediately identify my identity by simply validating my face
| with their own eyes. It's incredible, trust me.
| emidln wrote:
| Your mother doesn't view you through a 0.3MP camera in a
| dimly lit room with no flash when deciding if the person in
| front of her is her child.
|
| Further, if I take a high resolution photo of you, and then
| go to your mom and ask for money by presenting her the
| picture, she won't accept that picture as proof that I am you
| (although she may suspect I'm blackmailing or otherwise
| threatening you). This, moreso than qualms about the
| resolution/quality of the sensor is the GP's point. If the
| sensors are accurate, that specific set of bits that is
| translated as your fingerprint will not change. If someone
| knows those bits, it's extremely likely they can convince the
| sensor they are you. From our example, once I have your
| picture, I can tell your mother I'm you--and she'll believe
| me!
| dustinmoris wrote:
| So your qualm is low quality biometric scanning, not
| biometrics itself? So we agree that biometrics are the most
| secure form of authentication and we are only debating on
| the quality of the technology, which we know is getting
| better day by day, yeah?
| emidln wrote:
| > Further, if I take a high resolution photo of you, and
| then go to your mom and ask for money by presenting her
| the picture, she won't accept that picture as proof that
| I am you (although she may suspect I'm blackmailing or
| otherwise threatening you). This, moreso than qualms
| about the resolution/quality of the sensor is the GP's
| point. If the sensors are accurate, that specific set of
| bits that is translated as your fingerprint will not
| change. If someone knows those bits, it's extremely
| likely they can convince the sensor they are you. From
| our example, once I have your picture, I can tell your
| mother I'm you--and she'll believe me!
|
| You skipped the second paragraph, so I helpfully requoted
| it.
| GranPC wrote:
| It rather sounds to me like you have run out of
| arguments.
| djrogers wrote:
| > is always a bad idea.
|
| Making sweeping generalizations about something as complex as
| information security is always a bad idea.
| [deleted]
| gumby wrote:
| As the author says, "Since you expect to be be typing in a
| command line, moving your finger to touch the key is probably not
| very efficient."
|
| I was excited to set this up when the first fingerprint sensor
| macs came out. Within a couple of days I'd switched it off. It is
| quite inconvenient and especially bad if you use an external
| keyboard.
| xoa wrote:
| It still strikes me as weird that Apple went with Touch ID vs
| Face ID on the Mac. Computer form factors in general, and
| particularly notebooks and AIOs, should be perfect for Face ID:
| the user is always at a good distance, in the right position,
| looking at it, and as you say will frequently have their hands
| otherwise occupied actually controlling the system. For that
| matter a Face ID+iPhone-quality camera thing for Macs that
| could attach to an external monitor would be a pretty useful
| value-add, and it would equalize things across all Macs meaning
| it could be depended on more. It's remained really perplexing
| that year after year when Apple left Touch ID far behind on iOS
| they haven't installed Face ID where it'd be even better. I
| assume this is mainly another one of many symptoms of Apple
| just not being able to multitask very well and the Mac not
| really getting that much concerted attention.
| gumby wrote:
| > It still strikes me as weird that Apple went with Touch ID
| vs Face ID on the Mac
|
| BTW the face system is so automatic on the phone that I don't
| think I'd want it for much beyond login. The flow-breaking
| reminders when installing apps and the explicit requirement
| of typing sudo are good ways to require deliberate intent for
| dependent risks. Login, App Store purchases and the like
| would be OK by me if controlled by face.
|
| All that being said: the Mac camera remains astonishingly
| terrible (see a recent HN front pager about how bad webcams
| are in general). Not just low resolution but poor white
| balance etc. I am not sure it's been upgraded in the last
| decade.
|
| There is much speculation as to why (no room in the lid,
| which is plausible); I feel like for some reason this is an
| issue on which they simply don't care for some reason as they
| make a lot of fuss about the changes in speaker and
| microphone. Perhaps it simply is good enough, based on the
| innumerable Zoom calls I've been on.
|
| Face ID needs more than a better camera, it also needs an IR
| channel. I do expect that when they finally do get around to
| upgrading the camera system they will jump ahead to something
| like the iphone front facing system.
| marcinzm wrote:
| I suspect the main reason is that the face-id camera module
| is too thick and they'd need to increase the thickness of the
| display casing. If there's on thing the Mac designers will
| never allow it's a thicker laptop.
| xoa wrote:
| Based on iFixit's iPhone 12 teardown and thus the most
| recent version of the module, I think they might be able to
| get it into the screen without much compromise. An
| important consideration here is that it's not just about
| the Face ID bit, it's about the better camera bit. While it
| was important even earlier, this past year has made
| videoconferencing and other remote work rocket up in
| priorities, and Macs suck pretty badly by modern standards
| in terms of camera quality. It's a big, by definition both
| very visible and very _social_ feature (because everyone
| else in the conference can see how good /bad you look). I
| think that might be a motivation for Apple that Face ID by
| itself wouldn't have.
|
| However that aside, thickness concerns don't apply a single
| bit to the iMac or to a standalone (Mac only) module (or
| even integration in Apple's ultra fancy display), so that
| objection doesn't cover the spectrum of Macs.
| djrogers wrote:
| The current thickness of the MacBook lid (my 16") is
| <3.5mm, and the faceID module is >3.5mm. Given that you
| need glass and metal in that 3.5mm as well as the faceID
| module, you're talking about significantly changing the
| dimensions of the MacBooks to do this with today's faceID
| module.
|
| I look forward to the day they do get it fit in there
| though (hoping that the Silicon redesign allows for it)!
| gumby wrote:
| > It's a big, by definition both very visible and very
| social feature
|
| But you only see _yourself_ as a thumbnail so the
| feedback is quite lossy.
| ncrmro wrote:
| I feel like it's only a matter of time
| nikanj wrote:
| Less likely to accidentally fool you into tapping the finger
| sensor vs fool you into showing your face to the camera
| xoa wrote:
| Could say the same thing about iOS, and this is a silly UX
| complaint anyway. Apple could easily offer or require some
| purposeful interaction using mouse/keyboard along with Face
| ID and it'd still be a nicer UX.
| jaywalk wrote:
| Not sure how "fooling" comes into play. Only trusted
| applications can request to use Touch ID/Face ID in the
| first place. It's not like there's a way for a random
| application to just say "Scan your face and let me take
| over your machine"
| nikanj wrote:
| Exploits do happen, and to me it sounds reasonable that a
| web page gets local unprivileged code execution -> sudo
| (which is a trusted application) -> my face was already
| in front of the camera -> root.
|
| I guess this could be circumvented with a "click OK if
| you agree to get face ID" dialog or similar. Anyway, you
| need to figure out a way to deal with the "key" always
| being in the lock if you're using face id on a laptop.
| gumby wrote:
| One point is that the touch prompt is "out of band": it
| shows up in its own window. Some other app could open
| that request while you're looking elsewhere then yiu type
| sudo, look up, see it (without focus), so click it and
| then put your finger on the sensor. When your sudo
| remains blocked you see the other, click I, and proceed
| under the assumption it was a glitch.
|
| Sounds complicated but is actually quite plausible. And
| worse under face I'd as it would be more seamless. iOS is
| different as the user interface is largely single task
| (slightly less under ipad) and background tasks that need
| face ID need a notification and explicit selection to get
| it
| ctur wrote:
| Every update requires you to redo this. It's so repetitive that I
| keep a copy of what I want `/etc/sudo` to look like in my homedir
| and, whenever I get the prompt for a sudo attempt, I instead sudo
| to cp the file. Then I go on my way with what I was originally
| intending.has recently sudo'd.
|
| Rote but effective.
| ethanpil wrote:
| Why not run a script on boot that does the update? Does it need
| to be in the .bashrc?
| danielyaa5 wrote:
| BTW if any of you accidentally corrupted the file like me, this
| fixed things for me
| https://superuser.com/questions/1368246/accidentally-added-a...
| fluder wrote:
| And with every macOS update you should do it again and again.
| Just another not useful tip.
| smolyeet wrote:
| its not like you update everyday, once a month seems like a
| fair trade if it's convenient.
| deergomoo wrote:
| I disagree that it's not useful--I have a really long password
| and suck at typing, so being able to mash the fingerprint
| sensor is really helpful.
|
| But yes, it is very frustrating that every time there's a
| system update you have to redo it.
| aequitas wrote:
| Or just use Puppet to manage your macOS installation which
| makes things a lot easier ;)
| fluder wrote:
| Puppet on every minor update?
| rvz wrote:
| Very handy. But you can use your Apple Watch for sudo which is
| even better: [0]
|
| [0] https://github.com/insidegui/pam-watchid
| pplante wrote:
| I agree using your watch is cool. However I think you lose out
| on the security aspect, an important element that a fingerprint
| provides all on the same device.
| apetrovic wrote:
| The watch is already used on other parts of the MacOS
| (anything in System Preferences), I don't think that sudo is
| much different than allowing kernel extension to run, for
| example.
| dkonofalski wrote:
| >I think you lose out on the security aspect
|
| Can you clarify what you mean by this? I love the idea of
| unlocking and running admin stuff with my watch but kinda
| gave up on the idea because I assumed there would be security
| implications. After thinking about it a little more, though,
| I haven't really been able to come up with anything that
| didn't already require physical access to my machine and some
| way to authenticate (password or fingerprint). Since you have
| to authenticate your device to authenticate the watch and it
| un-authenticates any time it's removed, it seems like you
| don't lose anything security-wise.
| JimDabell wrote:
| The watch unlocking mechanism only works if it's in an
| unlocked state, i.e. you haven't taken it off your wrist
| since the last time you entered your PIN. Somebody would have
| to double-press the side button on your watch while you were
| wearing it.
| gumby wrote:
| I think it's not that bad, security wise. Your watch unlocks
| as soon as it leaves your wrist, and the unlock handshake
| uses the BT hardware to figure out how close your watch is.
|
| I think this isn't a great UX for other reasons I posted on
| this discussion. But the security is acceptable to me.
| dmitriid wrote:
| I'd love for iPhone and Watch to serve as a second-screen touch
| id for MacOS. Then I can tuck the laptop (or Mini) away, and
| not have to type passwords into various systems.
| deergomoo wrote:
| If you have a Touch ID Mac, enabling Touch ID for sudo also
| enables using an Apple Watch, so you can use either if you
| like.
| messe wrote:
| If I remember rightly, this only works with the lid open.
| deergomoo wrote:
| Ah, I never use clamshell mode so I didn't know that.
| mkskm wrote:
| That's correct, which typically defeats the point of using
| it since in that case you still have access to Touch ID.
| The above link works in both scenarios, and can be used as
| a fallback for pam_tid.
| gumby wrote:
| You have to take your fingers off the keyboard for this which
| is a big distractor, worse than using a mouse.
|
| I use this feature for other touch cases (e.g. unlocking
| 1Password) but would hate it when in the flow.
|
| Admittedly my password is well wired into my fingers.
| bombcar wrote:
| I want a mouse with Touch ID in the button. Or on the side.
| chadlavi wrote:
| It would be cool if they built it into the touchpad in a
| future generation. I'm guessing once they can figure out
| fingerprint through the glass on iPhone they'll do it in
| the touchpad, too.
| anaerobicover wrote:
| I'd have some concerns with this being trigger-able
| without positive intent to do so if it were in my mouse
| or trackpad. Having a small interruption can be
| beneficial for safety.
| hardlianotion wrote:
| If you use your little finger RHS print as a reference,
| perhaps that won't be too bad? On the keyboard it seems
| fairly reachable.
|
| I haven't tried it myself ...
| gumby wrote:
| I did try that but it's a stretch worse that the extrema of
| Emacs.
| dylan604 wrote:
| The fact it is the last key in the first row makes it easy
| to find by touch without looking at it. Just like regular
| touch typing, it becomes habitual/muscle memory.
|
| I haven't used a full size keyboard in so long, I had to
| think about the print reference. I have lost direct
| placement of Home/Print Screen/End type button locations in
| my memory. To be more accurate to the keyboard in question,
| it is a slight extension past the delete key. The only
| hazard is if you come up short, you might bring up Siri
| (depending on touchbar mode) which is an even bigger
| distraction. </pedanticmode>
| easton wrote:
| Maybe that's better, if you're using sudo you should probably
| think a second before you do what you were going to do. I
| used to enforce the disclaimer coming up every time after I
| broke a package one too many times.
| vladikoff wrote:
| Original source / credit for this is probably:
| https://twitter.com/cabel/status/931292107372838912
| mettamage wrote:
| This won't be as easy, but I just never thought about it: what
| about creating a Face ID for sudo on Mac?
___________________________________________________________________
(page generated 2021-03-01 23:01 UTC)