UPEK Fingerprint Reader Software Puts Windows Passwords At Risk

colinneagle writes with this excerpt from Network World: "If your password management system is to use your 'fingerprint as your master password,' and if your laptop uses UPEK software, then you'll not be happy to know your Windows password is not secure and instead is easily crackable. In fact, 'UPEK's implementation is nothing but a big, glowing security hole compromising (and effectively destroying) the entire security model of Windows accounts.' On the Elcomsoft blog about 'advanced password cracking insight,' Olga Koksharova had bad news for people who thought they were more secure by using biometrics, a UPEK fingerprint reader, instead of relying on a password. UPEK stores Windows account passwords in the registry 'almost in plain text, barely scrambled but not encrypted.' It's not just a few that are susceptible to hacking. 'All laptops equipped with UPEK fingerprint readers and running UPEK Protector Suite are susceptible. If you ever registered your fingerprints with UPEK Protector Suite for accelerated Windows login and typed your account password there, you are at risk.'"

Comments

How is this a surprise...

[schaiba]

...I don't really know.

Re:How is this a surprise...

[sexconker]

...I don't really know.

You're modded -1, but your post is completely accurate.
What did people think the software was doing? Generating a key based on your fingerprint that stays the same every time you scan it and then using that key to decrypt passwords that are properly encrypted? As if!

Re:How is this a surprise...

[flaming error]

Exactly. Even if they had implemented it well, within the security community, the concept is thoroughly discredited.

The primary attribute of a user id is that it be unique.

The primary attribute of a password is that it be secret.

Biometrics are (theoretically) unique, but not secret. They make brilliant uids, lousy passwords.

Re-using uids as passwords is lazy/criminal.

In other news

[Sparticus789]

Criminals have stopped chopping off right index fingers. More news at 11

No surprise

[Anonymous Coward]

Using fingerprint data as an decryption key is very hard as the information is quite noisy. However, an decryption key is still needed to fetch the password (which, in turn, is needed for example to access encrypted files). Without a secure boot infrastructure a TPM doesn't help, so that leaves only the possibility of storing the key on-disk. Once the key is located, obtaining the password is trival so it doesn't really matter whether strong encryption is used.

This means that probably all fingerprint scanner software suffers from this flaw.

Re:No surprise

[bluefoxlucid]

Basically if the fingerprint scanner integrated with Windows Login the same way as third party login systems like Novel Networks et al, it wouldn't need your password until you tried to access an encrypted file. The flaw here is they hack it out by sending your password to Windows; fingerprint data is too noisy, you compare it as "sufficiently similar" but it's going to be too unique to generate a key from with any repeatability and high entropy. Thus they store the key UUENCODED or BASE64 or MIME to obscure it, which doesn't work on hackers. Instead, they should hook the login process and directly complete user authentication without a password, and let windows ask for a password if it tries to touch an EFS file.

Re:No surprise

[TemporalBeing]

Basically if the fingerprint scanner integrated with Windows Login the same way as third party login systems like Novel Networks et al, it wouldn't need your password until you tried to access an encrypted file. The flaw here is they hack it out by sending your password to Windows; fingerprint data is too noisy, you compare it as "sufficiently similar" but it's going to be too unique to generate a key from with any repeatability and high entropy. Thus they store the key UUENCODED or BASE64 or MIME to obscure it, which doesn't work on hackers. Instead, they should hook the login process and directly complete user authentication without a password, and let windows ask for a password if it tries to touch an EFS file.

That wouldn't really work either. What they need to do is store the password in a system encrypted file using the Windows encryption and a per-system negotiated key to access it - perhaps one that uses TPM. Or better yet, assign a specific user (configurable which) that is created for the sole purpose of managing the keys and passwords. The software gets your fingerprint, and then logs in as that user in the background (perhaps using a service) to retrieve the relevant data.

And, of course, if the wrote their own GINA plug-in or login system then they could manage it completely and then a simple authentication token for the user would be passed back so it could be used for the login.

Regardless, it wouldn't really work best unless Microsoft provided some kind of API to really support it cleanly instead of relying on each individual manufacturer. That is - have an API whereby they could store some kind of data (perhaps even with some vendor/app specific encryption) - be it biometrics, passwords, etc - that could be stored locally or in the domain; it then returns a valid authentication token that could be used to complete the login process.

Re:No surprise

[Rich0]

You couldn't use passwords stored as hashes to authenticate with remote resources - those systems are expecting to receive the password, not a hash of it. If they were happy with the hash, then storing the passwords as a hash provides no security since the hash effectively would be the password.

Re:No surprise

[KGIII]

If I had initiative I'd start a company having to do with GINA in Virginia and make a unique business name. Yes, yes I am three and have no real point other than that.

Re:No surprise

[viperidaenz]

The software gets your fingerprint, and then logs in as that user in the background (perhaps using a service) to retrieve the relevant data.

So all you need to do is get the password or token that the software uses to login to that other account and you've got access to all passwords?

Re:No surprise

[TemporalBeing]

The software gets your fingerprint, and then logs in as that user in the background (perhaps using a service) to retrieve the relevant data.

So all you need to do is get the password or token that the software uses to login to that other account and you've got access to all passwords?

There will always be a weakness. The point is to make it as hard or as difficult as possible to get to - one reason why that should not really be something that each vendor does, but rather an API that Microsoft provides.

Re:No surprise

[cryptizard]

There is actually some new research into exactly this problem. Using what they call "fuzzy extractors" you can derive a secure key from noisy information. Really cool, check it out http://www.cs.bu.edu/~reyzin/fuzzy.html

Re:No surprise

[helix2301]

So basically if you entered the windows password you were unsafe. The fingerprint itself was safe it was if you had a windows password entered you were insecure as mentioned "UPEK stores Windows account passwords in the registry "almost in plain text, barely scrambled but not encrypted." The fact that 16 major venders used this software kind scary. Some places just use bio metrics and no windows password in that case you would be safe.

Re:No surprise

[bluefoxlucid]

Except that with the NTLM2 hashes, you can't use the hash to get the password and thus can't use the password to decrypt EFS files. With the system you described, I can boot a Linux LiveCD and copy out all the passwords for all accounts, and then log into anything directly and decrypt any encrypted files I want.

Re:No surprise

[TemporalBeing]

Except that with the NTLM2 hashes, you can't use the hash to get the password and thus can't use the password to decrypt EFS files. With the system you described, I can boot a Linux LiveCD and copy out all the passwords for all accounts, and then log into anything directly and decrypt any encrypted files I want.

FYI - there is a hack for Windows that lets you mount a Windows NTFS file system, and generate a password that is close enough to generate the same hash value. Using a Windows Domain doesn't solve the issue either as the local machine retains a copy (on disk) for authentication when not connected to a network the domain is accessible from. And all the disk encryption softare also stores caches for verification unless you do not use your Windows Credentials for authenticating to the encryption software (in which case it has a cache of its own credentials).

So yes, while NTLM2 hashes are one-way hashes, they is still a known exploit for them.

Re:No surprise

[bluefoxlucid]

Uh, no. Maybe with rainbow tables calculated ahead of time, but the hashes are MD4 and not really easily cracked. On the other hand, the actual password used is needed to generate the encryption key for EFS--an MD4 collision isn't "close enough". Physical access always gets you authentication, but it won't get you the actual password (you can't use what you get to log into other accounts with the same password--ie bank accounts) and it won't get you encryption keys.

Security Theature NOW ON BROADWAY

[RobertLTux]

so how long has this been in use before somebody noticed the passwords were effectively PLAIN TEXT??

folks this is about as smart as swimming near Amnity Island with an open wound on your ankle.

I propose any kind of Silver Bullet be subjected to the Mitnick Test (throw it at a group of blackhats and then see how long it takes them to break it fix what you find and then pay them enough to keep quiet)

Re:Security Theature NOW ON BROADWAY

[gstoddart]

so how long has this been in use before somebody noticed the passwords were effectively PLAIN TEXT??

You know, this kind of stuff happens all of the time -- because people are lazy, under pressure from the boss, or just plain stupid.

Several years ago, I was helping to install some software which was supposed to go onto the machine in the DMZ and reach back into the firewall to access a database.

It turns out the software stored the admin password in cleartext in a registry key (zero attempts to obfuscate, let alone encrypt). I started shouting this quite loudly to anybody who would listen, and tried to explain why this was ludicrous.

Eventually I got told it was a low risk, and that I should shut up. Sometimes, management overrules you on these things.

Sadly, I'm betting someone brought this to someone's attention, and got told to STFU.

Re:Security Theature NOW ON BROADWAY

[dgatwood]

It's not the fact that it is plain text that concerns me. What concerns me is that it uses a password at all. I'm not personally familiar with how Windows does things, but if you were implementing this on OS X, you'd implement a custom authorization plug-in that would be queried for permission instead of using a password. I assume that this is just a case of the implementors of this particular fingerprint reader tool not knowing what they're doing.

One of two things is true: either the device can reproducibly generate a long enough crypto key (based on the fingerprint itself) to provide adequate protection on its own or it doesn't. If it does, you don't need to store the password. That crypto key can be used for things like full disk encryption, etc. If it doesn't, then no matter how you store the pasword, it will never be secure, because the key must be stored somewhere, too, and as long as the crypto key is stored somewhere, it doesn't matter if the password is in plain text, ROT-13, XORed with a known sequence, or encrypted with AES-128 or AES-256; if Eve = Alice, Eve gets your password. Encryption is basically useless here for the same reason that DRM is basically useless. In other words, no matter how the password is stored, it is fundamentally and unavoidably insecure by design.

The only way to do something like this with even the slightest bit of security is with an authorization plug-in. Further, unless the hardware/software can reproducibly generate a long crypto key from a fingerprint, the only way to support full disk encryption would involve storing the key in some form, in which case it would be fundamentally insecure because you'd have the Alice = Eve problem again.

Re:Security Theature NOW ON BROADWAY

[viperidaenz]

They're blackhats. They're not good honest citizens. They'll tell you some of the flaws they find so you give them money. They'll keep the others to extort more money out of you in the future. You know, like an investment.

Re:Security Theature NOW ON BROADWAY

[RobertLTux]

hence you would be paying them enough to keep them happy (budget for the extortion in a way) and or get 3 groups that HATE each other to check each other (have a red blue and green team)

Re:Security Theature NOW ON BROADWAY

[viperidaenz]

What about a red, blue, yellow and purple team?

Re:Security Theature NOW ON BROADWAY

[RobertLTux]

needs to be an ODD number of teams (breaking any possible Ties)

Re:Security Theature NOW ON BROADWAY

[viperidaenz]

Who should we add then? Henry the Octopus, Wags the Dog, Dorothy the Dinosaur or Captain Feathersword?

Is it really secure anyways?

[biochozo]

We were issued laptops with fingerprint biometrics in a science class a couple years ago. I swiped my finger on my friends laptop and it logged into his account for me. Hopefully, despite this new found security hole, they have come a long way since then. I haven't seen these used anywhere. Does anyone find fingerprint biometrics to be useful? Secure? Maybe it's really just to keep the honest people honest.

Re:Is it really secure anyways?

[Anonymous Coward]

I haven't seen these used anywhere. Does anyone find fingerprint biometrics to be useful?

It is very useful to laptop salesmen and computer manufacturers as a selling point/gimmick for the clueless masses.

Re:Is it really secure anyways?

[Mister Whirly]

Where I work everyone wanted to use fingerprint scanners as the sole method of authentication. I argued for two factor if using fingerprints - either a password or smart card. They argued up and down how fingerprints were unique, and then I logged into 2 out of the 6 laptops in the meeting room using my unregistered fingerprints. The idea was quickly abandoned thereafter. I have since tried this on a number of the Dell laptops with fingerprint scanners here and have a roughly 15-20% chance one of my fingers will log me into an account. Fingerprint scanning is like putting a 3 inch fence around something you want to protect. Yeah there is something there, but it doesn't take much to defeat it.

Re:Is it really secure anyways?

[DarkOx]

In general the error rate on the ones cheap enough to put on portable computers is to high to use a sole security device anyway, despite everyone and the brother pretending that they are. If you tune it for to favor type II errors, they can be secure but will be overly frustrating for the user, it will take many swipes most of the time before a good read and match. If it biases toward type Its most likely that if I line up a room full of random people one of them is going to have a finger that will work at least once, and that really should not be acceptable from a security perspective.

Personally I think these things are best used as a second factor, you know your password and your figure print is a likely match. There is very little software that does this however.

Re:Is it really secure anyways?

[jedwidz]

That's about the same as my success rate after I registered my fingerprints.

It was faster to just put my gloves on and then type my password.

Re:Is it really secure anyways?

[Hadlock]

The Thinkpad fingerprint utility allows you to set high and low verification requirements. The high req requires me to swipe 2-3 times often before it will let me in.

Re:Is it really secure anyways?

[eam]

Still, why would you use an authentication system that relies on a password that is copied every time you touch something? You leave copies of your fingerprints everywhere. Heck, the majority of thinkpad users probably have a copy in the middle of their screen.

Re:This is a non-issue.

[The MAZZTer]

As the article states, individually encrypted files using EFS would normally be secure even with the method you mention since that method does not obtain the Windows password, You can only access machine unencrypted files, or reset a password. Windows itself is as secure as you could expect. As you said the same can be done to Linux.

Still I can imagine some people think Windows machines are "secure" somehow if they just have a password on their account. These people would likely assume their system would be more secure with the UPEK reader.

Also it sounds like this UPEK software has more features, probably browser passwords and such, so there may be more problems using the UPEK software. This article doesn't state it though.

Interestingly the manufacturer is claiming passwords are stored using AES. It would be interesting to see someone else follow up and see who is telling the truth.

never trusted it. always disabled it

[darue]

Not a surprise that it's vulnerable, but it is surprising how badly they stored the passwords.

More Checklist Security

[fm6]

Remember that Simpsons ep where Smithers and Burns have to enter their top secret command post? They pass through a dozen high-tech security portals worthy of a James Bond movie to get there. Unexplained is why they didn't just use the other entrance, which consists of a broken screen door.

Then there's the ISP I used to work for that advertises "Biometric security access". What is means is that a server room in an office building has a lock that can be opened by employee fingerprint. Of course, it can also be opened by an ordinary key, which is what building security uses.

People buy security tech, and they think they've solved a security problem. Once again I quote Bruce Schneier: security is a process, not a product.

Never rely on a single authentication method.

[QilessQi]

The best authentication has three components:

1. Something you know (such as a passphrase), plus...
2. Something you own (such as the ID number from a FOB which rotates IDs every minute), plus...
3. Something you are (biometrics).

You don't use biometrics *instead* of the passphrase or FOB; you use it to augment the effectiveness of those techniques.

Re:Never rely on a single authentication method.

[bondsbw]

I disagree. Biometrics can pose a safety and security risk when used to secure very important data. It is often as easy or easier to detach a finger or an eyeball than it is to remove knowledge from someone's brain. And detaching fingers and eyeballs tend to be permanent solutions.

Re:Never rely on a single authentication method.

[tringstad]

Biometrics are not and should not be used for authentication at all, they fall under the category of identification.

Good article on the differences between Identification, Authentication, and Authorization here:

http://technet.microsoft.com/en-us/library/cc512578.aspx

There is even a section which addresses biometrics specifically.

Re:Never rely on a single authentication method.

[QilessQi]

I think we're on the same page, but talking about two entirely different things. I agree that in James Bond scenarios, biometrics might pose a risk to the owner, but I'm talking about why you don't use biometrics by themselves. The article starts with this:

If your password management system is to use your "fingerprint as your master password," and if your laptop uses UPEK software, then you'll not be happy to know your Windows password is not secure and instead is easily crackable.

Absolutely. Using biometrics as a funny sort of password -- without any other authentication methods to supplement it -- is a bad idea, even if no one is lurking behind the bushes of your house waiting to brain you with a crescent wrench and steal your index fingers.

   

Re:Never rely on a single authentication method.

[QilessQi]

Wow, that's an interesting perspective. For any tl;dr folks out there, the summary boils it down nicely:

* Identification: who are you?
* Authentication: how can you prove it?
* Authorization: what can you do?

However, if biometrics are used to back up the assertion of the username in a supplied username/password combo (in 2-factor authentication), they feel a little more like authentication than identification to me. But I see your point, and mod you Informative with my imaginary mod points.

Re:Never rely on a single authentication method.

[JimBobJoe]

The best authentication has three components:

This is an old mantra that I don't think is believed anymore (except by companies that sell biometric systems of course. :)

Numbers 2 and 3 are essentially the same...they are both something you have. The idea that number 3 is somehow different from number 2 stems from the assumption that biometrics does something special, like it's uncopyable. It's not magical though and it really is just something you have.

Re:Never rely on a single authentication method.

[tringstad]

if biometrics are used to back up the assertion of the username ...

Biometrics is intended to replace the username, not "back it up".

... in a supplied username/password combo (in 2-factor authentication) ...

Username/password combinations are NOT 2-factor authentication. 2-factor authentication is more along the line of the OP's first two examples of something you have plus something you know. For instance, my gmail account is secured using Google's 2-factor implementation and my smartphone:

http://googleblog.blogspot.com/2011/02/advanced-sign-in-security-for-your.html

... they feel a little more like authentication than identification to me.

Hopefully this is no longer the case.

Re:Never rely on a single authentication method.

[tringstad]

And I just realized that you ARE the OP.

Imaginary mod points back at ya.

Re:Never rely on a single authentication method.

[Anonymous Coward]

Biometrics cannot be used for authentication without a security guard who pays attention that you are not trying to bypass the biometrics scanner.

Biometric authentication is extremely easy to bypass:
1. fooling the scanner directly, using a printed fingerprint, or a face mask, a picture of an iris. It is possible to make scanner that are better, but that also increases false negatives, so most scanners are simple. Still they can be fooled.
2. recording the output of the scanner, simply play it back.

So for point one, you need a security guard to: clean the scanner after every use, thoroughly check the finger for fake fingerprints, keeps hold of the finger as he presses it against the scanner. As an extra bonus he could do a facial recognition himself as the system shows a photo id which belongs to the fingerprint.

For point two the scanner and the equipment between the scanner and the computer system needs to be temper proofed and/or under continues surveillance.

Remote fingerprint or facial recognition systems are just silly. The 4 digit PIN for you debit card is more secure.

I actually want to add a 4th factor, which I haven't seen yet.
4. Where you are (the location of the terminal you are accessing). Banks use this to detect fraud by seeing if funds are being withdrawn in locations that you are not likely there. Games use record and check the IP address if you have access.

And the 5th factor is really scary, it is often used as a master key to get into your account by many companies.
5. Something everybody knows of you (security questions, like what high school did you go to)

a secure boot doesn't even com into it.

[Anonymous Coward]

Secure boot has no relevance at all.

This situation is the same for ANY biometric login method. The actual password has to be stored for decryption.

Re:a secure boot doesn't even com into it.

[Rich0]

Actually it is quite relevant. Just search for examples of using TPM, linux, and trusted Grub to store passwords that can only be retrieved if you boot via the same boot chain. All that Palladium stuff that started the whole treacherous computing buzz years ago was fully implemented in hardware and BIOS - it is only Windows that doesn't generally support it.

If you boot into an OS that supports it, you can store keys in a TPM hardware vault that can only be retrieved if the software that stored them is run (with the chain from BIOS-bootloader-OS-drivers-application intact), or if the TPM is defeated.

This is used by many full disk encryption systems. Those can get away with it on Windows since the encryption happens very early in the boot process - before the lack of Windows support breaks the chain of trust. For whatever reason I've yet to see any Linux distro implement it, but both grub and the kernel fully support this.

Re:Is the Dell or Lenovo model reader?

[ThatsMyNick]

It is the same software. It usually says "Powered by Blah Blah". My HP software uses a newer version of the same software (branded as HP Simple Pass 2010 Identity Protection powered by AuthenTech), which supposedly is not vulnerable.

Re:how hard would it have been

[bluefoxlucid]

Ridiculously hard. Fingerprints are biometric, they change. You have a rough model that's similar to a rough model snapshot of your fingerprint pressed, squished, scanned, etc. Your print may possibly be rotated--orientation is random, but comparable to a known snapshot. Basically every time you image the fingerprint you get a slightly different result, and you apply fuzzy logic to work out if it matches prior data.

This also means that using fingerprint uniqueness points to generate some sort of AES key would store your password in plain text: the finger print is stored somewhere for verification, and therefor the finger print model can be used to derive the encryption key, and thus the key is stored with the ciphertext, thus plain text. (By this logic, if you attach your front door key to your front door with a magnet and then lock your front door and leave, your house is unlocked--any moron can pluck the key dangling by the door knob and open your door, you've simply altered the interface a bit. Key under the doormat is the same, takes a little more time examining it to figure out how you're supposed to open the door but you can, it's not really locked.)

It's not a security device

[joeflies]

All consumer biometric devices should not be considered "security" devices, but rather "convenience" devices. It makes it easier to log in than typinig a password, and it's more convenient than using an OTP on the desktop. But it's not secure as a password because the password store is on the computer.

As far as password lockers go, I'm inclined to trust a password store encrypted by a passphrase (like lastpass) rather than a biometric. That's because with a passphrase, you can have a very precise method of unlocking the password store. The passphrase itself vouches for you and is repeatable. A biometric scan may vouch for you, but the values it returns are not a key. Some other key is used to decrypt the password store. And that "some other key" is open to the whims of how it's implemented by the device maker.

One caveat, on the security scale, commercial biometric devices are a different animal altogether

Re:Is the Dell or Lenovo model reader?

[pixelpusher220]

A search of Dell shows a number of machines that use it linky

eye scan

[P-niiice]

What i don't understand is why in Avengers Loki used a device to actually break skin/eyeball to relay an eye scan remotely. it seems needlessly cruel. The little device could have easily taken a scan and sent the information instead of cutting into the guy's face. Was the guy going to have to give up an eye if he himself ever needed to get at the iridium?

Re:eye scan

[Dr Fro]

I think Loki just wanted to cut into a guy's face? He didn't seem like a very friendly fellow in the movie...

Rot13 is totally secure

[techsimian]

No one will ever figure out how to "decrypt" it.

Re:Rot13 is totally secure

[spitzak]

Just run ROT13 twice for double the encryption!

Pssssh

[Desler]

Psssshaw. My voice is my password.

Well that is much simpler than I thought

[AlienSexist]

I always figured that the digital representation of your fingerprint would be extracted and copied. With that copy a number of options could be possible. Perhaps the scan can be bypassed entirely and the biometric computer fed the digital copy. Or perhaps the copy can be used with the reverse-algorithm from the reverse-engineered reader to produce a fingerprint that will have the same "hash value" even if it is not exactly like the owner's. Any one of these "solution" fingerprints could be printed onto paper or some material that would allow proper scanning as a normal finger.

Let us not forget the rumored "gummy bear" attack on biometric readers in the past.

But no, I guess it is far ,far easier to just read the users password out of the registry from where the biometric system wrote it.

Windows services "log on"

[whoever57]

Under recent versions of Windows, services can be configured to "log on" as a particular user in order to run. This requires the password to be entered.

If the user's password is later changed, the services will not run, because the "log on" fails. This implies that the password is being stored (perhaps encrypted) somewhere in a fashion that the password can be recovered (in order to be used by the service to "log on").

If the OS can recover the user's password to log on a service, then other programs should also be able to recover the password.

Have I misunderstood what is happening to the user login, or is it another hole?

Re:Windows services "log on"

[whoever57]

Your understanding is wrong. User passwords are stored as hashes. For "Log on as a service", the password is stored in the WMI database somewhere, and there are no methods for querying it.

Just because a method isn't provided does not mean that it cannot be written.

Re:Ha Ha HA!!!

[Anon-Admin]

No it says that windows has a "Security model" I am guessing it is a Model of the HMS Titanic.

Re:how hard would it have been

[dgatwood]

Not necessarily. It *might* be possible to store the data used during the verification process in such a way that it would not be sufficient to reconstruct the key data in the absence of the actual print. For example, if you need ten data points, you might choose fifty data points and store a copy of forty of them, which you would then use to distort the scanned image so that the remaining ten would be correct with a high degree of probability. That *might* get you your ten robust data points without actually telling you anything about them.

Alternatively, you could use a cryptographic system designed so that each piece of data provides a portion of a key, and any k of the n pieces of data are sufficient to reconstruct the key. This might be done in any number of ways, mostly involving sophiticated checksums and error correction, and you might even have to have the equivalent of a .par file for your crypto key, but it should be possible, at least in theory.

Or it might require combining techniques like these with who-knows-how-many other techniques.

I have no idea if anybody actually has developed such technology, though. Biometrics are insecure for so many other reasons (triviality of duplication and the inability to change them being the most obvious) that they really aren't that interesting to me. :-)

Missing the point

[Rich0]

The summary states that the passwords are scrambled but not encrypted. I fail to see the distinction. If I take a word and reverse it, that is a form of encryption. Sure, it is a very weak form, but it is.

And if you're going to just store the session key in the registry then it doesn't matter if they're using AES with a 5000-bit key.

If they used strong encryption on the password database, and then used TPM to store the session key, with a full trusted boot chain to the software needed to obtain the keys, then that would be pretty strong. However, I don't know that enough of Palladium was ever implemented to make this practical. Full-disk encryption software tends to work this way, but that runs before the bootloader, so it only needs the boot chain to be secure up to that point.

Re:Missing the point

[Anonymous Coward]

The summary states that the passwords are scrambled but not encrypted. I fail to see the distinction.

No, if you take a word and reverse it that is not a form of encryption. It's a form of encipherment.
Enciphering something is the process of applying a calculation or formula to it to obfuscate it.
Encrypting uses a secret key - in security systems a unique one - in order to make it computationally impossible to retrieve the original data without the secret key.

Re:Missing the point

[Rich0]

I don't think the terms are used quite so consistently as you suggest.

Block ciphers use keys. And when looking up the definition of encrypt in a dictionary the first definition was "to put into code or cipher."

Clasically ciphers and codes have tended to be distinguished on whether they operate at the level of meaning (usually words) or syntax (usually characters).

Which Registry Entry?

[bazald]

Can anyone tell me which registry entries I should check for? I'd like to verify that uninstalling the software has removed my "barely scrambled" password from the registry.

Re:how hard would it have been

[ngc3242]

As others have pointed out all over, what you're suggesting isn't feasible. What is feasible is that the sensor acts like a secure key store. When a finger is swiped that matches an enrolled finger, the sensor releases a key associated with that enrollment.

Re:Is the Dell or Lenovo model reader?

[viperidaenz]

Yes, social engineer a finger print.

Re:This is a non-issue.

[anomaly256]

What I don't get is why it needs to store the windows account password at all. If they wrote a proper authentication plugin for the windows security model, they would just need to know the user's SID and have permission to go 'Yep, the person at the console is in fact this SID' without needed to provide the password at all. I've done this before, it's really not all that hard either, day or 2 of digging through docs and actual coding. *confused*

Doesn't W7 do this by itself?

[mlts]

I don't see on a modern laptop why UPEK would even be installed in the first place. If a laptop has a fingerprint scanner, Windows 7 or even Vista will find it and have a native process in place to enroll fingerprints and attach that as a credential to logging in.

I don't know how secure W7 stores that info, but I'm pretty sure it wouldn't be something trivial to decode. Add a TPM chip and BitLocker [1] to the mix, and the fingerprint database is definitely well protected against intrusion.

[1]: If you are leery like me, you use a TPM + PIN + a nonce on a USB flash drive. This way, if the laptop is off or hibernated and it gets stolen, if the USB drive is still in the pocket, then there is assurance that the laptop's OS is well locked down. Even then, I like working completely from remote via GoToMyPC, or some other protocol so the laptop essentially is a glorified terminal. That way, if something does happen and the laptop is happily running and unattended, the damage is still minimal. If I have to store stuff locally, I use a TrueCrypt volume with keyfiles stored on a hardware-secured USB flash drive [2].

[2]: Only one I've really seen that is well engineered are the old IronKeys, now made by Imation. The advantage of these is brute force resistance. 10 wrong password guesses, the key either fries itself or erases itself depending on type.

Re:Is the Dell or Lenovo model reader?

[Khyber]

Easily done. Here, touch this piece of tape. I now have your fingerprint. A good 2D camera with magnification and a 2D/3D modeling program and a 3D printer and you could print your own fingerprint.

Re:This is a non-issue.

[MightyMartian]

Been a long time, but I recall that you could even write custom authentication plugins in VBScript/JScript back in the day and most certainly you can do it with .NET. Why anyone would build a system this way is beyond me.

Re:This is a non-issue.

[cryptizard]

Right, but then what if you have your home directory encrypted? Usually this key is not stored but derived from your password at login time. You can't do that with fingerprints.

Re:This is a non-issue.

[anomaly256]

Ah right. Does windows allow you to change the encryption key on the home directory after the fact? I guess it must since people change their passwords. UPEK could re-encrypt it using a key derived from the fingerprint(s) or such

Re:how hard would it have been

[ewanm89]

Hard as every scan is different. Slightly more/less pressure, slightly different finger angle...

Re:Ha Ha HA!!!

[jedwidz]

The master key is in a lockbox at the bottom of the Atlantic, encrypted with a Caesar cipher, written backwards in runic with lemon juice.

Re:This is a non-issue.

[cryptizard]

But your fingerprint is not read 100% the same every time so you would not be able to decrypt any of your files.

Re:This is a non-issue.

[anomaly256]

Not the physical fingerprint, the mathematical relationship between primary features in the image kind of 'fingerprint'. You know.. the mechanism they use to match your fingerprint *in the first place* to authenticate you?

Re:This is a non-issue.

[cryptizard]

Right, but they don't require a 100% match on the extracted features. Also, if the key is derived from the fingerprint, and the fingerprint template is stored on the disk, then really the key is just being stored on the disk in a roundabout way and you don't have any better security anyway.

Re:This is a non-issue.

[anomaly256]

Read up on bitlocker @ wikipedia, the key derived from the user provided password isn't the only means of decryption. I'm SURE they could find a better way than storing the password. And if not, they can at least make it harder to get at. If anyone wants to throw enough resources at it, they'll decrypt your drive anyway. That doesn't mean you should make it easy for them.

network logins

[phorm]

Would that work for Network logins?
If you've got mapped drives, I'd imagine that the server is going to need more than a "yup, this is Bob all-right" from the client machine. If the user hasn't typed his/her password in at login, then how would it get to the remote server without being stored somewhere?
And without an authenticating master password, I don't see a way to safely store secure data. There may be an obscure alghorythm or something of the sort to mash it up, but eventually it needs to be decryptable, which - without human intervention - means hard-coded methods of doing so which are subject to discovery and abuse.
Similar issues arise in Linux-land if you have an encrypted password keystore and auto-login. You need to either login to the keystore, or re-enter your wifi password to connect to an AP, or have the AP password saved in a way that is plaintext or encrypted in a way that could be duplicated.

Re:network logins

[anomaly256]

Read up on SMB at wikipedia. It uses Kerberos authentication. It does not exchange passwords. In fact, nothing in windows land exchanges actual passwords any more. And anything that does is considered legacy and needs to be updated (eg lanman auth vs kerberos auth). There really is no reason to store a password in windows land. None.

Re:network logins

[phorm]

The client authenticates itself to the Authentication Server (AS) which forwards the username to a Key Distribution Center (KDC). The KDC issues a Ticket Granting Ticket (TGT), which is time stamped, encrypts it using the user's password and returns the encrypted result to the user's workstation. If successful, this gives the user desktop access.

So where does the password used to encrypt the TGT come from?

Re:network logins

[anomaly256]

I think you're reading the Active Directory / Domain Logon article not the SMB article. But at any rate, this just goes to highlight how stupid it is to be storing the poorly obfuscated user password if talking about Domain Logons *anyway*

Re:network logins

[anomaly256]

The really obvious solution is either: Simply don't support domain logons with your fingerprint SW because it's a bad idea anyway with how easy it is to obtain someone's print in the first place, or if you must have it, work with Microsoft to develop a secure means of authenticating on the domain by fingerprint without requiring storage of the user password. Storing the user's password is not a solution. It's a feet-dragging, responsibility-shirking copout.

Re:network logins

[phorm]

I agree that storing the password is dumb, mainly because there's currently no really secure way to do so with authentication methods that don't require a strict set of authenticators (password, card, etc).

I wasn't saying that they should be storing the password, just that it seems impossed to use a non-password measure and then still use any other resources that might require a password-based component (such as domain logins).

Fingerprints are too "fuzzy" for use as a password, so you end up with something where "close enough" is good enough for login, but will not likely be good enough to replace the password itself (so you get dumb things like storing the password in the file, convenience instead of actual security)

Re:how hard would it have been

[bluefoxlucid]

No, the problem isn't that you're storing the key; the problem is you have to store the key. If you take 50 uniqueness points from a fingerprint, you'll get 50 points that are almost close enough. You don't get numbers {3, 7, 15, 29, 37, 42} and then again get {3, 7, 15, 29, 37, 42}; what you get is {3, 7, 15, 29, 37, 42} and you store that, and when you plug in you get {3, 8, 14, 27, 36, 44} and that's close enough that it's 99.99% likely to be the same fingerprint. If you generate a key with {3, 8, 14, 27, 36. 44} it won't match the key you generated with {3, 7. 15, 29. 37, 42} and you won't be able to decrypt shit.

Re:how hard would it have been

[bluefoxlucid]

Also, if you want to use (n) keys to reconstruct, you use a finite field and plot a polynomial of degree (n-1). Two points? Plot a line. Three? Quadratic. Four? Cubic. Take four points on a cubic polynomial and run gauss jordan elimination, and you get an equation that generates ALL the points. Then pull the Y intercept as the key. So take key K and generate (rand1)x^2 + (rand2)x + K and pull 15 points, use any 3 points to solve for rand1, rand2, and K.