Pushing off from Ben's email on new user creation [1] I wanted to get some setup for the think finger support that david mentioned [2].
So to start off with some technical questions about think finger, some of these might be obvious to other people besides me:
Can it's presence be detected automatically? And it's (pam) authentication be added automatically?
How many times does it take to train think finger support initially?
Can it be (re)trained incrementally? Is this required?
What are the security models required for this? Thinkfinger && password? Thinkfinger || password? Just Thinkfinger? My assumption here is that either is accepted.
Can we get the image from think finger for user feedback? Ray mentioned we might be able to fake it, which would probably be good enough.
Can we detect / remember the number of failed think finger attempts before a successful one? This is related to retraining, if it's possible to retrain the reader or human to scan better over time.
I think that's all for now, I'd like to work off responses.
~ Bryan
[1] https://www.redhat.com/archives/fedora-desktop-list/2007-October/msg00002.ht... https://www.redhat.com/archives/fedora-desktop-list/2007-October/msg00002.html [2] https://www.redhat.com/archives/fedora-desktop-list/2007-October/msg00021.ht... https://www.redhat.com/archives/fedora-desktop-list/2007-October/msg00021.html
On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
Pushing off from Ben's email on new user creation [1] I wanted to get some setup for the think finger support that david mentioned [2].
So to start off with some technical questions about think finger, some of these might be obvious to other people besides me:
Can it's presence be detected automatically? And it's (pam) authentication be added automatically?
It's a device it should be able to be looked up in hal.
How many times does it take to train think finger support initially?
3 good finger swipes that it checks against one another.
Can it be (re)trained incrementally? Is this required?
not that I've seen.
What are the security models required for this? Thinkfinger && password? Thinkfinger || password? Just Thinkfinger? My assumption here is that either is accepted.
I tested it on my rawhide laptop and while afaict thinkfinger doesn't care gdm and logins and everything else are unprepared for 2-factor auth. They'll accept a finger swipe or a password but cannot handle it if your pam config requires both.
Can we get the image from think finger for user feedback? Ray mentioned we might be able to fake it, which would probably be good enough.
the image of your fingerprint?
-sv
On Thu, 2007-10-25 at 08:58 -0400, seth vidal wrote:
Can we get the image from think finger for user feedback? Ray mentioned we might be able to fake it, which would probably be good enough.
the image of your fingerprint?
I had to give up my fingerprints to the USCIS recently, and they have impressive scanners that show you your fingerprint in fullscreen. Unfortunately, the fingerprint scanners of your average laptop don't produce anything near that resolution. There simply is no image to show...
Hi,
Can we get the image from think finger for user feedback? Ray mentioned we might be able to fake it, which would probably be good enough.
To be clear, what I was saying was:
- It would be really cool if we could show a finger print on screen when the user scans their finger - The fingerprint wouldn't have to be the user's fingerprint, just as long as it looked like a fingerprint and looked different than other people's fingerprints
I don't know what fingerprint scanners store (actual image data, or just enough information to identify the print or what). Even if we don't have a full image to show, we could potentially just perturb a fake fingerprint seeded by whatever data we do have.
Having said that, I think some scanners do give image data. David pointed me to this post he made a long time ago:
--Ray
On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
Pushing off from Ben's email on new user creation [1] I wanted to get some setup for the think finger support that david mentioned [2].
I'd actually like to make it a teensy bit more general and think about the non-Thinkfinger readers also. From my Pile Of Laptops, the Authentec readers are pretty common. And davidz has already done some prodding with them based on his blog ;)
While not very relevant to the interaction, it's mostly important so that we don't make assumptions of hardware capabilities that may or may not be present.
Can it's presence be detected automatically? And it's (pam) authentication be added automatically?
They're all usb devices, so pretty detectable. Adding the pam config is just a matter of deciding we're doing it and then adding to the stacks written out by authconfig
How many times does it take to train think finger support initially?
This probably depends on the hardware. Thinkfinger is 3 swipes and trained in hardware. Some of the other readers just give you back an image and you have to do verification[1] on your own. But probably 3 is a reasonable guess there too. It's at least the range of "more than one, less than many"
Can it be (re)trained incrementally? Is this required?
Nope, you pretty much have to do the initial readings upfront.
Can we get the image from think finger for user feedback? Ray mentioned we might be able to fake it, which would probably be good enough.
This is definitely going to be dependent on the hardware, so probably can't be counted on.
Can we detect / remember the number of failed think finger attempts before a successful one? This is related to retraining, if it's possible to retrain the reader or human to scan better over time.
PAM doesn't usually keep track of a number of failures. You could have a module do it, though if you really wanted I think.
Jeremy
Heya,
On Thu, 2007-10-25 at 10:06 -0400, Jeremy Katz wrote:
On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
Pushing off from Ben's email on new user creation [1] I wanted to get some setup for the think finger support that david mentioned [2].
I'd actually like to make it a teensy bit more general and think about the non-Thinkfinger readers also. From my Pile Of Laptops, the Authentec readers are pretty common. And davidz has already done some prodding with them based on his blog ;)
The plan for the F9 feature[1] was to not use pam_thinkfinger (it's real crap, and has some gross hacks, such as sending line feeds to accept password auth), and switch to a dbus service instead (so that we don't do threading in pam_thinkfinger).
The dbus service would be a HAL singleton, and we could obviously use a different implementation that could drive Authentec readers, or any other, given a sane API.
While not very relevant to the interaction, it's mostly important so that we don't make assumptions of hardware capabilities that may or may not be present.
Can it's presence be detected automatically? And it's (pam) authentication be added automatically?
They're all usb devices, so pretty detectable. Adding the pam config is just a matter of deciding we're doing it and then adding to the stacks written out by authconfig
And for which PAM services we'd want to enable this.
Cheers
On Thu, 2007-10-25 at 15:54 +0100, Bastien Nocera wrote:
The dbus service would be a HAL singleton, and we could obviously use a different implementation that could drive Authentec readers, or any other, given a sane API.
Maybe a bit off-topic, but as I said in my other mail, now that we have D-Bus system bus activation, the current advice from the HAL team is to use dedicated services (with standardized interfaces) and use HAL as the directory for looking up the service. That way, there's no HAL dependencies which gives us more freedom to rewrite HAL.
(More off-topic but perhaps interesting: As a matter of fact, I talked to Marcel Holtmann about this and it's probably how Bluetooth and Wireless USB audio (and other cloud services) is going to work; the interface will be exactly the same (org.fd.WirelessAudio or whatever) but the services providing them will differ e.g. org.bluez.Audio, org.wusb.Audio and so. The main consumer for Fedora of this, PulseAudio, thus does not need to care at all about the _implementation_ (only the interface) and it will enable us to plug new wireless protocols in without modifying any consumers.)
David
On Thu, 2007-10-25 at 10:06 -0400, Jeremy Katz wrote:
On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
Pushing off from Ben's email on new user creation [1] I wanted to get some setup for the think finger support that david mentioned [2].
I'd actually like to make it a teensy bit more general and think about the non-Thinkfinger readers also. From my Pile Of Laptops, the Authentec readers are pretty common. And davidz has already done some prodding with them based on his blog ;)
So the one way to do this sanely is to build a simple API that will work for our purposes; e.g. make it high-level driven by application requirements. Since messing around with auth tokens / whatever is a privileged operation, expose it over D-Bus and lock it down via PolicyKit. It doesn't need to be more complicated than the API offered by tf-tool
# tf-tool --help
ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/) Copyright (C) 2006, 2007 Timo Hoenig thoenig@suse.de
Usage: tf-tool [--acquire | --verify | --add-user <login> | --verify-user <login> ] [--verbose]
Notably, to make fingerprint enrollment work in a sane way (we're so not going to do crazy stuff like running X11 apps as root) _anyway_ you need to expose it over D-Bus. And, really, it's pretty trivial, only a matter of a few hours in C; see
on details how to do it. Hey, you can even do it in Python and since it only involves shelling out to tf-tool, it's probably on the order of hundreds of lines. Now, when we have this API we'll just merge the following properties on the hal device object
info.capabilities += 'fingerprint_reader' fingerprint_reader.dbus_service = 'com.example.ThinkfingerService' fingerprint_reader.dbus_obj = '/' fingerprint_reader.dbus_iface = 'org.freedesktop.FingerPrinterReader'
so if someone wants to do Authentec or whatever they just do a D-Bus and make an object that implements the org.freedesktop.FingerPrinterReader D-Bus interface. Then they merge
info.capabilities += 'fingerprint_reader' fingerprint_reader.dbus_service = 'com.example.AuthentecService' fingerprint_reader.dbus_obj = '/' fingerprint_reader.dbus_iface = 'org.freedesktop.FingerPrinterReader'
Our UI apps simply don't care what fingerprint_reader.dbus_service is; they only care about poking an object with the D-Bus interface org.freedesktop.FingerPrinterReader. So the UI simply does
1. hal.find_by_caps('fingerprint_reader') 2. read .dbus_service, .dbus_obj, .dbus_iface 3. checks that .dbus_iface=='org.freedesktop.FingerPrinterReader' 4. calls into the service 5. profit
David
While not very relevant to the interaction, it's mostly important so that we don't make assumptions of hardware capabilities that may or may not be present.
Can it's presence be detected automatically? And it's (pam) authentication be added automatically?
They're all usb devices, so pretty detectable. Adding the pam config is just a matter of deciding we're doing it and then adding to the stacks written out by authconfig
How many times does it take to train think finger support initially?
This probably depends on the hardware. Thinkfinger is 3 swipes and trained in hardware. Some of the other readers just give you back an image and you have to do verification[1] on your own. But probably 3 is a reasonable guess there too. It's at least the range of "more than one, less than many"
Can it be (re)trained incrementally? Is this required?
Nope, you pretty much have to do the initial readings upfront.
Can we get the image from think finger for user feedback? Ray mentioned we might be able to fake it, which would probably be good enough.
This is definitely going to be dependent on the hardware, so probably can't be counted on.
Can we detect / remember the number of failed think finger attempts before a successful one? This is related to retraining, if it's possible to retrain the reader or human to scan better over time.
PAM doesn't usually keep track of a number of failures. You could have a module do it, though if you really wanted I think.
Jeremy
desktop@lists.fedoraproject.org
-
Bastien Nocera -
Bryan Clark -
David Zeuthen -
Jeremy Katz -
Matthias Clasen -
Ray Strode -
Seth Vidal