add support for fingerprint readers in pam_ecryptfs

Bug #255799 reported by Dustin Kirkland  on 2008-08-07
This bug affects 16 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)

Bug Description

Binary package hint: ecryptfs-utils

User request, it seems a good wishlist item to me...

"It does not seem currently possible to use this solution in combination with a fingerprint reader, since the pam module has to intercept the login password. Is this going to be a possibility in the future?" -- woutersj


Changed in ecryptfs-utils:
importance: Undecided → Wishlist
Michael Rooney (mrooney) wrote :

Hi Dustin! I have been following your work with the encrypted ~/Private and really appreciate it. I have also been following fingerprint support in Ubuntu. Have you looked at ThinkFinger / pam-bioapi ( Unless I misunderstand, this may allow this behavior.

joenix (woutersj) wrote :

Hello Mike,

ThinkFinger and pam-bioapi are indeed ways to get fingerprint support. However, I think we need a more general approach.
If we put the initial wrapping of the mount password in the pam_ecryptfs module, then it will have access to the pam authentication token, whatever that may be (password, fingerprint, smartcard, usb drive...). Then we just need a small pam-aware application for ecryptfs-setup-private to call.
The question is of course what to do when the user wants to use multiple methods of authentication (e.g. sometimes passwords and sometimes fingerprint).


Dustin Kirkland  (kirkland) wrote :

Hi, thanks so much for the bug report.

I've been thinking about this quite a bit lately. I'm going to have to mark this "won't fix" for now.

The prevailing opinion from security professionals is that fingerprints are perhaps a good replacement for usernames. However, they're really not a good replacement for passwords.

Consider your laptop... How many fingerprints of yours are there on your laptop right now? As such, it's about as secret as your username. You don't leave your password on your spacebar, or on your beer bottle :-)

This wikipedia entry (although it's about Microsoft Fingerprint Readers) is pretty accurate:

So, I'm sorry, but I don't think we'll be fixing this for now.


Changed in ecryptfs-utils:
status: New → Won't Fix
Roger Binns (ubuntu-rogerbinns) wrote :

It isn't really your place to decide what is acceptable security for users :-) The touchstrip used in my laptop is certainly way better than the finger sized static readers like those from Microsoft. Fingerprint authentication is also better than weak passwords, eg people using one of the twenty most common passwords. Pretty much any scheme can be broken (eg use a gun and coercion). And an encrypted home directory plus fingerprint is better than unencrypted and fingerprint.

Making this all work when a password isn't entered is hard, but it is solving the hard problems that distinguishes good software.

Jamie Strandboge (jdstrand) wrote :

I am not personally a fan of fingerprint readers on their own because often they can be subverted (see Dustin's comment) and because I generally don't like amputation-ware (I like all my parts where they are now, thanks). That said, someone else may have a really good reader and want to use it, and I'd have to agree with Roger that just because I, Dustin and other security professionals don't find them useful for passwords, that doesn't mean they shouldn't be supported, if those interested want to put in the work.

Combining a fingerprint reader with other authentication mechanisms can make things more secure. Eg, the fingerprint (something that uniquely identifies you), with a password (something you know) and a smart card/usbkey (something you have) would offer quite strong protection (not to mention rather severe usability issues). In this scenario an attacker needs to obtain three different tokens, which is likely more difficult than two and certainly more than just one.

Changed in ecryptfs-utils:
status: Won't Fix → Confirmed
Tyler Hicks (tyhicks) wrote :

Hello Roger - Dustin and I have talked about this feature request in the past. The bug was marked wishlist because we don't feel that it is in the best interest of the core eCryptfs developers to implement. If someone submitted a high quality patch that added the ability to use fingerprint readers, we would be dumb not to seriously consider it for inclusion, but it is unlikely to get fixed otherwise.

Dustin Kirkland  (kirkland) wrote :

Thanks to all for the latest feedback.

At this point, I'm marking this bug 'Triaged', which should be a marked upgrade from 'Won't fix' ;-)

For the reasons that I've previously mentioned (I don't have a fingerprint reader, and wouldn't use one even if I did), I personally won't be implementing this.

However, as my cohort Tyler says, if someone comes forward with a good, working, tested patch, I would certainly merge support into the eCryptfs upstream codebase. It should be quite possible to implement, as a generic PKCS-11 token within the existing eCryptfs key module framework.


Changed in ecryptfs-utils:
status: Confirmed → Triaged
Dustin Kirkland  (kirkland) wrote :

Linking this bug upstream, in case anyone there has an inkling to try and add this feature.


Changed in ecryptfs:
importance: Undecided → Wishlist
status: New → Triaged
Changed in ecryptfs:
status: Triaged → Confirmed
Changed in ecryptfs-utils (Ubuntu):
status: Triaged → Confirmed
Domen Kožar (ielectric+) wrote :

It would be nice to temporary fix user experience and provide a way to type password at first login instead of current "fail fingerprint for 5 times and fallback to password".

Thomas Hood (jdthood) wrote :

Here is how to avoid having to "fail fingerprint for 5 times" at the display manager login screen.

sudo cp /etc/pam.d/common-auth /etc/pam.d/common-auth-nofinger

Edit /etc/pam.d/common-auth-nofinger to remove the line "auth [success=3 default=ignore]"; save and quit.

Edit /etc/pam.d/lightdm (or /etc/pam.d/gdm, if that's what you're using) so that it "@includes" /etc/pam.d/common-auth-nofinger rather than /etc/pam.d/common-auth.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers