Hey,

Just curious if anyone has any domain experience with this. I have to replace Windows logon and Citrix logon with biometric authentication as part of a new product we're producing in conjunction with some of our business partners.

I know you can swap out or hook msgina.dll, how much of a pain in the ass is it? Does it allow you to put in the password? Ideally I'd like user to type in username, then authenticate against a facial/fingerprint/etc template, then we'd do a lookup of their password and put it into the password box.

Someone else suggested we, at a very low level, intercept kerberos tokens, but I don't see that as viable because we can't force key knowledge on other programs. I also don't see an adhoc MITM attack oriented pattern (as I view it), as a staying solution.

http://msdn.microsoft.com/msdnmag/issues/05/05/SecurityBriefs/

Yeah, I've read that but I meant in a more practical setting. Microsoft can "sugar coat" things a bit. I can't tell you how many times I've gone down a path with an MS technology only to find out later its buggy, has undocumented gotchas and complexities, and requires ad hoc workarounds in order to attain any level of stability.

And it worked like crap. It did work the way you are saying though, you put your thumb on and it would fill in the password for you. That said, don't do it. Biometrics are evil.

Hey,

Thanks for the response.

How did it work like crap? Bad matching algorithm? Slow? Would crash Windows?

It was very picky about recognizing the print. This could be good or bad, but was generally frustrating. It caused some programs to work very poorly or not at all. It ran along with every program (it wasn't just for logging in, but for logging in to other programs that require passwords as well) and if it didn't work, it sometimes wouldn't allow you to manually enter a password either. The database of password/print wasn't stored locally (bad implementation) and would fail to connect pretty regularly. It didn't handle password changes very eloquently, which would lead to getting locked out.

Did I mention this technology is evil? Do you own the data that represents your fingerprint once your employer has it? Is that information protected? When you leave do they get rid of it, including backups? If it isn't stored locally (or even if it is) is it encrypted in transit? Would that data be protected in the case of a crime or other legal reason where authorities might ask for it?

Bad matching algorightm, slow, and crashing windows (or specific programs) are all pretty accurate besides the things I mentioned above.

I appreciate your comments.

I think the interesting thing of our implementation is that it solves a lot of the issues you have concerns with. In our implementation the fingerprint/iris scan is one-way hashed into binary, so (even though its encrypted both in transit and storage), its of no value by itself. You can't get a fingerprint picture or anything back out of it once its stored.

I'm not sure which programs we'll include. I have a feeling we'll rely primarily on Windows permissions, meaning we won't log into your Quickbooks or password protected word documents or whatever. I can't get much into technical details but I'm not worried about false negatives in this scenario (its configurable to high threshold or low threshold depending on environment criterias). I'm more worried about having to log into stuff like Citrix and other third party programs.

Crashing Windows concerns me. Did the crashes happen during login or after?

That included our main app, so that was pretty much it. I don't remember if Citrix and it played nice, but I think most of our citrix apps pull domain credentials anyway, so it was kind of a non-factor. As far as the one-way hash goes... I still think it's bad idea security wise as lifting and faking fingerprints isn't really that hard. Of course that assumes that passwords that are being typed in aren't mishandled in the, "I'll just write it on a post it and stick it to my monitor" variety.

Crashes during login were rare, but system instability was pretty common as any program relying on the program we tested would flake out and either cause memory access BSoD or need to windows to be restarted in order to work again. While the latter was significantly more common, if it is a program you need to be in, it's really only marginally better than a crash. Less chance of data loss, but then you are still restarting your computer.

I must reiterate that I consider this technology ####ing evil in the corporate environment, so all my comments should be read under that light. In this case at least, I'll fully admit my own bias. I'm miles from a technophobe, but this #### just rubs me wrong in a visceral and physical way. I actually had to refuse testing (despite being a network admin, so in any beta group by default) because I literally couldn't do it. To the point that I starting sweating profusely and like twitching at the thought of doing it.

Yeah, I gotcha. I'm not sure why you find it so vile hehe, but I'll take your word for it. Security-wise in any environment where security needs to be tight you'd layer the authentication, so I'm not that concerned about faked prints.

Thanks for the tips, I wouldn't be surprised if this project is going to be a total pain in the ass.

http://en.wikipedia.org/wiki/GATTACA and you have an idea why I find it so offensive. It's actually an involuntary reaction, so I don't know for sure why I find it so vile either, but that is what I suspect.