Jason Gerfen wrote: > Currently the pam_fprint module only looks for a valid enrolled > fingerprint scan (image) and compares it to the current scanned finger > during login. Correct? I only briefly scanned the source for pam_fprint.c
Almost: it doesn't deal with images, it deals with other representations of the finger. And I think you probably meant this as well, but it only compares against fingerprints that have been enrolled by that specific user (it doesn't consider any other users) > By implementing a secondary check for the uid, gid you are mapping a > local account to the log in process for added security... I still don't get it, sorry. This is what happens at the moment: 1. PAM says "fred is wanting to log in" 2. pam_fprint retrieves all fingerprints that fred has enrolled 3. pam_fprint starts identification using a gallery of all fred's prints 4. If the libfprint reports that the freshly scanned print exists in the gallery, fred is logged in successfully Perhaps I'd see what you're getting at if you could explain where the security flaw is here? I still don't understand the problem you're looking to solve by examining UID, GID, and password hash. > If this still does not make sense to you think about the Kerberos > authentication protocol and the TGT verification process and the > requirement of it mapping a local user account *before it lets you get a > desktop environment. My minimal kerberos understanding: The Kerberos server issues the TGT message to anyone (no authentication), but of course only the intended recipient can actually do stuff with it because it is encrypted with the client<-->AS key which nobody else knows. The TGT is verified by the TGS, because it includes some other magic blob which is encrypted by the AS<-->TGS key that nobody else knows. Still can't see how this links up with fingerprint-based authentication, sorry! > You currently can only setup the enrolled finger with a local account > right? Yes, but this is a problem that will be solved by fprintd offering a range of different storage backends. > As I stated above. There is not a problem with the authentication stack > logging a user in. It is ensuring that there are specific attributes in > the passwd database that on *most *NIX systems are required thereby > adding a stricter rule to authentication. Attributes like what? Required for what? When would they not be present? Why? Why is it pam_fprint's responsibility to enforce this? pam_fprint should be about fingerprints. In addition to missing these attributes, the system might also be missing OpenSSL and the cp command. Those are pretty important for many users. Should pam_fprint be checking that too? (obviously not, just trying to illustrate just how far off my understanding is here!) >> The getpw/getpwnam functions just read the password file. So we get to >> see the user's encrypted password. How does that assist in >> fingerprint-based authentication? > > Stated above... I still don't get it. Sorry! > Fingerprint Image storage. Everything is a photo to me. Let me know if > you need more explanation. They aren't images, but yes, I agree with this. You can take a representation of a fingerprint and stuff it in a binary representation somewhere. That's indeed how the storage backends will work. I don't see how else it could be done. Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
