Thinkfinger doesn't unlock keyring

[Ciso]

After a good configuration with this HowTo:
http://www.thinkwiki.org/wiki/How_to_enable_the_fingerprint_reader_with_ThinkFinger#Ubuntu
My fingerprint reader works to login, but if I login with my fingerprint, the keyring manager asks me to unlock the keyring to connect to my wifi network.
Everything's okay if I login with my text password.
Ubuntu Hardy on Dell XPS M1330

[Justin Dugger (jldugger)]

For reasons unknown to me, Network manager stores your wireless passwords in an encrypted keyring. Your password is the decrypt token. I assume you've enabled pam_keyring in common_auth, which recieves the password you type at GDM and starts the keyring manager with enough timeout to let nm-applet retrieve passwords from your keyring.

I'm marking this confirmed, to keep it a visible and known bug.

The fixes I can imagine are to either:
* place NM wireless keys out of the keyring by default (weak wireless security)
* store the keyring token within the fingerprint reader itself (good luck)
* store the keyring token on disk (bad security!)

Given the nature of the request and the very weak security of fingerprints, I think something closer to the first option is the desired solution here. I understand that Network Manager in Intrepid (http://www.ubuntu.com/testing/intrepid/alpha5#Network%20Manager%200.7) allows system wide settings.

Does this sound like an acceptable fix?

[Ciso (cisoprogressivo)]

Hi justin,
thank you for your help,
can you tell me how to place NM wireless keys out of the keyring?
Thank you

[Justin Dugger (jldugger)]

It's not a feature in hardy, but I'll see about how it works in intrepid.

[Ciso (cisoprogressivo)]

Ok, thank you.
I'll report how it works in Intrepid.

[otzenpunk (reisswolf-nospam)]

I think, placing the wireless passwords out of the keyring is not the ideal solution, because the keyring is being used for other passwords as well. (Like Samba shares or various instant messengers.) So just dealing with network-manager decreases security but doesn't solve the problem at all.

If you personally don't care about encrypted password storage, I think you could set your gnome keyring master passphrase to an empty one. Of course this will cause your whole keyring to be saved to disk unencrypted.

I personally don't mind typing the keyring password once during login and use thinkfinger for sudo, screensaver, etc.

[Justin Dugger (jldugger)]

The right way to fix this "securely" is to make the password and fingerprints required, both of them. Then you can unlock the keyring, log into WPA protected wifi, connect samba shares and so on.

Anything else is security theater. The odds are pretty good, especially on a tabletPC or laptop, that there's a recoverable fingerprint on the LCD screen. This is the fingerprint equivalent of the password on a stickynote attached to the monitor, except you do it without even trying.

[otzenpunk (reisswolf-nospam)]

Of course everything less than full harddisk encryption is "security theater", if you've got knowledgable enemies with unmonitored physical access to your laptop.

But that was not my point. Everybody has to decide for himself, which level of security is appropriate for him, and what is overkill, based on his own perceived threat. I just wanted to express my opinion, that people who do not want to use encryption to store their passwords could easily use a null passphrase in gnome-keyring before they try to configure/patch every single application not to use the keyring.

Additionally I would suggest to mark this bugreport as INVALID (or WONTFIX), because thinkfinger is not capable to open the gnome-keyring (or any other encrypted stuff) as a matter of principle.

[j0rd (jordan-gocubeco)]

The fact that gnome-keyring doesn't support thinkfinger or the settings in common-auth is actually a security weakness not strength...because if I have my common-auth set to thinkfinger+password+standing-on-one-foot+blindfolded, then keyring could simply be unlocked with the password, which is a WEAKNESS, not a strength and a bug which should get resolved.

I don't care about the security of data on my laptop. I don't have "enemies" and the fact that I use linux will deter any stupid thief from "stealing my data" and by data I mean web history because that's essentially all I use this for. No nuclear codes on this puppy.

With that said, what I do care about is having to type in another password to unlock my keyring after I login with thinkfinger. It's really annoying and adds almost 5 seconds to each login. That's a total of like 1 minute I could save each WEEK! What I would like is the ability for keyring to unlock with the settings I have in my common-auth file. Perhaps, I'm mistaken, but common auth stands for common authentication and should cascade through to all my applications including keyring.

[j0rd (jordan-gocubeco)]

Ah. Been digging around and found some wonderful insight on this issue.

<quote>
I take issue with that -- the Thinkfinger package I've adopted from Debian works quite well for several tasks. The biggest problem is one of security. I think what you want is a fingerprint scan to unlock the GNOME keyring, and firefox and friends to play with that. Sadly, this is impossible to do securely -- the keyrings work by encrypting your various other passwords and data with a master password. Without that protection, your data is sitting on disk somewhere waiting to be read by mean broswer extensions etc in plain text. You can't use a fingerprint as a substitute for a password; the scan isn't identical between reads, the print itself changes over time, and you can't securely store a password on disk to unlock encrypted data on other parts of disk.
</quote>

http://ubuntuforums.org/showthread.php?t=419617&highlight=thinkfinger+keyring&page=2

[otzenpunk (reisswolf-nospam)]

> Ah. Been digging around and found some wonderful insight on this issue.

That's essentially what I wrote. And I also wrote, that you could use a null passphrase for your gnome keyring, if you don't mind storing your passwords in an unencrypted, unsecure way because you want to save your 1 minute every week.

[mannheim (kronheim)]

The bug here seems to be the inability of gnome-keyring to work together with pam.

It seems that pam is configurable to allow various different "secrets" to be used for tasks such as logging in. Thus, pam can be configured to allow either a fingerprint or a password or both, as sufficient verification for login. However, the gnome-keyring stands apart from this: the only thing secret that will unlock the keyring is the password for that keyring (at least as far as I understand).

The security (or lack of) of fingerprint readers here is not the point. The same problem would apply to any other authentication method.

[Milan Bouchet-Valat (nalimilan)]

mannheim: As explained above by otzenpunk and J0rd, gnome-keyring has to face a different problem than PAM. PAM can arbitrarily decide to allow a user to log in, it is completely mastering this authorization process. It is not the case of gnome-keyring, which stores the passwords in an encrypted file on the disk. To decrypt you passwords, you need the master password of the keyring, this is a technical/physical/absolute requirement.

What would be needed is to replace the master password with something you can get from fingerprints. But that's not easy, if even possible: images are always different, and you would have to find a constant feature of your fingerprint without being able to compare with precedent images. Possibly a realm of investigation for future developments, but certainly not a bug to fix!

So the only solution here can be to remove secure storage of your passwords by setting an empty master password. Use at your own risk if you lose your laptop! For now, I guess this bug must be closed.

[loke (developer-loke)]

Sure putting password only as a barrier is not a security, but a protection feature. But the passwords could also be encrypted, and be unlockable with either of the keys, which is the text passwords, and the finger swipe.

[otzenpunk (reisswolf-nospam)]

@loke:

NO, IT CAN'T!

Sorry, maybe I'm just too stupid to explain this in a comprehensible way.

Last try:

Authentication and encryption are two fundamental different things. You can't "unlock" an encrypted thing(tm) with a fingerprint. To decrypt an encrypted thing you need to know the secret, which was used to encrypt this thing. (Commonly known as passphrase.) This is not the place to teach the most trivial basics of cryptography, but you could read the last comment by Milan again to learn, why you can't use fingerprints for that.

If you would like to allow pam to do the decryption, you would have to provide pam with the secret, and if you don't want people having to enter this secret manually, then you'd have to save it on disk, which would be equivalent to writing your password with a big marker onto the frame of your monitor. (And no, you can't encrypt the passphrase itself without introducing another secret - hen and egg problem.)

So if you don't mind about effective encryption of your password safe, then use an empty passphrase for your Gnome keyring and go ahead. But please, people, stop filling this bug report over and over with this same crap. Thinkfinger can't open the keyring and most likely won't ever. At least unless it is discovered, that the hardware itself does contain some kind of password store.

Full stop.

*tagging this bug as invalid*

[loke (developer-loke)]

Reisswolf:
Sorry to have upset you. But I think you missed something about the
encryption, and the fingerprint data, which indeed would be some kind of
hash or string. Then why can the fingerprint data itself not be a key,
or a hash calculated on the fingerprint basis? I mean make a public key
on the basis of the fingerprint data. Once the fingerprint data is
available, "which is acting the secret key", pam should be able to
decrypt the stored password.
Loke
On Fri, 2009-01-02 at 20:10 +0000, otzenpunk wrote:
> @loke:
>
> NO, IT CAN'T!
>
> Sorry, maybe I'm just too stupid to explain this in a comprehensible
> way.
>
> Last try:
>
> Authentication and encryption are two fundamental different things. You
> can't "unlock" an encrypted thing(tm) with a fingerprint. To decrypt an
> encrypted thing you need to know the secret, which was used to encrypt
> this thing. (Commonly known as passphrase.) This is not the place to
> teach the most trivial basics of cryptography, but you could read the
> last comment by Milan again to learn, why you can't use fingerprints for
> that.
>
> If you would like to allow pam to do the decryption, you would have to
> provide pam with the secret, and if you don't want people having to
> enter this secret manually, then you'd have to save it on disk, which
> would be equivalent to writing your password with a big marker onto the
> frame of your monitor. (And no, you can't encrypt the passphrase itself
> without introducing another secret - hen and egg problem.)
>
> So if you don't mind about effective encryption of your password safe,
> then use an empty passphrase for your Gnome keyring and go ahead. But
> please, people, stop filling this bug report over and over with this
> same crap. Thinkfinger can't open the keyring and most likely won't
> ever. At least unless it is discovered, that the hardware itself does
> contain some kind of password store.
>
> Full stop.
>
> *tagging this bug as invalid*
>
> ** Changed in: thinkfinger (Ubuntu)
> Status: Confirmed => Invalid
>

[Justin Dugger (jldugger)]

gnome-keyring stores your passwords on disk, encrypted with a single passphrase. You make the phrase on creation and re-enter it again later to open the ring. The additional challenge is that nobody should be able to recover the data without also knowing the passphrase. So the datastore itself has to be imbued with mathematical properties related to the passphrase, and the passphrase change (unless you also have the old passphrase).

Fingerprint identification works by doing a fuzzy match of a given scan to a registered print. These fuzzy match algorithms are even subject to export controls (normally). Any given scan will be different, as your fingerprint changes over time. Scars, wounds, warts, orientation etc can affect the scan. So the given scan can't be an encryption key, because every scan is different and has far too few stable properties.

The registered print likely can't be a key because it's stored on disk and we don't know the format etc. The format itself is encrypted to prevent an attacker from crafting their own fingerprint based on the registered print, so not a lot is known about it.

About the only way this could work is if the fingerprint device itself had a secured datastore, working on the theory that it's much harder to attack the chip itself than a regular storage device. Place the passphrase and a registered fingerprint in the datastore and only release the passphrase when a matching print is offered.

[otzenpunk (reisswolf-nospam)]

> But I think you missed something about the encryption, and the
> fingerprint data, which indeed would be some kind of hash or string.
> Then why can the fingerprint data itself not be a key,

Because of what Milan wrote. Your fingerprint isn't exactly the same, whenever you scan it. Maybe you turn your finger slightly to one side or the other while scanning, or move it at a different speed. It is the business of biometrical systems to cope with that and use some kind of fuzzy logic to identify not just 100% identical finger scans but those who are sufficiently similar to allow positive recognition. (While it is the business of cryptographic systems, on the other hand, to do exact calculation and not to reveal the decrypted data to attackers guessing only some pieces of the passphrase.)

Additionally the way things work requires, that you have to have a copy of your finger data installed on the system to do the comparison. If you use this data as a passphrase for your password safe, we are going round in circles again.

In the case of the Thinkpad fingerprint scanner and thinkfinger there is the additional fact that the comparison of the fingerprints is done by the scanner itself, and not by the driver software. The driver provides the scanner with the .thinkfinger.bir data and tells it to scan a finger and do the comparison, and then it just returns yes or no. Of course you could totally rewrite pam_thinkfinger to do the comparison itself and use functionality like tf-tool --acquire for every authentication process. But of course it would return slightly different data with every scan - believe me, I've tested it - and so the problem mentioned above would remain.

[Milan Bouchet-Valat (nalimilan)]

That said, would it be possible to detect when a laptop is using fingerprint authentication and propose the user to use an unencrypted keyring, explaining security risks and inherent limitations of fingerprints? I'm just dreaming here, but it could make sense.

[otzenpunk (reisswolf-nospam)]

I'm not sure if it would be a good idea to actively encourage this. Maybe just create a new README file under /usr/share/doc/libpam-thinkfinger?

[Carroarmato0 (carroarmato0)]

Just for information, the biometric device on the Dell XPS m1530 is capable of storing the hash either on the chip itself or not.

[MvW (2nv2u)]

Any progress on this issue?
Using 910RC on a Dell Vostro 1310 right now and nothing has changed.
Using you finger print to login is pretty much useless if you have to type in your password immediately afterwards.
You should even be able to login without selecting a user in the login screen altogether.
Agree this degrades the security level a bit, but if you use the face browser(which is default now) it's just a matter of trying all available users.

[Mattias Eriksson (snaggen)]

I guess the upstream bug is:
https://bugzilla.gnome.org/show_bug.cgi?id=501204

[spmccann (sean-mccann)]

This is very disappointing. I'm running a Lenovo Thinkpad T61. The fingerprint authentication works fine under MS windows 7. I'm running a clean install of maverick. I've installed think finger and followed the instructions and am now presented with a password authentication dialog box for the keyring. So I know the device runs under Maverick but is not integrated into the system keyring. This defeats the purpose of having a biometric login.

With biometric authentication devices becoming more popular on consumer devices its important that they work under Ubuntu.

[bankey (bankey-biharidassa)]

Security is:
one thing to have + one thing to know

in other words:. fingerprint + password = secure

I have here a T61 too and was looking into the same issue (unlocking keyring) but after reading the arguments and remembering the lesson "security" I just accept it..

thanks for explanation..

[Andrew Bolster (bolster)]

The implication of setting up thinkfinger for login is a combination of security and convenience; for instance, I set up thinkfinger because I have a tablet, and it is convenient for me to leave the tablet in tablet configuration around 80% of the time, not needing the keyboard, but it is decidedly more secure than autologin, which would accomplish the same convenience.

As it stands, if people want to maintain the semi-secure convenience of thinkfinger, the suggested solution across the webz is to create an empty keyring password; which is obviously a very bad idea.

I believe this is a bug, in that from the user facing side, the keyring manager shouldn't be seen. In an 'Ideal World(tm)', the keyring manager would accept a valid PAM authentication as being satisfactory.

However it could be implemented, it would pose an increased security risk, as the access vectors to the keyring are being opened up, so I'd imagine that the only practicable way of doing this would be to have an option in the keyring store (a la the change password window) that states "Allow transparent login with PAM data" or something similar.

This would increase the convenience for those thinkfinger users who care primarily about security, increase security for those thinkfinger users who care primarily about convenience, and since it would be an opt-in, would pose no/little risk to non-thinkfinger users.

[Milan Bouchet-Valat (nalimilan)]

Le samedi 07 mai 2011 à 17:50 +0000, Andrew Bolster a écrit :
> In an 'Ideal World(tm)', the keyring manager
> would accept a valid PAM authentication as being satisfactory.
We *can't* do that. The keyring is a real secure place, thus we can't
just decide to release the passwords: we *need* the master password to
decrypt them. Really.

Fingerprints are not passwords, they are matched against an already
known fingerprint, which has to be stored somewhere, defeating the idea
of protecting your password.

[Juaco (kankito)]

Wait a minute. I've come to this report by a similar problem (authentication via pam-usb and/or pam-face and gnome-keyring asking for password).

What about storing the keyring with a blank password in an encrypted filesystem to be unlocked by pam-mount? Could you see this working? I'm tempted to try it right now.

[Milan Bouchet-Valat (nalimilan)]

That's the same problem. *Conceptually*, pam-mount or any other encrypting method cannot read something encrypted without the authentication mechanism providing a secret *that isn't stored on the computer*. So the authentication device must store the password in some hard-to-read place itself for this to work, and I don't think it's the case ATM.

[Juaco (kankito)]

I see now how it goes. The only way to cut out of the chicken and egg problem is an external secret at some point, by means of this scheme (http://wejn.org/how-to-make-passwordless-cryptsetup.html) or similar.

[Miroslav Zaťko (mirec-z)]

maybe importance of this problem should be lifted to maximum level...

[Phil Gillaspy (phgphd)]

Could authentication be abstracted to one level higher by implementing following requirement: if authentication is via fingerprint, then accept fingerprint reader output, otherwise use gnome keyring via password.

[Rafael Henrique Santos Rocha (rocharhs)]

This is still an issue in 2024. Authentication via fingerprint asks for keyring just after login