[HN Gopher] Quick Tip: Enable Touch ID for Sudo (2020)
___________________________________________________________________
Quick Tip: Enable Touch ID for Sudo (2020)
Author : polycaster
Score : 370 points
Date : 2022-06-15 08:48 UTC (14 hours ago)
(HTM) web link (sixcolors.com)
(TXT) w3m dump (sixcolors.com)
| delogos wrote:
| Speaking from personal experience, don't do this on a machine
| you'll ever access remotely, because then you're stuck waiting
| for the biometric check to time out before you can authenticate
| via another method.
| bodge5000 wrote:
| Doesnt just apply to macs/touch bar either. Had the same issue
| when I setup my fingerprint sensor on my thinkpad on fedora.
| Maybe theres a way to get both to work, but I never found it
| [deleted]
| jwr wrote:
| That's why I prefer using Yubikeys (using this setup:
| https://github.com/drduh/YubiKey-Guide) -- and this method
| times out immediately (just press esc when the "insert card"
| dialog comes up).
|
| Plus you can have multiple keys. Plus you can use them for gpg
| and ssh. Plus you can back them up. Plus you can print them on
| paper.
| tirwander wrote:
| The biggest reason I haven't adopted Yubikey yet is that I'm
| super worried I'll lose that one little USB/NFC key
| _morgs_ wrote:
| Always get 2...
| kelnos wrote:
| How does that work in practice, though? Do most websites
| (etc.) support enrolling more than one token?
| fragmede wrote:
| GitHub and Google/Gmail certainly do.
| mwarkentin wrote:
| Almost every one .. the big one that only supports a
| single MFA token that I'm aware of is AWS...
| GekkePrutser wrote:
| Yes and you can forward the yubikey through an SSH agent.
| It's what I do. This way you can sudo with hardware auth both
| locally and remotely. Enable touch to sign so the yubikey
| can't be 'milked' for authentication while it's inserted and
| unlocked.
|
| I don't know if you can do the same (forwarding over SSH)
| with Fido2 but I still use traditional SSH keys anyway
| (stored on the yubi with OpenPGP). And the pam_ssh_agent_auth
| module.
|
| I'll only consider switching to Fido once everything supports
| it (eg my iLO devices too) and it can offer at least the same
| features like forwarding. For now the former is very far from
| being realised anyway.
| smsx wrote:
| I've just tested this, and it works fine. It asks for my
| password like normal from an ssh session, while still using
| touch id locally.
| Thorrez wrote:
| Hmm, what about remote desktop?
| rfoo wrote:
| There is a "Use password" button.
| vladvasiliu wrote:
| There's a workaround for this on the Arch Wiki:
|
| https://wiki.archlinux.org/title/Fprint#Login_configuration
|
| This also helps if you want to use the touch / Yubikey /
| Whatever to unlock the machine, but you need to type in the
| password when _opening_ the session so that all the wallets
| unlock, too.
| xenadu02 wrote:
| In macOS terms ssh is a "StandardIO" session, not an Aqua (UI)
| session so it shouldn't even attempt the biometric prompt in
| that case.
| dingleberry420 wrote:
| Title should mention "mac tip"
| jeroenhd wrote:
| Well, `sudo` is a *nix binary, so Linux and macOS are your most
| popular options here.
|
| Fingerprint authentication for sudo was enabled by default on
| my Manjaro install after I enrolled a fingerprint so I guess
| popular Linux distributions configure it automatically. If
| yours doesn't, try the configuration methods on this page:
| https://wiki.archlinux.org/title/fprint or here:
| https://askubuntu.com/questions/1015416/use-fingerprint-auth...
| or consult your operating system's documentation.
|
| The big difference is that you need "pam_fprintd.so" instead of
| "pam_tid". On Ubuntu (or derived, probably), running "sudo pam-
| auth-update" will allow you to configure fingerprint
| authentication without needing to manually edit system files.
|
| Do note that if you use a more exotic window manager, any fancy
| visual sudo prompts may not know how to deal with such a
| system. I don't know how gksudo and i3 work together on this,
| as visual sudo tools often try to block access to other
| windows.
|
| If you're on Windows and want WSL with Windows Hello, there's
| this tool: https://github.com/nullpo-head/WSL-Hello-sudo which
| is a PAM library that will call into Windows Hello from WSL.
| Windows Hello should in turn support your fingerprint reader or
| other biometric authentication system configured for your PC.
| woodruffw wrote:
| If you're like me and you got the order wrong, this will
| completely break your PAM configuration. To fix it, I had to
| temporarily enable the actual root user[1].
|
| [1]: https://superuser.com/a/1357253
| Reason077 wrote:
| This is pretty neat.
|
| But one annoyance is that on macOS Monterey, the authentication
| pop-up dialog doesn't have focus when it appears. You first need
| to click on it before you can use Touch ID. That slows the whole
| process down to the point where it's probably just quicker and
| easier to use your password.
|
| Is there any way to make the pop-up automatically get focus, or
| is that itself a security risk somehow?
|
| (Side note: the same module enables authentication by Apple Watch
| too! But again, having to take your hands off the keyboard to tap
| the Apple Watch to approve the request slows down the process so
| much that it's hardly worth it)
| alana314 wrote:
| It has focus for me, using iterm2.
| Reason077 wrote:
| Oh, thanks! Your comment made me look again and now I've
| figured it out!
|
| I had _" Secure Keyboard Entry"_ turned on in Terminal.app.
| Apparently this prevents the authentication pop-up (or
| anything else, presumably) from taking focus away from
| Terminal.
|
| Turning it off solves the focus issue!
| edjw wrote:
| I find that the dialog pops up without focussed when I launch
| Bitwarden, but does have focus when I launch 1Password. It is
| confusing
| mwint wrote:
| Apple Watch auth is slower than Touch ID, but faster if you're
| using an external keyboard that doesn't have build in Touch ID.
| alana314 wrote:
| how do you enable this? Would like to do it for my desktop.
| Also for application installers if possible.
| Reason077 wrote:
| System Preferences -> Security & Privacy -> General -> _"
| Use your Apple Watch to unlock apps and your Mac"_
| Reason077 wrote:
| I wonder if there's a way to make it skip the confirmation
| step. Apple Watch auth when logging in requires no
| confirmation, so is there a good reason for sudo to require
| it?
|
| That would make it faster than Touch ID and having to first
| click on the authentication pop-up.
| pilif wrote:
| It would also allow to authenticate sudo without you
| knowing for as long as you sit next to your machine
| [deleted]
| Reason077 wrote:
| Well, you _know_ about it, because the watch makes an
| "unlocking" sound and taps your wrist each time it
| authenticates you.
| saagarjha wrote:
| Right, but there's no way to undo a sudo authentication.
| mikevin wrote:
| Theoretically automatically popping up that dialog could result
| in you authenticating without being aware you did so. It would
| require you resting your finger on the right spot but it might
| be the reason for this behaviour.
| Rygian wrote:
| If anything, the reverse is a security risk: applications that
| steal focus while I am typing down a password.
| wonderbore wrote:
| Software stealing focus is an awful antipattern and I wish
| macOS would fix this crap. Even on iOS, which is otherwise
| good with this, will gladly interrupt whatever you're doing
| to show you a fullscreen captive portal. Obnoxious,
| especially if you're just walking by an open wifi you joined
| at some point in your life.
| Mindwipe wrote:
| It completely baffles me why captive portals do not obey
| the normal windowing mechanisms on iOS.
| easton wrote:
| Because then the average user would say "I know I'm on
| Wi-Fi because Control Center says so, but nothing loads
| in {app that isn't a browser}". Or worse, "I joined a Wi-
| Fi network but my iPhone decided that it can't connect to
| the internet through that so now it's using my data plan
| instead without telling me[0]".
|
| Windows and macOS pop up the default browser (or on
| macOS, a webview) with the captive portal when they
| detect one. iOS doesn't have windows, so if it wants to
| get the user to do the captive portal without them
| sitting there in confusion it has to pop it up. It could
| pop a notification, but if the user misses it (as one
| could, with all the notifications that come in these
| days), then they are stuck.
|
| 0: https://support.apple.com/en-us/HT205296 (which has
| kicked in for me sometimes when my LAN doesn't have
| internet for whatever reason)
| wonderbore wrote:
| iOS made the mistake of conflating wifi with "internet",
| it will even attempt to kick you off a wifi if it doesn't
| have internet, but it will gladly show you the icon even
| before logging you into the captive portal.
|
| The current situation is incredibly badly-engineered on
| so many levels. It's maddening, really. One of the worst
| parts is that the modal disappears as soon as you attempt
| to switch apps (or god forbid you try to respond to a
| message you received)
|
| Notification + real internet connectivity indicator + a
| regular Captive Portal/Internet App would go a long way.
| reaperducer wrote:
| _on macOS Monterey, the authentication pop-up dialog doesn 't
| have focus when it appears_
|
| Good.
|
| Focus has really become a problem on Macs.
|
| When I switched from Windows to Macs, programs were not allowed
| to steal focus from what you were doing. To me, it was an
| amazing thing to not be interrupted for every little piddly
| thing that some background process deemed to be the most
| important thing in the world. I was so much more productive
| when I wasn't being constantly interrupted, as I was in
| Windows.
|
| Then, not too long after Snow Leopard, that changed. Programs
| here and there started asserting themselves. Now it's like
| Windows days, and it's awful.
|
| Even Apple is guilty of this. A few days a week, I plug in four
| encrypted drives. It takes about five minutes for them to
| mount, so I go work on other things. I'll be happily typing
| away at something, and then suddenly find what I'm writing is
| being typed into the password field to unlock one of the
| drives.
|
| Finder -- perpetually awful -- can't even keep focus on itself
| in the middle of some tasks. Even on a brand new M1 machine,
| 90% of the time, when I Shift-Command-N to create a new folder,
| focus will land in some random window or pane. The new folder
| was created, but it's just "untitled folder" all by itself,
| because Finder decided to go scratch its butt. Or sometimes the
| name of the folder is the first few characters I wanted it to
| be, because in the middle of typing the name, Finder switched
| focus to something else. Or when I switch to some other
| program, and then switch back to Finder a good percentage of
| the time, I find out that _none_ of the windows are in focus,
| and none of them are focusable with Command-~ at all. So, I
| have to go back to the trackpad to select the right window. The
| window I was using twelve seconds ago, the last time I was
| using Finder.
|
| I think allowing any pop-up to demand focus is a serious
| security flaw. I've sometimes found myself typing a password
| into a browser, or a word processor, because they've decided
| that they are the most important thing in my life at that
| moment.
| Reason077 wrote:
| Fair points, but this is not some random app popping up a
| dialog. It's a child window of Terminal itself, so I can't
| think of a good reason why it shouldn't get focus.
| spoiler wrote:
| Must depend on the terminal, then. The terminal I use
| (Warp[1]) does focus the authentication popup after I run
| sudo.
|
| [1]: There's so many things named warp these days, so
| here's a link to ease searching lol https://www.warp.dev/
| Reason077 wrote:
| I discovered the focus issue is caused by having "Secure
| keyboard entry" enabled in Terminal. Turning that off
| means you can use Touch ID without having to click to
| focus.
| paulcole wrote:
| ITT: "Ackshully if your threat model includes James Bond level
| tradecraft this is a bad idea."
|
| Spoiler alert: Essentially nobody's threat model includes that.
| cbxyp wrote:
| idk if the pam module used to be around but i remember building a
| modified sudo binary to accomplish this on my MBP pro a few years
| ago.
| dt2m wrote:
| For whatever reason, this resulted in me being prompted to first
| type my password, then also authenticate with Touch ID.
| thorncorona wrote:
| This happened to me when I didn't put the pam_tid.so line right
| under the first line.
|
| Mine looks like
|
| ```
|
| auth sufficient pam_smartcard.so
|
| auth sufficient pam_tid.so
|
| auth required pam_opendirectory.so
|
| account required pam_permit.so
|
| ...
|
| ```
| dt2m wrote:
| Killer, thx !
| saxonww wrote:
| I've tried this multiple times over the years and it doesn't seem
| to work, at least not with tmux.
| er0k wrote:
| this works for me with tmux
| https://github.com/fabianishere/pam_reattach
| nimbius wrote:
| reminder: biometrics are not protected by the fifth amendment.
| use strong passphrases.
|
| https://www.eff.org/dice
| zakk wrote:
| It's very cool, but every update of mac OS resets it! After a
| while I didn't bother to reactivate it...
|
| Is there a permanent solution, that does not involve cron scripts
| or other hacks?
| blinkingled wrote:
| iTerm 2 password manager is a close no hacks required solution
| that's slightly more involved but not all that much - add your
| password and on sudo prompt hit cmd+shift+f, touch id and
| enter.
|
| The touch id part is once per iterm session so overall it's not
| too bad and reasonably secure as it uses built-in keychain to
| store passwords I think.
| inopinatus wrote:
| Just go with that. Far from being a hack, converging Unix-like
| system configuration from scripts run out of cron is downright
| mundane.
| irusensei wrote:
| I think there is a filesystem extended attribute that marks
| that file as part as the rootless system. If you exclude that
| attribute it might prevent it from being overwritten. I haven't
| tested it tho.
| vhiremath4 wrote:
| Call me old fashion, but I love the feel of entering my sudo pw.
| It's the rumbling to my v8 engine. I mean M1 Mac.
| hsbauauvhabzb wrote:
| I lock my computer when not near it. If my computer is breached,
| having user level access of the one account permitted sudo is
| pretty much Crown Jewels. If you really wanted to privesc you
| could sniff X11 keystrokes or back door bashrc, but either way
| even user level access screws me so whatever do what you want
| after that.
|
| As a result, I just enable passwordless sudo.
| rollcat wrote:
| You're right, once an adversary gains physical access (or even
| remote access as your main login account), all bets are off.
| This is the area where the traditional UNIX security model has
| failed to adapt at all: you need a password to install a random
| game from apt (a vetted and trusted source), but you don't need
| a password to install a cryptolocker, or exfiltrate personal
| data.
|
| However I like having a password (or some other form of
| confirmation), just so that I can stop to think for a second,
| whether what I'm about to do is a good idea.
|
| What's annoying is that I effectively need two different
| policies on workstations and on servers, since I still want to
| be able to escalate privileges from maintenance scripts[1].
|
| [1]: https://github.com/rollcat/judo/issues/9
| PureParadigm wrote:
| I do the same. I've yet to hear a convincing argument against
| this practice. Everyone seems okay with passwordless docker and
| you can use that to privilege escalate too.
| hsbauauvhabzb wrote:
| I use FDE so I've also configured gdm3 to auto login, login
| and screen lock are two separate concepts and I only use the
| latter :)
| deckard1 wrote:
| yep. What I did in the past, back when yubikey first came out,
| was I added a PAM module to check the presence of the yubikey.
| It's almost comically stupid since it just checks that the key
| is inserted with the correct serial number. But you'd need root
| to see what the number is (to emulate it with a fake usb
| device, I guess), and to get sudo you'd need the key inserted.
| I WFH so I'd just leave the key inserted for passwordless sudo
| all the time. But if I needed to step out, just grab the
| yubikey and go.
| irusensei wrote:
| Order matters. Lets say you already have a registered yubikey or
| similar smart card. The /etc/pam.d/sudo file might look like
| this: # sudo: auth account password session
| auth sufficient pam_smartcard.so auth
| required pam_opendirectory.so account required
| pam_permit.so password required pam_deny.so
| session required pam_permit.so
|
| So if for some reason you want to have both Touch ID and the
| smart card authentication as options you might want to do this:
| # sudo: auth account password session auth sufficient
| pam_smartcard.so auth sufficient pam_tid.so
| ...
|
| It will ask for smart card first but if a smart card is
| unavailable or authentication fails the touch mechanism will be
| requested. If you invert those parameters the order also gets
| changed.
| yuriyguts wrote:
| I love using sudo with Touch ID and have been using this trick
| for years. The only inconvenience is that the PAM configuration
| always gets reverted by OS updates.
|
| I wrote a small tool to mitigate this by configuring PAM on
| system startup: https://github.com/YuriyGuts/persistent-touch-id-
| sudo
| eevilspock wrote:
| I'm leery of configuring user code to automatically modify
| system files, especially security related ones. I think your
| tool should at least have an option to ask user confirmation,
| perhaps showing the expected file diff, before making its
| change. https://github.com/YuriyGuts/persistent-touch-id-
| sudo/issues...
|
| System updates are not frequent. I prefer doing it manually,
| and just automating a notification that it needs to be redone.
| I added this to my `.bashrc`: if ! grep -q
| "pam_tid.so" /etc/pam.d/sudo ; then echo "touch ID no
| longer enabled for sudo. Insert the following line as line 2 in
| /etc/pam.d/sudo:" echo " auth sufficient
| pam_tid.so # enables touch id auth for sudo" fi
| yuriyguts wrote:
| This is a reasonable concern. Although, whenever security-
| convenience tradeoff is involved, different users will
| inevitably have different preferences and tolerance for
| automation. Some will prefer to do things manually, while
| others will prefer something that "just works" for them.
| eevilspock wrote:
| That's why I said "should at least have an option". And
| even when that option is enabled, it still "just works",
| but with a simple user confirmation and perhaps a visual of
| the file before and after (What if Apple changes the file
| format?).
|
| I think you overstate this tradeoff in this case since
| there is a win-win solution.
| saagarjha wrote:
| System updates are pretty frequent if you're on a developer
| train.
| rollcat wrote:
| Seems like something that would be worth generalising a little
| bit, perhaps merge /usr/local/etc into /etc every boot?
| Probably could be as simple as "rsync -r /usr/local/etc/
| /etc/".
| chii wrote:
| you'd want a patch file instead may be? If something new was
| added to /etc, you'd not want to overwrite it
| rollcat wrote:
| OpenBSD has sysmerge (https://man.openbsd.org/sysmerge),
| Debian's dpkg will also prompt to accept/reject changes;
| this probably would be the ideal solution, but macOS
| doesn't give you an opportunity to implement such a scheme,
| since an upgrade just overwrites all user changes
| unconditionally.
|
| Patches are harder to use than plain files, since you need
| to maintain a source and a destination to diff against, and
| applying them can occasionally fail, requiring the user to
| resolve.
|
| I think overriding configuration in /etc is one of those
| cases where the user's intent is very clearly "I know what
| I'm doing, please get out of my way", and other unices are
| built to respect that. macOS assumes it's the other way
| around, and ends up doing crazy stuff like overwriting
| "PasswordAuthentication" to "yes" in sshd_config on every
| upgrade.
|
| Running rsync to just overwrite the configuration is
| probably too simplistic. Maybe the tool could detect that a
| file was overwritten by an upgrade, and make a backup
| (sshd_config.upgrade, and so on).
|
| I think I'm just going to write it now.
| [deleted]
| eatmyshorts wrote:
| Is there any way to do this as a 2nd factor, so that both my
| password and my fingerprint are needed for sudo?
| likecarter wrote:
| Shortcut:
|
| echo 'auth sufficient pam_tid.so' | sudo tee -a /etc/pam.d/sudo
| haunter wrote:
| This is what I'm trying to do but under Windows and Debian +
| preferably with a mechanical keyboard. Well the mechanical
| keyboard w/ fingerprint reader is the bigger ask cause there
| aren't many choices. There is a decently good one with Cherry MX
| switches from Taiwan but pretty much impossible to order one to
| Europe (they sell their other keyboards but not the one with
| fingerprint reader)
| https://www.i-rocks.com/web/product/product_in.jsp?pd_no=PD1...
| jeroenhd wrote:
| It's not exactly the same, but you could try to buy a keyboard
| with a USB port on the back and add a USB fingerprint reader
| (i.e. https://www.kensington.com/p/products/data-
| protection/biomet...) that way. You'd have a little "key"
| dangling off the back or side of your keyboard and you'd be
| "wasting" a USB port on your fancy keyboard, but it'd work to
| get a fingerprint reader close to your hands on a desktop.
| haunter wrote:
| Thanks I like this, didn't even think about it!
| TacticalCoder wrote:
| Why not a FIDO key? The most stupid ones work with just a click
| (but they do work and they're cheap, so there's that). Then
| there are slightly less dumb ones that works with your
| fingerprint. Then there are less stupid ones which are using a
| PIN to register a new service and another PIN to authenticate
| yourself to a previously registered service.
| 4ad wrote:
| Unfortunately, this resets after every macOS update, which is
| very frustrating, and also absolutely ridiculous.
| mshockwave wrote:
| I tried this a couple of years ago but it would be reset after
| every system upgrades. Is it still a case now?
| jdthedisciple wrote:
| Surely very convenient but idk, I still feel a li'l icky using my
| fingerprint for authorization. What if one day the fingerprint
| sensor acts up a little, as can always happen with such sensitive
| hardware? Then you 're just completely screwed?
| josu wrote:
| No, you just use the password.
| jdthedisciple wrote:
| What? So there's no added security by using TouchID as some
| here seem to think? So it's a pure convenience thing ... if
| so then well, I'm personally not very annoyed by having to
| enter my password when my hands are on the keyboard anyway.
| JW_00000 wrote:
| I think the idea is that you can choose a very long and
| complex password, because you won't have to enter it so
| often once you enable TouchID. Without TouchID, most people
| are tempted to choose passwords that are easy and quick to
| type.
| FabHK wrote:
| As the article says (my highlight):
|
| > That line basically tells the sudo command that the Touch
| ID authentication module is _sufficient_ to authorize the
| user
| yrro wrote:
| Depends how you configure PAM. You can have it set up so
| you need both touch and password if you really want...
| fastball wrote:
| If you want to do the same but auth with your Apple Watch, you
| can follow this[1] guide.
|
| [1] https://akrabat.com/add-apple-watch-authentication-to-sudo/
| ddlsmurf wrote:
| Doesn't this block ssh (headless) access ?
| irusensei wrote:
| Within /etc/pam.d there are multiple files for each system
| component:
|
| authorization authorization_la chkpasswd login.term screensaver
| screensaver_la su authorization_aks authorization_lacont cups
| other screensaver_aks smbd sudo authorization_ctk checkpw login
| passwd screensaver_ctk sshd
|
| So if you edit the sudo file it will only affect sudo. Likewise
| sshd will only affect sshd. Unless of course it contains an
| entry that includes another file which is common for Linux.
|
| Now even if it causes problem for say sudo over ssh that page
| recommends that you add a "sufficient" entry. That means that
| method will be tried and if fails or its unavailable the next
| one will be tried.
| pil0u wrote:
| Around 2014, I read a security researcher's article stating that
| biometrics should be used as an identifier at best, but never as
| a password. "You can change a password, but you cannot change
| your fingerprint".
|
| From that day on, I've never used biometrics system used as
| authentication.
|
| With a increasing use of biometrics on phones, should I think
| differently in 2022?
| lathiat wrote:
| Every time you type a password or pin code into your phone in a
| public place it's trivial for someone to see what it is over
| your shoulder. It's doable for keyboards to though not quite as
| easy.
|
| They can't see it if you use your fingerprint or FaceID.
|
| That's actually a security improvement for some threat models.
|
| Just a thought :)
| franga2000 wrote:
| Being able to change a credential only matters of it's a
| clonable credential like a key or a password. Assuming whatever
| device you're using is able to distinguish between the real
| thing and a copy, it doesn't matter if your
| fingerprint/face/iris... is "compromised" so there's no need to
| change it. That is, however, an assumption that has been made
| many times in the past and proven untrue.
| Angostura wrote:
| One advantage of TouchID/FaceID for me is that I can use a
| long, strong passphrase on my phone - one much longer than I
| otherwise would if I had to use it to unlock every time. The
| passphrase is still required for highlky sensitive stuff like
| keychain access and turning off Find My
| mrtksn wrote:
| > a security researcher's article stating that biometrics
| should be used as an identifier at best, but never as a
| password
|
| Blanket statements like that are never true. It's usually about
| threat modelling, i.e. build your defences according to who
| might want to access your stuff and what are their
| capabilities.
|
| Why? Because you will have to target a balance between
| convenience and security. If you don't use biometrics you might
| end up to have "QWERT1234" as a password to compensate for the
| loss of convenience.
|
| Even if you have a strong password and you are ready to give up
| some convenience, you also risk false sense of security. Your
| password might be strong but there are many ways to extract
| passwords. As a result you might want to switch to certificates
| - which are convenient and secure to use but now you are
| responsible for it's upkeep or you might loss access to the
| systems when you loose your certificate. Also, you might think
| that certs are super secure but just yesterday it was revealed
| that there's a way to extract certificates from Intel and AMD
| machines through an attack called hertzbleed.
|
| Hmm, maybe you need something even more secure. How about air
| gap? If your device doesn't have a network connection, you must
| be %100 protected, right? Wrong, there are multiple
| demonstrations about extracting information through sound,
| magnetic forces and light.
|
| %100 security is impossible, better choose the right kind for
| you.
| Wowfunhappy wrote:
| > Hmm, maybe you need something even more secure. How about
| air gap? If your device doesn't have a network connection,
| you must be %100 protected, right? Wrong, there are multiple
| demonstrations about extracting information through sound,
| magnetic forces and light.
|
| Eh, they're all pretty bogus though, with ridiculously
| contrived scenarios I mostly can't imagine happening in the
| real world.
|
| USB sticks and the like pose a more realistic danger to air
| gapped machines, but they're also easy to avoid if you're
| conscientious.
|
| Air gaps are really, really good and we should be using them
| more.
| mrtksn wrote:
| For most people a fingerprint scanner is just enough, an
| awful lot of people don't have any password or biometrics
| and even they just do fine. It's all about the threat,
| there's no right answer about how much security is enough
| security without assessing the threat factor.
| Wowfunhappy wrote:
| I'm not arguing that point. But I think focusing on these
| frankly-stupid "look we can transfer data using light"
| papers severely undersells the effectiveness of air gaps,
| for people who do need them.
|
| It should be obvious to anyone who has used a QR code
| that it's possible to transfer data over other channels,
| but it's pretty obvious it's happening.
| dhzhzjsbevs wrote:
| > Blanket statements like that are never true.
|
| Except in cases where they are, like this one.
|
| Just cause you want convenience doesn't change the fact your
| fingerprints aren't good passwords.
| personjerry wrote:
| I think this is a product manager versus engineer
| conversation where you're talking over each other.
|
| You're technically right that fingerprints aren't "good
| passwords", in fact they are not even passwords at all. But
| for most people, most of the time, they cover most of the
| same use cases at a better convenience price point.
|
| For general use (i.e. unless you work in security or
| journalism) that's what matters.
| babypuncher wrote:
| Biometrics may not be easy to change, but they are a lot
| harder to copy than passwords. How many people are likely
| to be targeted by an organization with the resources to
| covertly steal and duplicate peoples fingerprints?
|
| For the vast majority of users, the threat model looks like
| "I don't want that creep who just stole my purse to be able
| to log in to my iPhone", not "I am guarding state secrets
| and a potential target of Kremlin agents".
|
| Passwords get stolen and used all the time, but I have yet
| to hear stories of everyday thieves breaking into iPhones
| with stolen fingerprints.
| Bilal_io wrote:
| > Except in cases where they are, like this one.
|
| Mark Twain once said "All generalizations are false,
| including this one."
| mrtksn wrote:
| fingerprint are not passwords at all, they are
| fingerprints.
|
| Checking for a fingerprint match essentially means that the
| administrator of the device is present and authorises the
| action, assuming that their fingerprints are not copied by
| an attacker and they are not physically forced to comply
| with an attacker.
|
| Checking for a password match essentially means that the
| administrator of the device might or might not be present
| but authorises the action, assuming that the password was
| not obtained through a post-it, coercion, phishing,
| guessing or any other password extraction method and they
| are not physically forced to comply with an attacker.
| hunter2_ wrote:
| I think there are many cases where your listed
| assumptions about each (passwords and fingerprints) are
| agreeable, but one important difference makes passwords
| often superior: ability to change after a compromise. If
| your accounts get hosed because someone else can enter
| your password, you can start over and continue using
| password-based authentication; if someone else can enter
| your fingerprints, you start over and must not use
| fingerprints for authentication.
| lstamour wrote:
| True. But unlike a password, biometrics often also act as
| a second factor in that they authorize a particular
| device and can't easily be done remotely. Even if my
| fingerprints were compromised, I'd probably continue
| using biometrics instead of or in addition to a password.
| I'm a fan of Yubikey with biometrics, for example,
| because it's an extra layer of security. Just don't lose
| a finger or hand or you'll never easily authenticate
| again...
| throwaway09223 wrote:
| The point is that fingerprints _may not_ mean the
| administrator of the device is present, in the same way
| that a password that cannot be changed also may not mean
| the administrator of the device has authorized an action.
|
| If a credential cannot be changed then its confidence as
| an identifier is significantly reduced.
|
| Fingerprints are useful in cases where the effort of
| copying a fingerprint is greater than the value of the
| target. They're great for almost everyone with low value
| systems, like your average easily pickable front door
| lock. They're good for keeping honest people honest.
|
| Fingerprints are a problem for high value systems.
|
| Fingerprints are also certainly a shared secret
| identifier, and we typically call shared secret
| identifiers "passwords" even when they aren't literally a
| typed word.
| hulitu wrote:
| > Checking for a fingerprint match essentially means that
| the administrator of the device is present and authorises
| the action
|
| No it means only that the fingerprints are present. Your
| finger can be cut or you might be forced to unlock the
| device.
| interactivecode wrote:
| if they are about to cut off my finger, I'm pretty sure I
| will just tell them my sudo password of my local machine.
| at that point they can modify all they want on my laptop.
| pilsetnieks wrote:
| Touch ID specifically requires a live finger. Other
| fingerprint readers might not.
|
| You can also be forced to reveal or enter the password.
| AndrewThrowaway wrote:
| > Touch ID specifically requires a live finger.
|
| I remember reading about one school which implemented
| "live finger" readers.
|
| How did kids hack it?
|
| Polymer clay and a gummy bear.
|
| Put your finger on clay and wait for it to dry. You will
| have your permanent mirrored fingerprint.
|
| When required fingerprint press gummy bear against clay
| and then against the reader. As gummy bear holds charge,
| can even be cut thin etc. there is little chance to
| detect that it is not a real skin.
| JoachimS wrote:
| You are missing the "requires a live finger" part.
|
| The biometric system (sensor + algorithm) used by Apple,
| as well as other competitive biometric vendors, detect
| blood flow, pulse in the finger. This is done as a
| mitigation against fake fingers as well as the (always
| presented) gory "cut off the finger" attack scenario.
|
| A gummy bear may be lifelike, but normally lacks a
| beating heart and circulatory system.
| airstrike wrote:
| > A gummy bear may be lifelike, but normally lacks a
| beating heart and circulatory system.
|
| "Normally"?
| shaftway wrote:
| Most fingerprint sensors that look for a pulse can be
| fooled by a gummy bear that has been sliced thin enough
| to allow the pulse to pass through, but thick enough for
| the ridges to be picked up. Think about something around
| a millimeter thick.
| FabHK wrote:
| That was literally the second half of the sentence (which
| you left out, unless GP edited their post).
| babypuncher wrote:
| > Your finger can be cut or you might be forced to unlock
| the device.
|
| How common is this scenario? I imagine it is a lot less
| common than passwords getting stolen or cracked.
|
| Contrary to how some people here are acting, most people
| aren't targets of foreign foreign espionage.
| chriswarbo wrote:
| No, it only means that the device _reported_ a match; or,
| that a match signal came in on a certain hardware port
| (since the scanner may have been replaced, tamperered
| with, etc.).
| mrtksn wrote:
| Not necessarily, it depends on the implementation. On
| Apple's case AFAIK the fingerprint mach doesn't simply
| report a match but also provides the system with the
| key(which was stored in a separate system) to decrypt the
| data. You can't simply connect a bogus fingerpront
| scanner to an Apple device and access the system, in fact
| that's the reason why unauthorised repairs end up having
| the touch ID or Face ID broken.
| dzikimarian wrote:
| Same on Android. Fingerprint is used to enable access to
| cryptographic key.
| mrtksn wrote:
| That's why I have an "assumptions" part. It doesn't
| matter though, it will depend on the implementation of
| the fingerprint scanner.
|
| The gist is, a password and a fingerprint are not the
| same thing. Fingerprint is not a weaker password or
| anything like that, they have different properties and as
| a result they have different pros and cons. For example,
| no one can copy your fingerprint by looking over your
| shoulder - unlike a password.
| qzx_pierri wrote:
| I think accounting for scenarios where someone might want
| to cut your finger off to gain access to your device is
| covered under the thread modeling reply above closer to
| the parent comment. Which makes sense. If I'm a cartel
| boss, I'm definitely not using biometrics. But if I'm a
| college sophomore who doesn't have any nation state
| enemies, then biometrics is fine.
| phpisthebest wrote:
| You negated all of your points with your clarifications
| of "assuming that..." why should one assume none of those
| are present?
| FabHK wrote:
| This was not a negation, but a helpful clarification of
| what assumptions are made in either case (and thus, what
| your threat model must consider).
|
| Namely: if you are forced to comply, it doesn't matter in
| either case.
|
| If your password can be "obtained through a post-it,
| [...] phishing, guessing" etc. (key logger), then you
| might be better off with biometric authentication.
|
| If your fingerprint can easily be extracted (and the
| sensor be fooled by it easily), then you might be better
| off sticking with the password.
|
| Those clarifications give you a good way to think about
| the tradeoffs.
| mrtksn wrote:
| Because that's how you model your threats? You assume
| things like someone won't be able to physically take your
| RAM and read whatever data they want, for example. If you
| can't assume that, then you implement measures against it
| like soldering the RAM to the mainboard.
| nl wrote:
| Most of the time they aren't. And if they are you
| probably can't protect against the attacker.
|
| From elsewhere on this thread: https://www.schneier.com/b
| log/archives/2015/08/mickens_on_se...
| chriswarbo wrote:
| > assuming that their fingerprints are not copied by an
| attacker
|
| > assuming that the password was not obtained through a
| post-it, coercion, phishing, guessing or any other
| password extraction method
|
| If we're happy to make such assumptions, then we can
| remove security entirely: just assume that actions are
| authorised!
|
| Less tongue-in-cheek: we should try to avoid making such
| assumptions in the first place. For example, saying "this
| action was authorised by the presence of an
| administrator" is setting us up for failure: that's a
| hard thing to ensure, and also relies on fuzzy concepts
| like "presence".
|
| Instead, there's nothing wrong with saying "this action
| was authorised by the fingerprint scanner matching the
| admin account": it's a more accurate statement, it
| doesn't hide any vulnerabilities, and it doesn't rely on
| any fuzzy concepts; e.g. we're not talking about humans,
| fingers, etc. we're only talking about accounts and
| hardware devices.
| mrtksn wrote:
| If you like, you can stop making assumptions and only do
| statements but that doesn't change anything.
|
| >"this action was authorised by the fingerprint scanner
| matching the admin account"
|
| Okay, so? It's the same thing as "this action was
| authorised by a keyboard entry sequence matching the
| admin account prerecorded sequence".
|
| How is this any more useful? If anything, you better know
| and understand your assumptions and introduce other
| measures if you suspect that some of those assumptions
| are no longer true.
| chriswarbo wrote:
| > "this action was authorised by a keyboard entry
| sequence matching the admin account prerecorded sequence"
|
| "keyboard entry sequence" is just a long-winded way of
| saying "password"; there's nothing wrong abbreviating.
|
| However, even this facetious example was useful, since
| it's exposed a security problem: you're storing passwords
| ("prerecorded [keyboard entry] sequence"). You should be
| storing password hashes instead (using a slow hash
| function).
|
| :)
| mrtksn wrote:
| I don't store anything but it doesn't matter because it
| doesn't change anything. Simply modify the sentence to
| include the hash conversion.
|
| The storing password part is relevant for extraction of
| password from an already compromised system and
| fingerprints can be hashed just as well(and on Apple's
| implementation, they are). It's just irrelevant
| implementation detail that doesn't make difference for
| the security of the system in question.
|
| In fact, fingerprints are actually more secure because
| you don't have rainbow tables for hashed fingerprints but
| you have it for passwords.
| chriswarbo wrote:
| > Simply modify the sentence to include the hash
| conversion.
|
| You seem to be missing my point: that it's better to
| think about security issues in terms of the components
| and actions that actually exist in the implementation
| (e.g. "when the given password agrees with the stored
| hash, then XYZ"), rather than the real-world concepts
| they're crudely trying to approximate (e.g. "when the
| administrator is present, then XYZ").
|
| If you want to use fingerprint scanners as part of a
| security system, that's fine; I really don't care. What I
| _do_ care about is that "fingerprint scanner says yes"
| does not imply "Alice is currently holding her thumb
| against the phone screen", or other such real-world
| scenarios.
|
| Alice holding her thumb against the screen might _cause_
| the fingerprint scanner to say yes; and it 's perfectly
| fine to make that assumption when designing a UI (where
| failure is mostly an irritation). Yet security design
| should _not_ make that assumption, since it may hide all
| sorts of vulnerabilities.
|
| As an analogy: a "Keep off the grass" sign is not the
| same as there being nobody on the grass. It's good enough
| for something inconsequential, like turning on a
| sprinkler system (if you get wet, you should've followed
| the sign; similar to a UI breaking if the user doesn't
| use their phone in standard ways); yet it's not enough
| to, say, store our valuables on the grass, in the hope
| that nobody can get to them.
| FabHK wrote:
| > "fingerprint scanner says yes" does not imply "Alice is
| currently holding her thumb against the phone screen"
|
| Which is why GP carefully qualified his statement that
| "administrator is present" with the appropriate
| assumptions.
| gchamonlive wrote:
| Related: fingerprints can be hacked
| https://news.ycombinator.com/item?id=29306163
| awestroke wrote:
| As can passwords
| alpaca128 wrote:
| But you can change passwords.
| pierreminik wrote:
| And the biometric check is still password based, right?
| You can't use Touch ID until you've entered your
| password, and then it's only a convenience for a given
| time.
| hackernewds wrote:
| > there are multiple demonstrations about extracting
| information through sound, magnetic forces and light.
|
| fascinated by this. where could one learn more?
| dave881 wrote:
| US Military/Intel TEMPEST program covers protection against
| some of these. The Wikipedia article's references includes
| links to relevant research.
|
| https://en.wikipedia.org/wiki/Tempest_(codename)
| permo-w wrote:
| for me this is not the reason you should be careful using
| fingerprints for security. I don't use touch ID because I'm
| concerned that if I'm ever arrested, the police could a) force
| me to unlock it, b) unlock it while I sleep. The same goes for
| people I sleep in the same room as.
|
| I think it's silly to have a security measure that can be
| passed while you're not even conscious
| kube-system wrote:
| If you're worried about being compelled to enter your Touch
| ID, just mess up entering your fingerprint five times or turn
| off the device, and the device will no longer accept Touch
| ID.
| permo-w wrote:
| I'd rather just use a code
| samatman wrote:
| Short answer is all that advice is obsolete. Biometrics as used
| by secure enclaves have tradeoffs which are unrelated to the
| (again, _obsolete_ ) practice of storing biometrics as
| authentication per se.
|
| The secure enclave holds biometrics, these are used to generate
| ordinary key pairs which are revokable.
|
| If you have a device like this, try it! Register a finger, then
| un-register the finger: congrats, you've changed your
| fingerprint.
| gommm wrote:
| I see touch ID for sudo as the equivalent of 2FA. I am on my
| computer, I'm logged in in the account that has admin
| permissions but we want to confirm that it's me and not someone
| else that is logged in to my account, so touchid for sudo acts
| as a 2fa.
| leksak wrote:
| That's a fine 2FA unless your threat model involves physical
| coercion. The nice thing about passwords is that giving it
| is, with the exception of some drugs maybe, voluntary. You
| don't really have the same agency if someone forcibly makes
| your finger touch the device. And I think fingerprints work
| even on a dead body. And can be lifted from inanimate
| surfaces like a glas at a bar.
| prvit wrote:
| This feels ignorant of the fact that all the interesting
| information on your computer will be accessible without
| sudo.
|
| touchid is actually better than a password here, as it
| prevents malware from using sudo without physical
| confirmation from you.
| jonfw wrote:
| What do you expect you will do if somebody capable of
| killing you wants your password?
|
| I can't imagine a circumstance where I would not
| voluntarily give somebody a password if they were in a
| position to physically force me to provide biometrics
| nijave wrote:
| The threat model of sudo is a little different. You already
| have authenticated access and sudo is requesting elevated
| access. Even a static button on the computer would provide
| benefit since it alerts the user a program is attempting to
| obtain elevated privileges.
|
| For comparison, Windows default configuration is a yes/no
| dialog (UAC).
|
| If an attacker had unelevated access they probably stand a
| pretty good chance of getting elevated access on a workstation
| (replacing files, putting a shim in front of sudo, stealing SSH
| keys, access tokens, cookies, etc) anyway (if the regular user
| has those privileges)
| brainphreeze wrote:
| I'd tend to agree to be honest. Consider this: a group of
| thieves jump you and pin you down, they want to perform a
| banking transaction on your phone. They grab your hand, extend
| your finger and press it against the phones sensor. They're in.
| On some mobile banking apps, they can perform the same.
|
| The use of a password only known to you cannot be physically
| taken from you as your mind controls that authentication
| mechanism.
| TacticalCoder wrote:
| That's why systems correctly designed have not one but _two_
| passwords (or PINs), which look identical. You enter either
| and everything seems to work. But one of the two means _" I'm
| under duress"_.
|
| If people home-jack me at night, my 24/7 alarm
| system/monitoring company calls me in the following 45
| seconds at most and asks me for my password. If I say
| "monkey" it means everything is fine, if I say "beetle" it
| means I'm under duress. When I give either password, the
| company answers: _" OK, sleep well, all is good"_. But in the
| later case they call the police and tell them a home-jacking
| is ongoing. (obviously my two words aren't "monkey" and
| "beetle", this is just an example).
|
| (as a bonus my alarm system has an anti-jamming system and
| communicates using several channels)
|
| Banking apps should be the same: they should have one PIN to
| do regular business and another one where everything looks
| legit, but you'd only be making fake wire transfer or only
| allowed tiny withdrawals, showing a small balance.
|
| Some companies (for example my alarm system) and websites
| (very few but I've seen some) and some HSM (for example
| cryptocurrencies hardware wallets can decode using two keys,
| one of them showing a smaller balance than the real one) have
| seen the light and have such a feature.
|
| I do believe we're still in the stone age when it comes to
| security. Most people like to post that disastrous XKCD and
| think the bad guys have forever won thanks to their $5
| wrench. I'd hazard a guess: people thinking with that victim
| mentality aren't the ones coming up with better security
| systems.
| brewmarche wrote:
| This would also work with 2 fingerprints
| Aaargh20318 wrote:
| Consider this: you are working on your laptop in a public
| place, like on the train. or in a coffee shop. You log in to
| your company website. Anyone looking over your shoulder can
| see you type your password, as well as the webpage you're
| logging in to.
|
| And it's not just people standing behind you, it can also be
| the security camera in that coffee shop. It can be someone
| looking through your office window with a telescope from the
| next building over.
|
| Same goes for your phone. There are ample opportunities to
| see someone type in their PIN code to unlock their phone,
| especially if you use it for payments which are generally
| done in public places. No need for violence, no need to draw
| attention to yourself, just watch them enter their PIN and
| then pickpocket the phone afterwards.
|
| It all depends on the exact threat scenario, but biometric
| authentication can be preferable to passwords when used in
| public places.
| FabHK wrote:
| When Ed Snowden accesses his laptop in the documentary
| _Citizenfour_ , he puts a blanket over his head and himself
| including the laptop, then types in the password
| (presumably... we will never know :), and only then emerges
| from the blanket. I thought that was an excellent simple
| security measure!
|
| Maybe a bit weird if you start doing that in trains and
| coffee shops though.
| coding_unit_1 wrote:
| A $5 wrench will retrieve a password https://xkcd.com/538/ :)
| michelb wrote:
| So they beat you until you give the password.
| Sebb767 wrote:
| They can also threaten to cut off your finger, in which case
| you'd probably want to enter the password anyway. Also, your
| password can easily be found by looking over your shoulder or
| by you unlocking your device in front of a camera - which is
| quite likely, given how often you unlock your phone. You can
| also collect and fake a fingerprint, but it's a lot more
| effort.
|
| On the other hand, in a few countries police can force you to
| use biometric authentication, but not to release your
| passwords. In the end, you really need to think about your
| threat scenario and act accordingly.
| sexy_panda wrote:
| I think that someone with enough motivation can easily use your
| fingerprint against you.
| cguess wrote:
| And that applies to only the smallest of percentage of
| people, and those it does would be receiving specialized
| trainings.
| coding_unit_1 wrote:
| Biometrics are not being used as a password directly. They are
| typically used as an identifier to unlock the secrets store on
| the device and then retrieve an access token (which has
| previously been obtained via username/password authorisation).
|
| The biometric information never leaves the device.
| dijit wrote:
| They continue to be correct, the major difference when it comes
| to phones is that you're constantly typing a number in plain
| view of everyone around you.
|
| So you're making a tradeoff and with phones it works out
| slightly better if you unlock with biometrics most of the time;
| but you should know the five clicks method for disabling the
| biometric unlock temporarily.
| dewey wrote:
| Don't use biometrics as a password if your threat model
| includes: Person cloning your finger print from a glass you
| left at a bar, manufacturing a fake fingerprint from it and
| getting physical access to your device to unlock it.
|
| Otherwise for most people it's probably better than easy to
| guess passwords or not using a password at all. Especially if
| it's annoying to type every time (iPhone passkey). Many people
| didn't use a passkey before, since there's TouchID or FaceID
| everyone uses something and it's better against a random thief
| than nothing at all.
| harha wrote:
| Adding to that: just because someone has your fingerprint,
| they won't have full access since you can't reset to a new
| iPhone and get the backup with just the fingerprint. It's the
| combination of fingerprint + the previously authenticated
| device
| Gigachad wrote:
| Never forget the $10 wrench method.
| TowerTall wrote:
| Obligatory xkcd https://xkcd.com/538/
| throwaway744678 wrote:
| Oh, man! The wrench actually costs only $5.
| FabHK wrote:
| Man, inflation is _everywhere_ these days...
| 01acheru wrote:
| The $10 wrench always works: biometrics, passwords,
| encryption keys, physical keys, PINs, etc.
| carlhjerpe wrote:
| But if you have wrench in your threat model you're either
| in a really bad situation or you're rich enough to have
| personal security making the wrench method a lot more
| complex.
| ohgodplsno wrote:
| It's either Mossad or Not-Mossad.
|
| >My point is that security people need to get their
| priorities straight. The "threat model" section of a
| security paper resembles the script for a telenovela that
| was written by a paranoid schizophrenic: there are
| elaborate narratives and grand conspiracy theories, and
| there are heroes and villains with fantastic (yet oddly
| constrained) powers that necessitate a grinding battle of
| emotional and technical attrition. In the real world,
| threat models are much simpler (see Figure 1). Basically,
| you're either dealing with Mossad or not-Mossad. If your
| adversary is not-Mossad, then you'll probably be fine if
| you pick a good password and don't respond to emails from
| ChEaPestPAiNPi11s@virus-basket.biz.ru. If your adversary
| is the Mossad, YOU'RE GONNA DIE AND THERE'S NOTHING THAT
| YOU CAN DO ABOUT IT. The Mossad is not intimidated by the
| fact that you employ https://. If the Mossad wants your
| data, they're going to use a drone to replace your
| cellphone with a piece of uranium that's shaped like a
| cellphone, and when you die of tumors filled with tumors,
| they're going to hold a press conference and say "It
| wasn't us" as they wear t-shirts that say "IT WAS
| DEFINITELY US," and then they're going to buy all of your
| stuff at your estate sale so that they can directly look
| at the photos of your vacation instead of reading your
| insipid emails about them. In summary, https:// and two
| dollars will get you a bus ticket to nowhere. Also, SANTA
| CLAUS ISN'T REAL. When it rains, it pours.
|
| https://www.schneier.com/blog/archives/2015/08/mickens_on
| _se...
| GSGBen wrote:
| The full article is a good read too. Such a great writing
| style.
| atoav wrote:
| May favourite attack of that kind has been the one where a
| CCC-hacker stole the German defense ministers finger print...
| using a DSLR camera and a tele lense at a press conference: h
| ttps://www.theregister.com/2014/12/29/german_minister_finge..
| .
| dewey wrote:
| That's exactly what I had in mind when writing that. That
| was a good one!
| olabyne wrote:
| Oh, I remember this, but I didn't know it was Ursula von
| der Leyen, now president of the european commission.
| satysin wrote:
| Sorry but I have to nitpick here. Nobody was ever able to
| verify the fingerprint was the same as the German defence
| ministers.
|
| What the attacker was able to do was take a high resolution
| photo of the defence ministers thumb and then produce a
| "fingerprint" that they could use to register as a
| "fingerprint" on their own phone and then unlock that phone
| with the "fingerprint".
|
| It could be nothing like the defence ministers actual
| fingerprint but just look enough like any real fingerprint
| to register with a fingerprint scanner on a phone.
| colechristensen wrote:
| If it was a good photograph Tia would be pretty easy to
| verify visually. It would also be trivial to replicate on
| towels to see if your methods actually were adequate to
| authenticate on your own device.
| atoav wrote:
| Thanks for the nitpick, you are right, but given the
| state of photogrammetry today I wouldn't be surprised if
| just a few pictures would be enough to give you an
| accurate representation.
| hnaccount_rng wrote:
| But that wouldn't work with TouchID sensors right? They
| also check for "living tissue". And at that point the
| attack becomes _very_ expensive to perform
| atoav wrote:
| I mean, as a electronics guy I'd say it kinda depends on
| how that living tissue detection is being done. You can
| trick a lot of sensors into outputing things that don't
| make much sense if you know which physical properties
| they are looking for.
|
| The most sophistication would probably be something like
| a PPG (optical reflection changes due to blood flow in
| certain bands). If the fake is thin enough the PPG would
| likely just shine through it. Skin resistance/humidity
| can be easily faked as well.
| mordae wrote:
| A glass?
|
| I mean... Wouldn't there be a bunch of my fingerprints on the
| phone itself?
|
| And if my bag gets stolen along with the laptop and possibly
| the phone, wouldn't there be fingerprints on pencils, water
| bottle and the phone charger?
|
| https://hackaday.com/2015/11/10/your-unhashable-
| fingerprints...
| dewey wrote:
| Where the finger print comes from isn't really the point.
| The point is that a random opportunistic thief that finds a
| phone and wants to go spelunking is most likely not
| dedicated, capable or willing to go through that and your
| data stays safe.
| GeckoEidechse wrote:
| Bringing us back to the discussion about threat models :P
| yallneedtogetit wrote:
| Police can compel people to provide biometrics to unlock
| their devices, but passwords can be forgotten.
| Gigachad wrote:
| This isn't true in most of the world and is even
| questionably true in the US
| phpisthebest wrote:
| It will remain questionable in the US until it reaches
| the Supreme Court.
|
| IMO is clearly a violation of the 5th amendment, but the
| Bill of Rights in the US has been soo watered down at
| this point they may not even be considered rights any
| more....
| NoGravitas wrote:
| 4th amendment, I think. Regardless, given the current
| composition of the Court, I wouldn't hold your breath for
| the situation to improve.
| phpisthebest wrote:
| One could make that case, but 4th allows for searches
| with a warrant
|
| I would say 5th because divulging the contents of ones
| mind is testimony which one should not be compelled to
| do, the 5th profits you from being a witness against
| yourself, reveling a password is being a witness against
| yourself
| chipsa wrote:
| Fifth: the password is testimony. It's searching their
| things, but the warrant issued by the court means that
| it's likely a reasonable search (ergo, not a violation of
| the 4th).
| JBiserkov wrote:
| on iPhone, you can press the `power` and `volume down`
| buttons for a few seconds and Face ID is disabled until you
| enter the code.
| ascagnel_ wrote:
| Similarly, tapping the power button five times in close
| succession will put an iPhone into "emergency mode",
| which (a) brings up a screen with prominent buttons to
| call 911 or your emergency contact and (b) disables
| biometrics until the PIN is provided.
| NoGravitas wrote:
| On Android, this is (usually, vendors may vary) hold down
| `power`, then tap "Lockdown" on the screen. I do like the
| fact that on Apple you can do it without interacting with
| the screen.
| cassianoleal wrote:
| Volume up works too.
| JBiserkov wrote:
| You are right. I incorrectly assumed that since `power` +
| `volume up` takes a screenshot, it wouldn't work, but I
| just tried it, and holding them for a few seconds does
| lock the phone too.
| NoGravitas wrote:
| In the US, the idea isn't that the password can be
| forgotten, but that passwords are protected speech, which
| can't be compelled. This legal theory hasn't been fully
| tested, though -- I wouldn't depend on it unless it was
| upheld by the Supreme Court, but I'd expect this Court to
| give the police absolutely anything they want.
| dewey wrote:
| That doesn't always work out that well for the person
| "forgetting" the password though:
| https://en.wikipedia.org/wiki/Key_disclosure_law
| patrec wrote:
| Exactly, this depends a lot on jurisdiction. I seem to
| remember that there are some places where you could
| basically spend the rest of your life in jail if you
| forget (with or without scare-quotes) your passport.
| tirwander wrote:
| Yeah... It's like child support laws here where I live
| (never had to pay child support, have a friend that is a
| lawyer). They can hold you indefinitely until you come up
| with what they need. Forgot the password? Ah well, how
| convenient! We have this place just for you to sit and
| hopefully.one day remember!
|
| Child support here, while I agree it should be being paid
| but people can run into hard times, is sort of like this
| but more ridiculous. If you are.behind on child support,
| they jail you indefinitely until you can pay it.... But
| you are in jail indefinitely and likely have lost your
| job if you had one. So....
| digisign wrote:
| That's a choice however, assuming you know it.
| nurumaik wrote:
| A person sitting next to you in cafeteria can remember your
| password by looking at your keyboard but can't remember your
| fingerprint this way
| theandrewbailey wrote:
| A person sitting next to you can wait until you leave, dust
| every surface you touched, and copy your fingerprints. I hope
| you can change your fingerprints.
| alpaca128 wrote:
| I'd wish them good luck guessing my custom keyboard layout.
| Melatonic wrote:
| My phone (android) doesnt let me use the fingerprint forever -
| every once in awhile I have to enter the passcode. And on
| bootup of course I have to enter the passcode. So while my
| passcode is quite long (and secure) the fingerprint adds a ton
| of convenience.
|
| I think this is a good compromise - at worst if I were to lose
| the device and someone were to cut off my finger at best it
| would only work for a few days. But that scenario seems quite
| rare.
| jw1224 wrote:
| > "You can change a password, but you cannot change your
| fingerprint"
|
| I've never understood this argument.
|
| I could just as easily say "someone else can use your password,
| but they cannot use your fingerprint".
| yallneedtogetit wrote:
| What's being missed here is that courts have ruled that
| police (read: government) can compel people to provide
| biometrics to unlock their devices, but passwords can be
| forgotten.
| spijdar wrote:
| I think this depends a lot on your threat model. (specifically
| referring to phones/mobile devices)
|
| If you're at all concerned about being targeted, this is a very
| valid concern. On the other hand, I think using
| fingerprints/biometrics is "good enough" to prevent non-
| targeted attacks (theft, lost device) from retrieving sensitive
| info, and is far better than no password or a short numeric
| PIN.
|
| Obviously, using a rotating alpha-numeric-symbol password is
| more secure, but unless you only very sporadically use your
| mobile device, is pretty inconvenient.
|
| (of course, it'd probably be best to use MFA here and have a
| PIN code along with biometrics, but I'm not aware of any
| consumer devices like that)
| obert wrote:
| I could agree, on the other hand though it would become very
| hard hiding your true identity if you were using a thumbprint
| to identify yourself, not to mention the ability to have
| multiple unlinked accounts, or signing in with someone else's
| account (eg your children or your partner's) on the same
| service.
| zitterbewegung wrote:
| I really hope the move to FIDO happens soon in all browsers
| (aka passkeys).
|
| When you reboot a Mac you have to type in the password to login
| still.
|
| The easiest way to authenticate to a Mac is actually your Apple
| Watch.
| quitit wrote:
| There is certainly merit to this line of thinking, however that
| is the scenario where the password is literally the hash of the
| fingerprint or facial read - this is a use case that's closer
| to a login name rather than a password.
|
| To use touchid/faceid as an example:
|
| - it requires that the password was recently entered
|
| - it's not the password, but a means of accessing a temporary
| token
|
| - that token is easily purged from memory by triggering SOS or
| failing touchid/faceid repeatedly
|
| - a range of conditions will also automatically purge the
| token, such as usage that doesn't match the user's behaviour,
| unusual movement such as scuffles, certain combinations of
| location/time/movement, and of course not being used for
| several hours (this also seems to vary based on certain
| conditions.)
|
| In this sense a biometric read can provide a useful level of
| security for most scenarios and definitely better than entering
| a 4-digit pin repeatedly, and infinitely better than gestural
| passwords which are comically easy to guess.
|
| For secure applications it's not useful, nor is a 4 or 6 digit
| pin, but such implementations also engage a range of security
| enhancements such as internet/voip via an encrypted VPN, locked
| down device profiles, limited access to networks and so-on.
| Sometimes the discussion about biometric data use in
| authentication tends to over-borrow from this level of security
| need.
| Spooky23 wrote:
| Typically, biometrics are used as an unlock locally.
| btm1971 wrote:
| When fingerprint readers were first starting to appear in
| Thinkpads, I enabled it so I could log in. I was demo'ing it to
| a co-worker who said "what's to keep someone from cutting your
| finger off to log in". I responded "if we've reached the point
| that they are willing to cut off my finger, I'm going to give
| them my password".
| kube-system wrote:
| Touch ID isn't really biometric authentication. It is hardware
| token authentication, and that hardware token is unlocked via
| biometrics. The end application then authenticates with the
| hardware token. It works similarly to a Yubikey Bio Series
| token. It is actually an additional layer of protection over
| what you'd have with most physical hardware tokens, which can
| be used by anyone who possesses them.
|
| While you can't change your fingerprint, you _can_ change which
| token is registered with the end application, so that concern
| is mitigated.
| corderop wrote:
| Am I the only one that things I write my password faster than
| putting my finger in the Touch ID?
| franga2000 wrote:
| I'm not doubting your speed-typing ability, but if you can
| actually do that, it just means your password is too short
| polycaster wrote:
| Perhaps your password is too short.
| obert wrote:
| 1Password forces users to enter the master password at least
| every 2 weeks, super annoying and insecure. Eg my master password
| is super hard to enter, even more on smartphones, so I'm
| considering moving to a less secure one to avoid the PITA. All
| this technical innovation with Touch Id is great but then
| companies keep reverting to old annoying approaches when facing
| innovation...
| nicoburns wrote:
| Does your password contain a bunch of special characters?
| Consider making your password consist of entirely plain english
| words (perhaps with a _few_ numbers / symbols but not many)
| but just making it longer. That'll be just as secure and much
| easier to type.
| Jaruzel wrote:
| Shameless plug of my (silly) password generator that creates
| those types of password:
|
| Demo: http://www.jaruzel.com/apps/quickpass/
|
| Source: https://github.com/MattOwenGB/QuickPass
| Sebb767 wrote:
| I can tell you from harsh experience that having to enter your
| password after a few months and struggling to remember it is
| strictly the worse option. It might be a PITA, but it
| definitely makes sense to refresh the memory once in a while.
| Saint_Genet wrote:
| That's why you write down your important master passwords.
| yosito wrote:
| Unless your threat model includes someone breaking into
| your locked filing cabinet and stealing the post it note
| with your master password on it. There are some passwords
| that I don't write down anywhere.
| obert wrote:
| I type a password to unlock my device, so I'd like having the
| option to use just touch Id in this case for 1Password
| wrexx0r wrote:
| So I've run into issues with this in the past, which seems to
| relate to using DisplayLink. Seems to be in how MacOS treats the
| DisplayLink driver, and can't be fixed unless Apple makes some
| changes in the OS level
| DavideNL wrote:
| For some reason, this only seems to accepts my Apple Watch as
| authentication, but not the fingerprint sensor... any idea why?
| (fingerprint works to authenticate in System Preferences, etc.)
| $ cat sudo # sudo: auth account password session
| auth sufficient pam_tid.so auth
| sufficient pam_smartcard.so auth required
| pam_opendirectory.so account required
| pam_permit.so password required pam_deny.so
| session required pam_permit.so
| urbandw311er wrote:
| Am I the only one who actually finds it faster to type a password
| than to remove my hand from the keyboard and perform Touch ID
| auth?
| oneeyedpigeon wrote:
| Thanks for the info. There were infinite possible combinations
| that your password could've been before this comment; it's a
| lot less now...
| nicoburns wrote:
| But the touch ID sensor is on the keyboard!
| imron wrote:
| But unless you've set it to be the little finger on your
| right hand, you have to take your fingers off the home keys
| to activate it
| jeroenhd wrote:
| I'm no mac user so I can't test it myself, but does this
| mean you can't associate multiple fingerprints with one
| identity on macOS?
| nicoburns wrote:
| You can associate up to 3
| jeroenhd wrote:
| Ah, okay, that's good. I suppose associating other
| fingers is not really that big of a problem in practice,
| then.
| yallneedtogetit wrote:
| your password is too short
| zwog wrote:
| Nope. The only reason I work on a terminal is that I never have
| to take my hand off the keyboard.
| CalRobert wrote:
| Fingerprints are usernames, not passwords -
|
| related discussion (from 2013!)
| https://news.ycombinator.com/item?id=6477505
| [deleted]
| georgelyon wrote:
| Does anyone know why Apple doesn't make this standard? I've been
| using this on and off for many years and only stop because I get
| frustrated after an OS update reverts it. Are there
| licensing/security/compatibility reasons this may be the case?
| Seems like an easy fix.
| ggm wrote:
| Not lead pipe safe, don't think touch ID cares if your hand is
| attached to your body.
|
| might still do it.
| polycaster wrote:
| On the other _hand_ : Neither does password authentication
| check if it were your fingers typing.
| ggm wrote:
| Well played. You have your finger on the pulse.
| [deleted]
| Gigachad wrote:
| Why does it matter? They could already unlock the laptop with
| Touch ID. Now they can also install drivers?
| synu wrote:
| How is your password safe from someone threatening you with a
| lead pipe?
| throwaway287391 wrote:
| I suppose if you value your privacy over your well-
| being/existence you can perhaps resist giving up your
| password (not so with a fingerprint). Or maybe you could set
| up a "suicide pill" alternate password that wipes/bricks the
| machine when entered if you wanted to deprive your future
| self of the opportunity to relent as the torture escalates...
|
| (Edit: I guess the latter is also doable via fingerprint if a
| different finger is used as the suicide pill, seems a bit
| risky for normal use though!)
| gattilorenz wrote:
| > you could set up a "suicide pill" alternate password
|
| By... rewriting or modding sudo AND the login screen of
| macOS? Doesn't seem like a realistic option.
| throwaway287391 wrote:
| Yeah it was more theoretical speculation, probably not
| doable on Mac (and I don't see Apple adding this feature
| tbh). I wouldn't be surprised if someone's implemented
| something like that in Linux though.
| Sebb767 wrote:
| It's actually quite simple and readily available with PAM
| duress [0] (at least on Linux, I'm not sure about PAM on
| Mac). It was also discussed here already [1]. Still, you
| should consider that doing so might not work in your
| favor, especially if the fact that you used a duress code
| becomes obvious.
|
| [0] https://github.com/nuvious/pam-duress
|
| [1] https://news.ycombinator.com/item?id=28267975
| sebzim4500 wrote:
| If you're in the US than the cops can't force you to give up
| your password but they can force you to unlock your phone
| with your finger.
|
| I think that's far more important.
| prvit wrote:
| Okay, but if the cops get to the sudo prompt they already
| have access to all of your data...
| synu wrote:
| What's the connection with the lead pipe threat?
| ggm wrote:
| Like a password, fingerprints offer no high barrier to
| entry if you are under physical threat or control. The
| connection is that if you think your password is at risk
| to lead pipe attack, a touch entry won't fix it.
| dividedbyzero wrote:
| One option is to protect the master password with a security
| LARP scheme that's so complex and unwieldy that no sane
| attacker will believe you when you tell the truth. Like,
| Shamir's secret sharing, but the fourth part can only be
| passed via a Ballet choreography. Also, the sixth Yubikey is
| biometric and will only work with a latex fake of the right
| pinky prepared by this exact recipe. The final part of the
| password is the statistical expected value of this slightly
| unfair die, obtained after 10 000 throws, to the third digit.
| rvieira wrote:
| (I'm joking, but curious) How difficult would it be to
| implement and oximiter-like sensor along with touch id, to at
| least make sure blood is pumping through the finger?
| wyager wrote:
| It's unclear to me if Touch ID already ignores dead tissue. I
| can find some reputable sources claiming it does, but there
| seems to be a lack of consensus.
|
| > Mashable repeatedly asked Apple, Google, and Samsung for
| comment on the matter, but received not a single response to
| our numerous inquiries. We also reached out to a host of
| biometric security experts, hackers, digital law experts, and
| forensic pathologists in an attempt to get to the bottom of
| what has passed from the realm of dark thought experiment to
| serious inquiry, but the responses (or lack thereof) only
| further muddied the waters.
|
| The articles I find claiming touch ID rejects dead fingers
| seem to be written by people who have no idea what they're
| talking about, so I would not take claims about its liveness
| guarantees (hah) seriously. People mostly seem to be
| confusing credible claims about rejecting e.g. pictures of
| fingerprints with incredible claims about detecting if a
| piece of tissue is alive or not.
| 2Gkashmiri wrote:
| heh, i watched a video about putting a carrot in an oximeter
| and it showed a reading. i swept that as covid costcutting
| making shoddy equipment but i had a 2016 bought oximeter and
| i saw 50-60% saturation on a carrot and mind=blown.
|
| the problem is, you cant really say "ignore less than 70%
| saturation as that is most probably a carrot" because covid
| patients got as low as 50% so i don't know what to make of it
| zwog wrote:
| I don't know about smartphones and Macbooks, but biometric
| access control systems in buildings and such usually measure
| at least the body temperature.
| duplabe wrote:
| I think it's a much better guide with iterm support:
| https://austencam.com/posts/using-touchid-with-sudo-in-termi...
| unpopularopp wrote:
| I didn't know that module was open source!
|
| https://opensource.apple.com/source/pam_modules/pam_modules-...
| willis936 wrote:
| This is a similar project for WSL. I love it.
|
| https://github.com/nullpo-head/WSL-Hello-sudo
| pxeger1 wrote:
| For people complaining that this gets reset by macOS updates, I
| think this should work (I haven't tested this on macOS, but it
| works for me on Arch Linux):
|
| 1. Copy /etc/pam.d/sudo to /etc/pam.d/customsudo and add "auth
| sufficient pam_tid.so" to that file instead.
|
| 2. Create the directory /etc/sudoers.d/ if it does not exist
|
| 3. Create the file /etc/sudoers.d/customtouchid with the
| following content: Defaults
| pam_service=customsudo
|
| You may need to set the right permissions on
| /etc/sudoers.d/customtouchid before sudo will accept it.
| nicwolff wrote:
| I did this and set perms on /etc/sudoers.d/customtouchid to
| 0444, now `sudo` opens the dialog, but touching the Touch ID
| gets sudo: account validation failure, is
| your account locked? sudo: a password is required
| nicwolff wrote:
| Adding it to /etc/pam.d/sudo does work.
| pxeger1 wrote:
| What is the content of /etc/sudoers? My guess is that macOS
| doesn't read /etc/sudoers.d
___________________________________________________________________
(page generated 2022-06-15 23:01 UTC)