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?
> 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.
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.
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.
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.
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.
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.
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…
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.
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.
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.
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.
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.
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.
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.
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.
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.).
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.
> 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.
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.
> "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).
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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
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.
It was mentioned elsewhere in the thread that a not too thick layer of gummy bear could fool it, due to light passing through it, but getting reflected back from the back. Not sure how true is it though.
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.
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.
>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.
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.
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....
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.
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.
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.
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.
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....
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
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).
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
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)
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)
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.
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.
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.
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.
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.
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.
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
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.
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".
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.
I'm not sure whether this applies to sudo, but for device access, a biometric like a fingerprint is neither an identifier nor a password. It is closer to a session key. In any finger print system I have used, you must login with a username and password, then you have a session of access. The finger print can extend that session for some hours or days. Eventually the session rules require you to login again. Without having a recent session, your fingerprint does not provide access.
Yes, like any session-based access, it is a compromise between convenience and security. For frequent usage like phone access, I feel like it is a reasonable compromise.
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.
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.
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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'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
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.
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.
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/".
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).
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.
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)
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.
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.
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.
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.
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.
> 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 does, they're just normally fullscreen ones.
The point is that that captive portal windows persist in the app switcher, and they can't be splitscreened on an iPad. So if you need to look at your email or text messsages to find your user credentials or the login page is badly coded and doesn't pick up your password manager you're screwed. It's really, really annoying.
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.
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.
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.
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.
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.
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.
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].
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.
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.
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.
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.)
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.
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.
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...
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.
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.
You can, you just won't be able to hit the fingerprint reader without taking your fingers off the home keys, except for the little finger on your right hand (giant monster hands excluded).
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].
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?
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.
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.
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.
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!)
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.
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.
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.
(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?
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.
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
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
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…
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.
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.
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.
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.
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.
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?