The Daily WTF: Curious Perversions in Information Technology

2011-04-07 Reply Admin

Mixing user identification and authentication is perfectly permissible in certain cases.

If you log in with a CAC, it has your identity stored in the certificates it carries, which are then used to authenticate you. (Those are generally further secured through a PIN.)

Other PKI techniques do the same. The ssh utility, for instance, can use PKI to both identify and authenticate the user. SSL certificates do the same.

Biometrics, like thumbprint scanners, don't need you to enter a userid since they're not storing the physical thing directly. Instead, they look up and confirm your identity based on matching various measurements. In both of these examples, the same factor does identifying and authenticating.

This problem is specific to passwords for a few reasons. They're trivially reproducible, so we hash them to avoid storing the original at all. Since people don't care as much as we want and since brains aren't very good at storing randomness, they tend to be fairly trivial. So to prevent dictionary attacks (especially rainbow tables) we add salt that's different for each password before we hash them. Once you've done that, you have to look up the salt to authenticate, so you can't mix user ids and passwords.

Ergo, TRWTF is that these idiots were probably storing passwords in plaintext, or just hashed without salting them.

2011-04-07 Reply Admin

Schol-R-LEA:
Interestingly enough, Bob Raskin at one point seriously suggested eliminating usernames and having users identified by means of their password alone, which would be required to consist of at least two words and a number. He made the point that the username adds little if anything to the security, while adding one more thing to what the legitimate user needs to remember. I don't think he had quite this sort of bureaucratic silliness in mind, however.

Hmm, not sure I agree with him regardless. In many modern scenarios username does add something... it allows the login mechanism to use a salt value on the password. The salt can then be looked up based on the username when authenticating the password... this means that if ever the hashed passwords were somehow stolen, no one with a simple rainbow table could reverse that hash into the actual password.

Maybe useless from an individual user authentication standpoint, but quite useful from a system security standpoint.

2011-04-07 Reply Admin

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.

You'd be surprised at what works. I once used a photocopied-then-faxed copy of my boss' when I needed to get into the secure audit rooms. Funny thing is, the room reader worked with this low-tech workaround but my el-cheapo usb based fingerprint reader wouldn't..

2011-04-07 Reply Admin

hikari:
Something I Am (username) Something I Know (password) Something I Have (RSA Key or similar)

Username is something you know, not are. I can't become you by watching over your shoulder but I can learn your username.

Technically they all currently map down to something you know. If you know both the algorithm and key for an RSA key then you can duplicate it. Same with all biometrics. They can be duplicated if you can intercept the information.

2011-04-07 Reply Admin

[quote user="the guy behind you"][quote user="Jack"]Did you try hunter2?[/quote]

Oh bash.org....how I miss you

2011-04-07 Reply Admin

Thanks.

I needed a good laugh today. The part where you had to submit a form for a password change was mildly funny. But the part where they both rejected your password change request and changed your password to something else without even consulting you--that's the but that made me lol.

Yeah, this article needs to go in the Best Of archive if isn't there already. When people ask, "just what is a technology wtf?" I can point to this article. Priceless.

(P.S. Yes, of course I get that it was also a brain damaged-ly stupid and insecure system. That also was worth a smile, but it was the aforementioned goofy behavior that was unexpected and therefore funny.)

-- Furry cows moo and decompress.

2011-04-07 Reply Admin

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.

2011-04-07 Reply Admin

Toc the elder:
In many modern scenarios username does add something... it allows the login mechanism to use a salt value on the password.

You don't need a user ID for that. Any random number stored with the password will suffice.

Anyway, I can't grasp the idea here to consider user ID in any way a security measure. It is something you propose to be, not any proof of it. It is to have a distinct symbol for the identity, to point to it, to name it. If the security measures for proving that identity are good enough, user IDs can be made public (at least for security's sake, perhaps not because of privacy issues). Of course the first step in security is to know a valid user ID, which proves some knowledge. But that is something that could be done with a password strong enough, anyway.

2011-04-07 Reply Admin

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.

2011-04-07 Reply Admin

A company I know of still uses something like this for their voicemail system... The access code is a 5-digit number, and you can call the mailbox number from the outside.

Apparently, it's all very safe as you just have a 1% chance of hitting an existing code, and only bad, bad people try something else than their own code...

hoodaticus · 2011-04-07 Reply Admin

12345:
A company I know of still uses something like this for their voicemail system... The access code is a 5-digit number, and you can call the mailbox number from the outside.
Apparently, it's all very safe as you just have a 1% chance of hitting an existing code, and only bad, bad people try something else than their own code...

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

Sequential numeric vmail passwords are very common btw. So much so, that IP Office gives what looks just like a Visual Studio compiler warning about each mailbox with a sequential password.

Our solution? Change them from 12345 to 13579.

2011-04-07 Reply Admin

hikari:
somedude:
Common misconception about 'factors' in multi factor authentication. Using only one field instead of 2, or 6 like B of A, constitutes 1 factor authentication. Using a zillion fields would still be 1 factor authentication.
Someone explained it well on the web, I don't remember who or where.

Single factor authentication usually comes down to "I know something", like a user name and password. To make it 2 factor, you add another factor such as "I have something", perhaps an RSA token or a USB fob or a fingerprint.

Something I Am (username) Something I Know (password) Something I Have (RSA Key or similar)

Fuck off dummy, stop spreading misinformation...

As pointed out by someone earlier, it's tards such as yourself that give inspiration to other tards to implement security schemes like this story...

2011-04-07 Reply Admin

Synchronos:
Toc the elder:
In many modern scenarios username does add something... it allows the login mechanism to use a salt value on the password.
You don't need a user ID for that. Any random number stored with the password will suffice.

Sure, that works.

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.

2011-04-07 Reply Admin

Actually, being actively involved in the development of fingerprint sensors, I can say that only old or really crappy fingerprint sensors are easily spoofed, especially with a lifted print. We are familiar with all the published methods of spoofing fingerprints, as well as those espoused by such sophisticated crackers as the Mythbusters, and can make a pretty good case that you'll grow old and die before you can make those methods successful against modern sensors. We haven't been willing to test the "chop off a finger and use it to bypass security" theory yet, but we're looking for volunteers to help us out.

2011-04-07 Reply Admin

KilroySmith:
Actually, being actively involved in the development of fingerprint sensors, I can say that only old or really crappy fingerprint sensors are easily spoofed, especially with a lifted print. We are familiar with all the published methods of spoofing fingerprints, as well as those espoused by such sophisticated crackers as the Mythbusters, and can make a pretty good case that you'll grow old and die before you can make those methods successful against modern sensors. We haven't been willing to test the "chop off a finger and use it to bypass security" theory yet, but we're looking for volunteers to help us out.

I volunteer Nagesh!

2011-04-07 Reply Admin

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?

2011-04-07 Reply Admin

KilroySmith:
Actually, being actively involved in the development of fingerprint sensors, I can say that only old or really crappy fingerprint sensors are easily spoofed, especially with a lifted print. We are familiar with all the published methods of spoofing fingerprints, as well as those espoused by such sophisticated crackers as the Mythbusters, and can make a pretty good case that you'll grow old and die before you can make those methods successful against modern sensors. We haven't been willing to test the "chop off a finger and use it to bypass security" theory yet, but we're looking for volunteers to help us out.

Go to a hospice, ask for volunteers. I'm sure you'd find someone who wouldn't mind letting you use their finger when they're done with it.

2011-04-07 Reply Admin

Doesn't this story already answer this question? This is exactly why we need two fields: the non-secure field (username) has to be unique, and you can inform a user when their desired username is taken without revealing any sensitive information.

Sure, you could smash them together, then you would have to require a password that is x + y characters long, where the first x characters are unique for each user. But good luck explaining that to your average user.

2011-04-07 Reply Admin

somedude:
Meep:
somedude:
Someone explained it well on the web, I don't remember who or where, and I really have no idea what I'm talking about. TRWTF is that reading crap like what I'm posting is probably how the idiot who designed the system in the article learned to do security himself.

FTFY.

Alrighty Captain Random. I'll bite. Enlighten us please, as to where I was in error.

Doesn't this story already answer this question? This is exactly why we need two fields: the non-secure field (username) has to be unique, and you can inform a user when their desired username is taken without revealing any sensitive information.

Sure, you could smash them together, then you would have to require a password that is x + y characters long, where the first x characters are unique for each user. But good luck explaining that to your average user.

2011-04-07 Reply Admin

Toc the elder:
Schol-R-LEA:
Interestingly enough, Bob Raskin at one point seriously suggested eliminating usernames and having users identified by means of their password alone, which would be required to consist of at least two words and a number. He made the point that the username adds little if anything to the security, while adding one more thing to what the legitimate user needs to remember. I don't think he had quite this sort of bureaucratic silliness in mind, however.

Hmm, not sure I agree with him regardless. In many modern scenarios username does add something... it allows the login mechanism to use a salt value on the password. The salt can then be looked up based on the username when authenticating the password... this means that if ever the hashed passwords were somehow stolen, no one with a simple rainbow table could reverse that hash into the actual password.

Maybe useless from an individual user authentication standpoint, but quite useful from a system security standpoint.

This is fair enough, but anyone with sufficient access to steal the hashed passwords would presumably have no barriers to also stealing the salt values. At they would be reduced to using a dictionary attack instead of a rainbow table, but rainbow tables for good hash algorithms aren't exactly trivial to generate to start with.

2011-04-07 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?

Ok. So you just calculate the hash, using the password candidate and the salt (which you haven't looked up yet), then use the hash to look up the salt in the database, so you can calculate the hash. Got it.

I'm leaning towards thinking that you're a troll, but I've been reading the articles here long enough to believe that you might be serious.

2011-04-07 Reply Admin

JamesQMurphy:
Schol-R-LEA:
Interestingly enough, Bob Raskin at one point seriously suggested eliminating usernames and having users identified by means of their password alone, which would be required to consist of at least two words and a number. He made the point that the username adds little if anything to the security, while adding one more thing to what the legitimate user needs to remember. I don't think he had quite this sort of bureaucratic silliness in mind, however.

Good Lord, if that was done, what would be shown in things like audit trails, change logs, etc.

04/06/2011 15:22 Created by kittens2love 04/06/2011 15:24 Modified by password4hacking 04/06/2011 15:25 Modified by ponyPlay4me

Just because the username isn't required to log in doesn't mean there can't be one. Store it with the rest of the account details, and allow people to change it once they've logged in. If there wasn't some public identifier associated with the account, you'd have bigger problems than audit trails: in a messaging system, for example, how do you send anyone a message if nobody has an ID they can publicly reveal?

I'm not sure if I'd be for or against abolishing requiring usernames to log in, I just like pointing out little flaws in logic. ;)

2011-04-07 Reply Admin

the guy behind you:
Jack:
Did you try hunter2?

Why would anyone use ******* as their password?

You idiot, you didn't do that right at all.

2011-04-07 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?

Are you fucking retarded? Ok, the user has only entered one piece of information, their password. Your database does not contain that password, only a salted hash of the password. You need to know which salt was used, so what piece of information do you use to look it up? You stored it using a random number, the user did not enter that random number, so you can't look it up by that. You can link it to the password, but you can't look it up by the password because you need the fucking salt to know what the password is.

2011-04-07 Reply Admin

I think it's more likely he just meant you map the username to the salt. Although seeing as you have to map the username to the hash anyway (in order to know you're checking against the right hash), there's no reason you couldn't have an extra link in the chain if you really want to.

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...

Right... they just bother you for virus removal. :)

On-topic: the person who "designed" the security model for the OP's system is probably a CIO by now.

2011-04-07 Reply Admin

Abso:
Ok. So you just calculate the hash, using the password candidate and the salt (which you haven't looked up yet), then use the hash to look up the salt in the database, so you can calculate the hash.

You had a misunderstanding here. I did not assume that there would be no user ID provided by the user. I just said it is not needed for salting the password, because any randon number will suffice. And is better, because if you salt with the ID, you can always use hash lookup tables salted with "admin" or "root". Random number makes lookup tables completely useless. And randomized user IDs would be quite bad for user experience.

2011-04-07 Reply Admin

anon:
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?

Are you fucking retarded? Ok, the user has only entered one piece of information, their password. Your database does not contain that password, only a salted hash of the password. You need to know which salt was used, so what piece of information do you use to look it up? You stored it using a random number, the user did not enter that random number, so you can't look it up by that. You can link it to the password, but you can't look it up by the password because you need the fucking salt to know what the password is.

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.

somedude · 2011-04-07 Reply Admin

keith:
somedude:
Meep:
somedude:
Someone explained it well on the web, I don't remember who or where, and I really have no idea what I'm talking about. TRWTF is that reading crap like what I'm posting is probably how the idiot who designed the system in the article learned to do security himself.

FTFY.

Alrighty Captain Random. I'll bite. Enlighten us please, as to where I was in error.

Doesn't this story already answer this question? This is exactly why we need two fields: the non-secure field (username) has to be unique, and you can inform a user when their desired username is taken without revealing any sensitive information.

Sure, you could smash them together, then you would have to require a password that is x + y characters long, where the first x characters are unique for each user. But good luck explaining that to your average user.

Hmm, that doesn't really have anything to do with the explanation of single vs multi factor authentication. I simply pointed out that user/pass combo is still single factor, that even 10 fields is still single factor. I have an apple. Man I hate oranges. Thats about as applicable.

2011-04-07 Reply Admin

somedude:
keith:
somedude:
Meep:
somedude:
Someone explained it well on the web, I don't remember who or where, and I really have no idea what I'm talking about. TRWTF is that reading crap like what I'm posting is probably how the idiot who designed the system in the article learned to do security himself.

FTFY.

Alrighty Captain Random. I'll bite. Enlighten us please, as to where I was in error.

Doesn't this story already answer this question? This is exactly why we need two fields: the non-secure field (username) has to be unique, and you can inform a user when their desired username is taken without revealing any sensitive information.

Sure, you could smash them together, then you would have to require a password that is x + y characters long, where the first x characters are unique for each user. But good luck explaining that to your average user.

Hmm, that doesn't really have anything to do with the explanation of single vs multi factor authentication. I simply pointed out that user/pass combo is still single factor, that even 10 fields is still single factor. I have an apple. Man I hate oranges. Thats about as applicable.

You hate oranges too?! I thought I was the only one...

They're sneaky, you know, pretending to be just fruits. I'M ON TO THEIR GAME!

mumbling something inaudible

2011-04-07 Reply Admin

anon:
Are you fucking retarded?

No, and frankly I'm not even attracted to them. Sorry, Bob.

2011-04-07 Reply Admin

mangobrain:
anon:
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?

Are you fucking retarded? Ok, the user has only entered one piece of information, their password. Your database does not contain that password, only a salted hash of the password. You need to know which salt was used, so what piece of information do you use to look it up? You stored it using a random number, the user did not enter that random number, so you can't look it up by that. You can link it to the password, but you can't look it up by the password because you need the fucking salt to know what the password is.

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.

Thanks captain obvious, but in this example there is no username, which is the entire point. Without the user giving you some piece of unique information that is stored in plaintext in the database, you have no point of reference to look up anything with.

2011-04-07 Reply Admin

Synchronos:
Toc the elder:
In many modern scenarios username does add something... it allows the login mechanism to use a salt value on the password.

You don't need a user ID for that. Any random number stored with the password will suffice.

Synchronos:
You had a misunderstanding here. I did not assume that there would be no user ID provided by the user. I just said it is not needed for salting the password, because any randon number will suffice. And is better, because if you salt with the ID, you can always use hash lookup tables salted with "admin" or "root". Random number makes lookup tables completely useless. And randomized user IDs would be quite bad for user experience.

That's exactly what Toc the elder was suggesting. So I guess this was just a failure of reading comprehension.

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."

Nagesh · 2011-04-07 Reply Admin

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?

2011-04-07 Reply Admin

hikari:
somedude:
Common misconception about 'factors' in multi factor authentication. Using only one field instead of 2, or 6 like B of A, constitutes 1 factor authentication. Using a zillion fields would still be 1 factor authentication.
Someone explained it well on the web, I don't remember who or where.

Single factor authentication usually comes down to "I know something", like a user name and password. To make it 2 factor, you add another factor such as "I have something", perhaps an RSA token or a USB fob or a fingerprint.

Something I Am (hacker) Something I Know (your password) Something I Have (RSA Key or similar)

FTFY

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?

Most likely the intercourse he was having with patients in mental hospital.

2011-04-07 Reply Admin

anon:
Thanks captain obvious, but in this example there is no username, which is the entire point. Without the user giving you some piece of unique information that is stored in plaintext in the database, you have no point of reference to look up anything with.

OFFS. Go back and read Toc the Elder's original comment - he was saying how he doesn't agree with Bob Raskin's idea that getting rid of usernames is good. He never said in his proposal that there would be no usernames. Give it up.

2011-04-07 Reply Admin

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...

2011-04-07 Reply Admin

Meep:
So to prevent dictionary attacks (especially rainbow tables) we add salt that's different for each password before we hash them. Once you've done that, you have to look up the salt to authenticate, so you can't mix user ids and passwords.

Careful what you say! Dictionary attack != rainbow table. A rainbow table is a convenient table containing one string which hashes to every possible output value of the hash algorithm - so if there is no salt, and you know the hash & algorithm, you can look up a string which produces the given hash and use it as the password. Full rainbow tables for good hashes are therefore incredibly computationally expensive to produce, but incredibly valuable (to crackers) once computed.

Dictionary attacks, on the other hand, take a known username and iterate through common passwords until one works. Because you are supplying the username, the system being attacked will supply the salt for you, so salting is no help against weak (i.e. dictionary word) passwords.

2011-04-07 Reply Admin

Abso:
That's exactly what Toc the elder was suggesting. So I guess this was just a failure of reading comprehension.

OK, you are right. He did really mean using ID to map the salt to the password, which I hastily read "using the ID as the salt to hash the password".

2011-04-07 Reply Admin

Synchronos:
anon:
Are you fucking retarded?
No, and frankly I'm not even attracted to them. Sorry, Bob.

And perhaps I should register my nick, too.

2011-04-07 Reply Admin

mangobrain:
anon:
Thanks captain obvious, but in this example there is no username, which is the entire point. Without the user giving you some piece of unique information that is stored in plaintext in the database, you have no point of reference to look up anything with.

OFFS. Go back and read Toc the Elder's original comment - he was saying how he doesn't agree with Bob Raskin's idea that getting rid of usernames is good. He never said in his proposal that there would be no usernames. Give it up.

And at no point was I arguing with Toc the Elder, in fact I was agreeing with Toc the Elder. I was arguing with Synchronos who claimed that Toc the Elder was wrong and a username was not needed to look up the salt and instead you could just use a random number and store that with the password, but failed to explain how you would look up the random number.

2011-04-07 Reply Admin

anon:
And at no point was I arguing with Toc the Elder, in fact I was agreeing with Toc the Elder. I was arguing with Synchronos who claimed that Toc the Elder was wrong and a username was not needed to look up the salt and instead you could just use a random number and store that with the password, but failed to explain how you would look up the random number.

Geez... I didn't notice anyone suggesting that the salting could be done without usernames, I just saw people arguing with the original proposal on the basis that you couldn't look up the salts, when it's plainly obvious that you can (if there are usernames). Too much text, too many usernames, not enough visual info in each post to quickly scan & tell who's who == me skipping a vital piece of the conversation. Plus the fact I'm part-way through an ale probably doesn't help. ;)

My bad - could have been worse though, I could have called you a fucking retard in the process!

Matt Westwood · 2011-04-07 Reply Admin

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.

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?

Beating up nosey jackwagons.

2011-04-07 Reply Admin

Jack:
Did you try hunter2?

WIN

2011-04-07 Reply Admin

Toc the elder:
Schol-R-LEA:
Interestingly enough, Bob Raskin at one point seriously suggested eliminating usernames and having users identified by means of their password alone, which would be required to consist of at least two words and a number. He made the point that the username adds little if anything to the security, while adding one more thing to what the legitimate user needs to remember. I don't think he had quite this sort of bureaucratic silliness in mind, however.

Hmm, not sure I agree with him regardless. In many modern scenarios username does add something... it allows the login mechanism to use a salt value on the password. The salt can then be looked up based on the username when authenticating the password... this means that if ever the hashed passwords were somehow stolen, no one with a simple rainbow table could reverse that hash into the actual password.

Maybe useless from an individual user authentication standpoint, but quite useful from a system security standpoint.

You know, I think your right!!

2011-04-07 Reply Admin

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.

2011-04-07 Reply Admin

Only Nagesh could create a giant turd sandwich like this.

2011-04-07 Reply Admin

hikari:
somedude:
Common misconception about 'factors' in multi factor authentication. Using only one field instead of 2, or 6 like B of A, constitutes 1 factor authentication. Using a zillion fields would still be 1 factor authentication.
Someone explained it well on the web, I don't remember who or where.

Single factor authentication usually comes down to "I know something", like a user name and password. To make it 2 factor, you add another factor such as "I have something", perhaps an RSA token or a USB fob or a fingerprint.

Something I Am (username) Something I Know (password) Something I Have (RSA Key or similar)

I know all of my colleague's usernames, thanks to a standardised naming scheme (if I know their name, then I know their username). I also know the email addresses of all my friends. Presumably I am all these people?.

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

The Phantom Password

Leave a comment on “The Phantom Password”