Fingerprints stored in unsafe location

Fingerprint authentication is secure unless part of a two-factor scheme. Even without compromising an admin user's account, there's often enough information on say a laptop screen to break a fingerprint auth.

It is best to consider biometrics to be identification, not authentication. See Schneier's essay at http://www.schneier.com/essay-019.html and note the sentence "Biometrics are unique identifiers, but they are not secrets". Using thinkfinger is good for convenience, but not security.

Note that there are also other attacks. The device is connected by USB on thinkpads. You can simply open up the wrist rest (a few clearly marked screws underneath) and plugin a device that emulates the fingerprint reader, but always says success.

The reader in thinkpads is capable of far more functionality including storing the fingerprint within the device itself and providing a password/key on successful verification. This is available on the Windows software. The fprint page has some more detail at http://www.reactivated.net/fprint/wiki/Upekts - the lesson again is that undocumented hardware can only be partially supported by Linux.

I guess I had it coming... This bug has nothing to do with the fact we're talking about a fingerprint reader here, it is the equivalent of passwd(1) not asking for the old password when setting a new one, which would obviously be a bad idea. A fix is also just as easy: Just move the fingerprints to a secure location, so that you have to be root in order to enroll a new fingerprint (and maybe create a SUID root program to so that users not in the group adm can set their fingerprint, but I doubt that would be necessary in most usage scenarios).

That said, I do wonder about about this knee-jerk bashing of fingerprint readers. I'd argue that, for the average user, they actually provide a level of security at least comparable to good old fashioned passwords -- if not better: all the attacks on fingerprint readers I've seen described require a much higher level of sophistication than looking over someone's shoulder while they're typing in their password or maybe buying and installing a hardware keylogger. And if someone determined enough to create a device emulating the fingerprint reader has physical access to my machine, I'm pretty much screwed anyway (never mind that it would probably much easier to get a hold of my password for them, too).

Earlier versions of thinkfinger did store the fingerprint in a "secure location". They would be stored as /etc/pam_thinkfinger/USERNAME.bir with the directory and files only accessible by root. The pam_thinkfinger code may still support this.

Unfortunately this led to two problems:

 * The files had to be copied to multiple machines even when users had a single networked home directory
 * Fingerprint verification could only be done when the pam_thinkfinger module is running as root. This broke many things #138957

In Hardy thinkfinger was changed to use your home directory so that there are no issues with needing to run the pam modules as root.

If you still want root only access to the fingerprints then you'll need to write a setuid helper module for authentication - https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/138957/comments/6 If you have access to the user home directory then your setuid enrollment program won't help since the bad guy can just run it as you and enroll their fingerprint, although the real user will eventually discover that theirs no longer works.

Lastly if you have the ability to modify files in someone's directory then you can trivially get root in other ways, such as changing their $PATH to point to a trojaned version of sudo which records the password, an ssh_agent that captures their password/keys etc.

The best way of looking at the security of all this is how much would a bad guy charge to crack the systems (which would be relative to the level of difficulty and risk of getting caught). USB keyloggers are in the 10s of dollars. Fingerprints are a similar amount of money. See the mythbusters episode where they used latex, ballistic gel and even photocopies.

I have to ask, what pray tell is the security problem with storing a .bir in a homedir? SSH keys are stored there and commonly accepted, after all.

Sorry, I've been revisiting bugs related to my account, and I didn't read the initial report enough to refresh my memory. On review, the SSH thing already been addressed, but I should note that in my first reply I meant "fingerprint is insecure unless..".

I could imagine making requiring tf-tool run as root, so that enrolling a new fingerprint requires a reauthentication, but if they've enrolled a print as sudo authorative it may already be too late. Moreover .birs seem to be transferable between devices, which means you could just bring along your own bir file rather than let tf-tool make a new one. The upstream project added ACLs to place fingerprints in your homedir owned by root but user readable, but my conversations with developers suggest that ACLs won't be enabled by default until a proper interface is created.

There are two critical differences between SSH keys and the .bir fingerprint file:

1. What they are authenticating you for. SSH keys are typically used to authenticate you to a (probably unprivileged) user login shell on a remote machine. If you compromise my SSH key and can login to my webserver, the SSH key does not authenticate you for privilege escalation (sudo) on the remote host. The .bir file, on the other hand, authenticates you not only for a login shell as your local user; but also for sudo (if you have admin privileges).

2. SSH keys can easily be password protected. It is less obvious how a .bir file could be protected by a password.

It might be possible to password protect the .bir file, then sign it w/ some certificate known to root, so an attacker could not just replace the file w/ one matching their finger print. tf-tool would require password authentication before generating a new, system-signed .bir file.

This, of course, would not address the weakness of fingerprint authentication in general, nor would it prevent the $PATH attack.

A quick workaround (if your home partition lives on an ext2/3 filesystem) is to use sudo chattr +i .thinkfinger.bir.

chattr +i also works on JFS.