Eddie Hung wrote: > The first problem here is that each user's fingerprint is stored in > the users home directory, rather than in a central location - meaning > that in order to "discover" all the fingerprints of all users on the > system, you must go through each user's home directory - not the most > efficient. Are there any plans to change this?
Full fingerprint login (no user OR pass) is certainly a desirable feature, and yes it would probably be sensible to come up with a different way of storing enrolled prints in that case. pam_fprint was a quick hack, if things need changing to implement more advanced features then that's fine. > Ignoring that, the next problem is howto check the result of one scan > against a list of fingerprints. Currently, pam_fprint utilises the > fp_verify_finger() function implemented in libfprint - and this > function takes a scan, and verifies if it matches *one* print. A > similar function, called fp_identify_finger() allows a new scan to be > verified against a list of prints, which seems to suit our purposes > better. > > However, to my dismay, I found out that this function is hardware > dependent: and my fingerprint scanner: the UBEK TouchStrip (embedded > on my IBM X41 laptop) > > Further investigation on the wiki > (http://reactivated.net/fprint/wiki/Upekts) revealed that the current > open source driver only supports verifying one print per scan - and > that verification is actually done in hardware, opposed to in software > (as I had assumed). > > However, I have seen this feature work under linux - in the form of > pam_bioapi combined with the UPEK binary driver - and I'd be willing > to try and reverse-engineer this functionality. I was not aware that the hardware could do this. Some pointers for reverse engineering here: http://www.reactivated.net/weblog/archives/2005/08/reverse-engineering/ I'm interested in doing it (I have the hardware) but it'll probably be a while before I get around to looking at it. So, if you want to take a look yourself, thats great, but I'd still request that you publish the traffic logs first. You can use usbmon to log the traffic, see Documentation/usb/usbmon.txt in the kernel source. Ideally this is what you would do: 1. Erase all enrolled fingerprints. 2. Enroll one finger for one user, while logging with usbmon. 3. Enroll one finger for another user, while logging with usbmon. 4. Login with just a single finger scan for the first user, while logging with usbmon. 5. Login with just a single finger scan for the second user, while logging with usbmon. Each logging stage should be done separately, so I'd like to see 4 separate files at the end of it. Also, try not to leave too much time before you start scanning your finger (otherwise the logs will get huge, as the driver polls the device) Please put all this on a new libfprint bug report. The logs will contain some info about your fingerprint structure. I don't know how to interpret the data, but if you're paranoid, feel free to send the logs by private email. Thanks, Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
