Bastien Nocera ha scritto: >> Anyway, before proceeding, I'd like feedback on some assumptions I made: >> 1) it's ok that, if pam requires authenticating w/ X>Y prints and user >> enrolled just Y prints (w/ available readers), access is DENIED > It should probably be unavailable actually, otherwise you won't be able > to stack the authentications. Ie. if you allow a fingerprint, and check > for a password when it's not available, using denied will mean that > they'll never get asked a password. Ok. So I'll have to check if there are enough "verifiable" prints (prints enrolled on now-present readers).
>> 2) any user could have prints enrolled from multiple readers > Yes. But there's only one device being handled at a time in pam_fprint, > and fingerprint data from one reader can't be used on another one. The standard one or my version? In my version I reopen the reader for every print to verify. >> 3) it is OK *not* to short-circuit a print recognition (so if X prints >> are required, X prints are scanned, even if the first fails) > That would be fair enough if scanning fingerprints was as reliable as > entering a password, but it's not, and you'd get a few miffed off users > that wouldn't know which finger print they bodged the entry for. That's intentional. Otherwise an attacker could easily "steal" a print (from non-swipe readers it's quite easy) and then identify it. Once he collects 3-4 prints and knows the corresponding fingers, he can logon w/ more than 50% probability. If he doesn't know which print he got, it's harder (= takes a lot of tests, that won't get unnoticed). Obviously it's a tradeoff: more false rejects or more false accepts? If root requires a fixed single finger, then he chooses a low-security system. If root asks for 4 fingers, he's asking for a "picky" system that should avoid false logins whenever possible. >> 4) it's OK to only return PAM_SUCCESS and PAM_AUTH_ERR (no more >> PAM_AUTHINFO_UNAVAIL) > As mentioned above, unavail should still be used. Otherwise what would > happen when the fingerprint reader is already in use or not plugged in? Good point. > The functionality sounds fine, although I didn't read the code. You > should really use git to generate it, or at the very least generate your > patch as a unified diff (diff -up). The current diff is unreadable by > humans. Already looking at how to use GIT. And trying to find the space to install it (damn "6GB should be enough for /" phrase I said when installed Mandriva!). >> Another thing I'd like to implement is handling a "fixed fingers list" >> so that different apps can require different fingers to be scanned. This >> could remove one implication (nfingers => randomlist), but adds >> another (len(flist) >= nfingers, and if strictly greater the others are >> chosen at random). > which applications would be using that? Different pam setups would > require a different pam config file. For now, I placed mine in system-auth: auth sufficient pam_fprint.so finger=-1 nfingers=2 randomize=true (finger=-1 and randomize=true are just placeholders: nfingers=2 implies'em). The "extension" could allow a line like auth sufficient pam_fprint.so fingers=05 nfingers=3 to require both thumbs and a random third finger. BYtE, Diego. _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
