The Daily WTF: Curious Perversions in Information Technology

2011-04-07 Reply Admin

Synchronos:
Abso:
Note that "You don't need X" is not a good way to say "You don't need X, except to do a lookup which you need it for."

Just to add one more thing to that: "Of course, you'll have to store the password in plain text so you can look up the salt, at which point the salt isn't very useful. Or you could try every salt in the system for every login, but that might be just a teensy bit slow." isn't very efficient way to say "no, you still need the user ID to look up the salt," either. Which would have communicated a bit better which you found to be in error in my comment. But that is human communication: always assume misunderstanding.

True enough.

hoodaticus · 2011-04-07 Reply Admin

C-Octothorpe:
Boris Vladamir:
Nagesh:
hoodaticus:
Am I the only one who gets frothing mad that incompetents like this have taken jobs I could have had? Because that knowledge drove me fucking nuts when I was unemployed.

And what was exact cause of unemployment?
Most likely the intercourse he was having with patients in mental hospital.

Damn, you beat me to it... I was going to say most likely due to intercourse with patients in the stable...

Nope; you're both wrong. I was having sex in the stable at the mental hospital. I can confess this freely, since you are all a hallucination anyway.

hoodaticus · 2011-04-07 Reply Admin

Nagesh:
hoodaticus:
Am I the only one who gets frothing mad that incompetents like this have taken jobs I could have had? Because that knowledge drove me fucking nuts when I was unemployed.

And what was exact cause of unemployment?

I was both a lowly employee and a contractor for the board of directors with fiduciary duties to them. My boss asked me to withhold information from the board, which I could not ethically do. So I quit. That same day.

Best decision I ever made.

2011-04-07 Reply Admin

Bryan the K:
Who's password was god?
/Too obscure??

no.

da Doctah · 2011-04-07 Reply Admin

SCSimmons:
(Is that a number 1, an upper-case I, or a lower-case l? Screw it, we'll make up our own password to assign to him.)

And that, ladies and genitals, is why Comic Sans is better than Arial, Times New Roman or Prestige Elite.

dkf · 2011-04-07 Reply Admin

mangobrain:
Schema as follows.
Username table: columns "Username" (unique), "Numeric ID" (unique)

Hash table: columns "Numeric ID" (matches up with numeric ID from username table; can be indexed quickly), "hash"

Salt table: columns "Numeric ID" (see above), "salt"

Idea being that even if a hacker steals all three tables' rows and knows the hash algorithm, they still can't look in their rainbow table for a convenient string which hashes to the target hash, because chances are their rainbow table's entry won't end in the characters from the salt table. Seriously, this wasn't even my idea, but calling the guy fucking retarded is just unnecessary.

Of course, you could just put all that information in one table (indexed by username only) and have the same level of real security. All you get from splitting it up like that (apart from a “by obscurity” fig leaf; remember, attackers know how to look at database schemas for foreign key constraints!) is more opportunity for things to go wrong in code, and more problems with performance.

Rainbow tables are a way of allowing attackers to compute hashes for passwords ahead of time. Using a 64-bit random number on the front or back (the salt) defeats that by requiring the attacker to construct 2**64 times as much data (still thoroughly impractical). Assuming a non-crap hash function is used. Salting does nothing against dictionary attacks, which use a totally different method.

Myself? I'd much rather require everything to use crypto keys (e.g. SSH RSA keys or SSL in client-authenticated mode) because they require the attacker to guess a hard, long-bit-length crypto secret from the word go.

2011-04-07 Reply Admin

Abso:
Synchronos:
Abso:
Note that "You don't need X" is not a good way to say "You don't need X, except to do a lookup which you need it for."

Just to add one more thing to that: "Of course, you'll have to store the password in plain text so you can look up the salt, at which point the salt isn't very useful. Or you could try every salt in the system for every login, but that might be just a teensy bit slow." isn't very efficient way to say "no, you still need the user ID to look up the salt," either. Which would have communicated a bit better which you found to be in error in my comment. But that is human communication: always assume misunderstanding.
True enough.

Hash the password, generate a salt based on that hash. Use that salt on the original password and hash again. Each user is identified by a combination of two hashes generated by one password.

The problem with this is that a cracker with create permissions can keep trying to create login passwords until they find one that is rejected because it is 'already in use'. Or just run one dictionary attack. (I bet variations on asAS12!@ are pretty common in systems that require a 'strong' password)

2011-04-07 Reply Admin

What is this? I don't even...

Coyne · 2011-04-07 Reply Admin

Why is this titled, "The Phantom Password"? It looks to me like it's the user ID that's phantom.

2011-04-07 Reply Admin

Matt Westwood:
neminem:
somedude:
Greg:
Not quite. 2 can be separated from you, 3 cannot.

Wanna bet? (grabs his hatchet)
Don't even necessarily need to resort to such violent methods; as spy shows have shown repeatedly, in many different ways, all you need is a sufficiently similar replica. As Michael Westen once pointed out, "Nobody wipes off a fingerprint scanner after they use it, so what's left on the scanner, nine times out of ten, is a fingerprint." Just stick the fingerprint on something else, reuse it, bang. Fingerprint, separated from the guy's finger without having to actually... separate the guy's finger.

Does this work for those scanners where you swipe your finger over a narrow (1mm) glass window? Doubt it.

No, it doesn't, because those use electrical conductivity to scan the fingerprint.

2011-04-07 Reply Admin

Decius:
Hash the password, generate a salt based on that hash. Use that salt on the original password and hash again.

That is only a slight variation of a hash algorithm, not real salt. Real salt adds (a lot of) information to the password before hashing. Your method only adds the knowledge of how to make the rehash. Which means you cannot use public source code, at least.

excession · 2011-04-07 Reply Admin

We're using Active Directory on Windows server, and the policy for account lockout is 'three bad password attempts', and "once locked, account can only be unlocked by an administrator".

This is per ACSI 33, the Australian Defense Signals Directorate 'computer security' paper.

It's a stupidity because "userids" in this place are in the form of five letters/numbers.

AAAA1 AAAA2 ... AZZZ9

So, how hard is it to write a script that walks through the possible list of USERIDS and tries to access a network resource three times with randomly generated passwords, and lock out every one of the >30,000 accounts in the domain?

Microsoft wisely recommend that the account lockout period be set to 30 minutes or so. Unfortunately, this department insists on following the DSD 'rules' and we're still under the global threat of any random user locking out the entire organisation with a three line Windows Scripting Host hack.

2011-04-07 Reply Admin

PmWiki uses just passwords, with no usernames, by default.

Power Troll · 2011-04-07 Reply Admin

J:
So? Where´s the WTF? Because they´re still using passwords? We enable auto-login as domain admin on every workstation. This way users don´t bother us with any file access requests, software installations or proxy exceptions...

Are you a complete and utter fool? You sound like someone who works at my IT help desk. Here's a hint: user accounts are an issue that is orthogonal to user privileges.

Welcome to the internet. Enjoy your stay.

frits · 2011-04-07 Reply Admin

All this talk of salt and hash is making me hungry.

da Doctah · 2011-04-08 Reply Admin

frits:
All this talk of salt and hash is making me hungry.

Have some spam and cookies and try not to think about it.

2011-04-08 Reply Admin

Power Troll:
J:
So? Where´s the WTF? Because they´re still using passwords? We enable auto-login as domain admin on every workstation. This way users don´t bother us with any file access requests, software installations or proxy exceptions...

Are you a complete and utter fool? You sound like someone who works at my IT help desk. Here's a hint: user accounts are an issue that is orthogonal to user privileges.

Welcome to the internet. Enjoy your stay.

2011-04-08 Reply Admin

nevermindme:
Power Troll:
J:
So? Where´s the WTF? Because they´re still using passwords? We enable auto-login as domain admin on every workstation. This way users don´t bother us with any file access requests, software installations or proxy exceptions...

Are you a complete and utter fool? You sound like someone who works at my IT help desk. Here's a hint: user accounts are an issue that is orthogonal to user privileges.

Welcome to the internet. Enjoy your stay.

With a name like "Power Troll" I'd've thought you'd get it.

2011-04-08 Reply Admin

da Doctah:
frits:
All this talk of salt and hash is making me hungry.

Have some spam and cookies and try not to think about it.

Oh ok, but just a nibble... maybe a byte.

2011-04-08 Reply Admin

Greg:
Not quite. 2 can be separated from you, 3 cannot.

Owww! I've just cut-off my finger while slicing some onions...

Scarlet Manuka · 2011-04-08 Reply Admin

Is there anyone here who didn't work out what was going on when they read this bit?

Your password was not created. Please choose a different password.

Chewbacca · 2011-04-08 Reply Admin

Synchronos:
Abso:
Of course, you'll have to store the password in plain text so you can look up the salt, at which point the salt isn't very useful.

Quite opposite. You just store the salt in plain text, and the hash of password combined with the salt. That way you can always calculate the hash again by combining the stored salt with the password candidate user provided.

Abso:
Or you could try every salt in the system for every login, but that might be just a teensy bit slow.

You know that there are ways to combine two pieces of information together, called "databases", which can map one hash to one salt?

Please be kidding. Please!

What is the point of salting if you provide the salt? If someone steals your database, and wants to rainbow-table it (or whatever) to get into the Real System, then salting prevents that only if the salt is unknown.

That's why I've coded my own (low-security, high crash chance etc, but that doesn't matter) hashing that generates the salt based on some other piece of information. That way, if the database is compromised, but not the sourcecode/application, then you can try and rainbow it until all the passwords are changed anyway (max 60 days).

2011-04-08 Reply Admin

Got to know: were the kittens rather of a furry kind or hairless?

2011-04-08 Reply Admin

The scary thing about this WTF is that I had a customer request this particular login method once with just a password field and no user id field. After picking my jaw up off the floor and telling them that, no the product can't be changed to incorporate this, I was told that this was a request from upper management as some of them found it too complex to remember a username and password and wanted the login process simplified.

2011-04-08 Reply Admin

Sudo:
Here's a terrifying thought - in this scheme, we are all Nagesh. Think about it, and weep.

My name is Nagesh, for we are many.

2011-04-08 Reply Admin

Chewbacca:
What is the point of salting if you provide the salt? If someone steals your database, and wants to rainbow-table it (or whatever) to get into the Real System, then salting prevents that only if the salt is unknown.
That's why I've coded my own (low-security, high crash chance etc, but that doesn't matter) hashing that generates the salt based on some other piece of information. That way, if the database is compromised, but not the sourcecode/application, then you can try and rainbow it until all the passwords are changed anyway (max 60 days).

Erm... generating the salt using anything other than a PRNG doesn't gain you any extra security. Seriously, go and look up what cryptographic salt is, what it protects against and why. While you're at it, look up what rainbow tables and dictionary attacks actually are, as well. Salts make pre-computed rainbow tables for a given hashing algorithm useless. Dictionary attacks can succeed - by which I mean the type of dictionary attacks which actively iterate through common passwords (hashing them as the application would, or actively attacking the running application), not ones based on pre-computed hashes of common passwords - but are slow and may produce no results if your users have strong passwords.

Even with known salt values, you would have to compute a new rainbow table for each password hash you wish to crack, since each hash incorporates a unique piece of known plaintext (which the application you're attacking will append to the user-supplied plaintext before hashing, so it must be accounted for in all your rainbow table entries).

IOW: random-but-stored salt values work, there's no need to generate them on the fly using an obscure algorithm. However, you can never protect 100% against brute force; the best you can hope for is to make it computationally infeasible.

2011-04-08 Reply Admin

Power Troll:
J:
So? Where´s the WTF? Because they´re still using passwords? We enable auto-login as domain admin on every workstation. This way users don´t bother us with any file access requests, software installations or proxy exceptions...

Are you a complete and utter fool? You sound like someone who works at my IT help desk. Here's a hint: user accounts are an issue that is orthogonal to user privileges.

Welcome to the internet. Enjoy your stay.

Power Troll getting powerfully trolled? No no no, this must be a double bluff.

2011-04-08 Reply Admin

Since the comments seem to be more interested in fingerprint scanners I'll tell you about the building I work in. They recently moved over to fingerprint scanners on all the external doors (they had some budget to burn and felt it made them look more "high tech"). The scanners naturally get covered in (surprise) fingerprints, but the jaw-dropping thing is you don't even need to lift the last fingerprint off to use it. You just need to wrap a bit of cling film (saran wrap) tightly over your thumb and gently roll it over the scanner. Hey presto, the scanner detects the last fingerprint it read and you're in.

I'm pretty sure I saw this technique in a movie and bugger me if it doesn't work some 10 years later on a widely used commercial fingerprint scanner. What's worse, we had the manufactuers in the building after they installed the system to talk about it with everybody. I questioned them on the ability to spoof the last fingerprint, before I even realised that it was so easy, and they said (I shit you not) "that's not something we really know anything about". WTF? You manufacture door locks and you don't know anything about the ways in which people try to subvert them? Ways that are so commonly known you can see them in the movies?

In disgust I refused to be scanned for the system so now I can't get in the building any later than 18:30 when they lock the doors. Fine by me, no more late nights.

2011-04-08 Reply Admin

Jeb:
1. Something you know (PIN, password) 2. Something you have (RSA token, smart card) 3. Something you are (fingerprint, voiceprint, etc.)
To be two-factor, you must use two of those factors (funny, that).

Serious two-factor authentication schemes don't go near biometrics so 3 is off the table in my opinion. A standard two-factor authentication scheme would be:

Something you know (PIN, password)
Something you have (RSA SecureID token - oh shit)

2011-04-08 Reply Admin

Citizen Schol-R-LEA why you are conplaining of bureaucracy? Friend Computer's bureaucracy is perfect.

Chewbacca · 2011-04-08 Reply Admin

mangobrain:
Chewbacca:
What is the point of salting if you provide the salt? If someone steals your database, and wants to rainbow-table it (or whatever) to get into the Real System, then salting prevents that only if the salt is unknown.
That's why I've coded my own (low-security, high crash chance etc, but that doesn't matter) hashing that generates the salt based on some other piece of information. That way, if the database is compromised, but not the sourcecode/application, then you can try and rainbow it until all the passwords are changed anyway (max 60 days).

Erm... generating the salt using anything other than a PRNG doesn't gain you any extra security. Seriously, go and look up what cryptographic salt is, what it protects against and why. While you're at it, look up what rainbow tables and dictionary attacks actually are, as well. Salts make pre-computed rainbow tables for a given hashing algorithm useless. Dictionary attacks can succeed - by which I mean the type of dictionary attacks which actively iterate through common passwords (hashing them as the application would, or actively attacking the running application), not ones based on pre-computed hashes of common passwords - but are slow and may produce no results if your users have strong passwords.

Even with known salt values, you would have to compute a new rainbow table for each password hash you wish to crack, since each hash incorporates a unique piece of known plaintext (which the application you're attacking will append to the user-supplied plaintext before hashing, so it must be accounted for in all your rainbow table entries).

IOW: random-but-stored salt values work, there's no need to generate them on the fly using an obscure algorithm. However, you can never protect 100% against brute force; the best you can hope for is to make it computationally infeasible.

With a derived salt (fast and simple "hashing" such as the number of characters in the username multiplied by the ASCII table ID of the third character) a rainbow table build will go from "Will take years to build" to "Will take longer to build than the sun has fuel for" if you want to get a hold of all the passwords. It is trivial to implement, costs almost nothing performance-wise, and is very transparent for any bugs or issues that might arise. I still hold that it's better than supplying the salt with the hash, as it spends almost no resources at all in making it several orders of magnitude harder to compute a rainbow against. Note that I'm talking about hashing each and every password with a different salt, derived from non-changing user data (birth date, username or whatever).

And yeah, this is a little over the edge of paranoia, as the only viable rainbow table I've ever actually seen is an 8-10 character alphanumeric password table, all against a simple unsalted (of course) MD5 hash. That file was nowhere near complete, and it was well over a gigabyte worth of text.

So yeah, I don't loose sleep over rainbow tables. Still, if I can trivially make it "impossible", I will.

On your point about brute force, of course, all this is irrelevant, and it all comes down to Jimbo in accounting not using "NASCAR" for his password.

2011-04-08 Reply Admin

neminem:
Call it... "Wish-It-Was One-Factor"?

More like 'Three-Letter authentication'.

2011-04-08 Reply Admin

[/quote]How desperate do you have to be to get at someone's vmail to try all those combinations? [/quote]

I am guessing you're not in the U.K.

http://en.wikipedia.org/wiki/List_of_victims_of_the_News_of_the_World_phone_hacking_scandal

Akismet this is not spam.

2011-04-08 Reply Admin

Chewbacca:
With a derived salt (fast and simple "hashing" such as the number of characters in the username multiplied by the ASCII table ID of the third character) a rainbow table build will go from "Will take years to build" to "Will take longer to build than the sun has fuel for" if you want to get a hold of all the passwords.

I fail to see how having such a trivial function for deriving the salt will make generating rainbow tables take any longer than having a stored salt - unless you're relying on people not knowing how you derive the salt. If they know that, they can generate the salt for each user just as quickly as looking it up in the data they stole. With stored salts, I am also talking about having a different salt for each and every password.

This is really nit-picking though, since it sounds like we're largely singing from the same song sheet. :) With either approach you need a different rainbow table for each password because the snippet of known plaintext is different.

2011-04-08 Reply Admin

The problem here is that there is no identifier.

You state you are X (by presenting an identifier - e.g. username).

Your factor(s) of authentication prove that you are who you assert you are.

Merely having a single value that identifies you and proves your identity is having an identified + security through obscurity (i.e. hoping no one can guess or otherwise stumble upon your identifier)

frits · 2011-04-08 Reply Admin

da Doctah:
frits:
All this talk of salt and hash is making me hungry.

Have some spam and cookies and try not to think about it.

That's certainly better than eating my own dogfood.

2011-04-08 Reply Admin

PedanticCurmudgeon:
inb4 "YHBT. YHL. HAND."

If only I had a nickel for every time someone said that... I can't believe that catchphrase has now been around seventeen years. I'M SO OLD!

Nagesh · 2011-04-08 Reply Admin

hoodaticus:
Nagesh:
hoodaticus:
Am I the only one who gets frothing mad that incompetents like this have taken jobs I could have had? Because that knowledge drove me fucking nuts when I was unemployed.

And what was exact cause of unemployment?
I was both a lowly employee and a contractor for the board of directors with fiduciary duties to them. My boss asked me to withhold information from the board, which I could not ethically do. So I quit. That same day.

Best decision I ever made.

You're person with ethics.That's good and bad.

2011-04-08 Reply Admin

You can have a good enough system which only requires you to enter a password and no userID. It only requires that the users themselves can't change their password or suggest passwords. Each user is given a password by the admin, which is created with a random-string-function. The random string is checked against all the other passwords so there will be no collisions. The authentication IS the identification. What could be wrong with this?

2011-04-08 Reply Admin

One of the dumber Anonymous posters:
You can have a good enough system which only requires you to enter a password and no userID. It only requires that the users themselves can't change their password or suggest passwords. Each user is given a password by the admin, which is created with a random-string-function. The random string is checked against all the other passwords so there will be no collisions. The authentication IS the identification. What could be wrong with this?

The obvious problem is that people aren't allowed to choose their own passwords. If you force a random strong password onto people and don't allow them to change it, what are they going to do? Well duh, they're going to write it down, probably on a sticky-note on the underside of their keyboard or worse, the side of their monitor (I've seen both of these before). With no login to verify the password against, it makes it even easier for an attacker to gain access - they don't even need to figure out your username, just bung in the password and they're in.

2011-04-08 Reply Admin

Anonymous:
You can have a good enough system which only requires you to enter a password and no userID. It only requires that the users themselves can't change their password or suggest passwords. Each user is given a password by the admin, which is created with a random-string-function. The random string is checked against all the other passwords so there will be no collisions. The authentication IS the identification. What could be wrong with this?

Sorry, all the PowerTrolls got there before you.

Just in case...

while AccessDenied() set MyLastGuess = MyLastGuess + 1 try SneakIn(convert(ascii,MyLastGuess)) wend

PedanticCurmudgeon · 2011-04-08 Reply Admin

Anonymous:
The obvious problem is that people aren't allowed to choose their own passwords. If you force a random strong password onto people and don't allow them to change it, what are they going to do? Well duh, they're going to write it down, probably on a sticky-note on the underside of their keyboard or worse, the side of their monitor (I've seen both of these before). With no login to verify the password against, it makes it even easier for an attacker to gain access - they don't even need to figure out your username, just bung in the password and they're in.

QFT. At one place I used to work, they had a policy of expiring passwords after 30 days. The users implemented their own policy of writing their passwords on the first card in their Rolodexes (translation for the age-impaired: files of contact information cards), and even the sysadmin started using the month and year as her password.

2011-04-08 Reply Admin

PedanticCurmudgeon:
Anonymous:
The obvious problem is that people aren't allowed to choose their own passwords. If you force a random strong password onto people and don't allow them to change it, what are they going to do? Well duh, they're going to write it down, probably on a sticky-note on the underside of their keyboard or worse, the side of their monitor (I've seen both of these before). With no login to verify the password against, it makes it even easier for an attacker to gain access - they don't even need to figure out your username, just bung in the password and they're in.
QFT. At one place I used to work, they had a policy of expiring passwords after 30 days. The users implemented their own policy of writing their passwords on the first card in their Rolodexes (translation for the age-impaired: files of contact information cards), and even the sysadmin started using the month and year as her password.

We tried to implement a system of personal usernames and passwords for our internal developers to log into our flagship product, rather than everyone using the default system / "idiot password" technique. Howls of protest from all those who refused to learn another username and password combination. So it never happened.

2011-04-08 Reply Admin

Anonymous:
...snip... you don't even need to lift the last fingerprint off to use it. You just need to wrap a bit of cling film (saran wrap) tightly over your thumb and gently roll it over the scanner. Hey presto, the scanner detects the last fingerprint it read and you're in.
...snip...

In disgust I refused to be scanned for the system so now I can't get in the building any later than 18:30 when they lock the doors. Fine by me, no more late nights.

If your claim about the fingerprint scanners were correct, not being scanned wouldn't stop you getting into the building...

captcha: genitus. If your claim is correct, you could probably also run that over the scanner...

2011-04-08 Reply Admin

anon:
Steve H.:
Actually the last one can be bypassed through either a picture of the eye (or face if it's facial recognition), or simply taking a fingerprint sample off anything you've recently touched.
Even worse is that once it's compromised, it's a bitch to change.

Facial recognition can often be bypassed with a photograph, retinal scanner cannot. Any retinal scanner that can be fooled by a photograph is not actually a retinal scanner, just facial recognition that only uses a very small portion of your face. And changing your fingerprint after a security compromise is easy the first 9 times, after that it gets a bit difficult.

Does it have to be a fingerprint? Or could you (in theory, anyway), use a toeprint, or scan some other body part to get uniqueness?

Or maybe not even use body parts, but then you're probably getting into a realm where it's more easily reproducible by the bad guys.

2011-04-08 Reply Admin

Nagesh:
Sudo:
Here's a terrifying thought - in this scheme, we are all Nagesh. Think about it, and weep.

My name is Nagesh, for we are many.

Yes, unfortunately, we know this...

2011-04-08 Reply Admin

foo:
Anonymous:
...snip... you don't even need to lift the last fingerprint off to use it. You just need to wrap a bit of cling film (saran wrap) tightly over your thumb and gently roll it over the scanner. Hey presto, the scanner detects the last fingerprint it read and you're in.
...snip...

In disgust I refused to be scanned for the system so now I can't get in the building any later than 18:30 when they lock the doors. Fine by me, no more late nights.

If your claim about the fingerprint scanners were correct, not being scanned wouldn't stop you getting into the building...

I guess, but I don't make it a habit of standing outside the front door, in full view of at least 3 security cameras, trying to crack the lock with cling film. I tried it once to satisfy my curiosity and a second time to demonstrate the problem to the facilities manager (he didn't really care and nothing was done about it). It's a shared facility so my boss has no idea, the door locks are not under his remit and I'm not about to tell him I felt the need to crack the security.

2011-04-08 Reply Admin

There's also the "4th" factor:

Someone who knows you.

This is used by the clandestine service for agents returning from the field. Someone from your area has to identify you before you can get your badge back. (A generic government badge that has no information about who you work for.) Arguably, factor 4 is a constellation of information that could include all parts 1-3, but still, it can't be automated. (yet)

2011-04-08 Reply Admin

JohnArlen:
1, 2, and 3 are distinctly different burdens for someone to bypass.
By using all 3, someone would need to: *) Guess/Extract your password *) Steal/Acquire your device *) Dismember your finger/eye

So, what you're trying to say is that the solution is a scalpel; "extract" the password using the 1000 cuts method (maybe a bit of salt or lemon juice will help here. Is this the salt everyone is going on about?), take the device from their coat pocket, then proceed with dismemberment (perhaps you coudl do this concurrent with the first step). To be safe, best to take all possible biometrics, and record the screams on a digital recorder, for voice print analysis.

2011-04-08 Reply Admin

Greg:
Not quite. 2 can be separated from you, 3 cannot.

Welllllll.....it depends on how determined the thief is. If you consider a fingerprint as something that cannot be separated from you, consider these two things:

On Mythbusters, Adam Savage was able to defeat a fingerprint lock with a photocopy of Grant's fingerprint. While Grant's finger remained securely on his hand, the information (the print) did not.
You can actually physically separate a person from their fingerprint, though at this point you'll be looking at greatly increased criminal charges if you're caught. (And yes, it has been done. In countries where carjacking victims are commonly shot, there's little additional risk in removing their hands.)

#2 is actually why I'm not keen on fingerprint locks. I don't want to make my fingers valuable to criminals.

The Phantom Password

Leave a comment on “The Phantom Password”