Passwords and authentication

[VernonDozier]

>> their database already have your account user name and password

They had better NOT have your password in their database. If they do then they're completely incompetent and you need to run like the plague. No database should ever store a user's password. Instead it should store a one-way HASH of the password. If you ever forget your password and click the "Forgot Password" and get an e-mail with your password, you know they're violating good security procedures. Instead you should be given a temporary NEW password and told to reset it. Passwords need not be stored to be authenticatable and hence should not be. And the key word in "one-way hash" is "one-way". Or is that two words?

[nezachem]

Can you outline an authentication protocol based on one-way hashes?

[VernonDozier]

>> Can you outline an authentication protocol based on one-way hashes?

Sure. Dani hires Alice to take over all webmaster, database, and super-moderator duties. Bob, a powerful jailed Nigerian official who recently won the lottery, needs to write a C++ program that calculates the sales tax on Aluminum Tubes sales. Mohammed, an Iraqi student studying in Prague, finds the missing semicolon and tells Bob where he went wrong. Bob thanks Mohammed and tries to delete the account since he doesn't want his professor at Lagos University thinking he cheated, but is told by Happy Geek that he cannot. Alice takes a break at Starbuck's, buys a coffee, accidentally leaving her laptop at the table, whereupon Eve the eavesdropping neocon, promptly steals the computer and sees the entire Daniweb database and thinks it might be a good thing to maybe make Bob come from Niger instead of Nigeria, add a last name to Mohammed's profile, change his profile from "student" to "Iraqi Intelligence Officer", and then log in as both Bob and Mohammed and send a few PM's between them planning monthly meetings in Baghdad, then cc'ing some Germans in the hope that they'll tell the Americans, but never let the Americans actually see the PMs. But to do this, Eve needs Bob's and Mohammed's passwords. Unfortunately for Eve, Alice was stupid enough to leave her laptop unguarded, but not dumb enough to leave her data unguarded. Hence Eve never finds out that Bob's password was "bob" since "bob" hashed out to some ridiculously long string of seemingly random characters and Eve can't hash it the OTHER way back to "bob" and complete her dastardly deed.

[nezachem]

A nice way to not answer the question. So, how does Bob log in?

[VernonDozier]

He logs in via a web page, types his password "bob" on HIS computer, which gets encrypted on his computer, gets posted over the wire encrypted, then is decrypted and hashed by whatever hash function Alice is using on the server side, the result of which is stored in the database. Alice's script checks whether what Bob typed in hashes to what's in her database, and if it is, the gate is opened. A more elaborate version is that it gets hashed AND encrypted on Bob's side, then unencrypted on Alice's side so Alice's side never ever sees "bob", so Eve can't really do much even if she works for Alice. At best Eve might be able to intercept that hashed value, which is pretty much useless to her since she can't use it to log in and she can't go backwards back to "bob". If Eve can hack into the computer running the script, she might be in business, but then again if she can do that she can probably bypass password authentification anyway. The point is that if somebody loses their laptop, 100,000 passwords aren't lost.

[nezachem]

Not so fast.

> which gets encrypted on his computer
with what key?
> then is decrypted
with what key?

> A more elaborate version is that it gets hashed AND encrypted on Bob's side, then unencrypted on Alice's side so Alice's side never ever sees "bob"

For me it means that the hash is a password; the fact that it hashes "bob" is irrelevant. Eve doesn't need to know "bob": she only needs to know what is sent over the wire.

[VernonDozier]

>> with what key?

Encrypted via the https method. I'm not very familiar with that protocol, but the keys use to encrypt and decrypt will have no relation to "bob" or its hash.

>> Eve doesn't need to know "bob": she only needs to know what is sent over the wire.

If Eve can decrypt what's going over the wire, then she wins, particularly if "bob" is sent rather than the hash of "bob". I have no idea how hard that is, but I assume it's really hard or we wouldn't still be using https. If she intercepts the hash instead of the password, she's still OK since that must mean that everything's hashed on Bob's end and if there's nothing more sophisticated, she can log in with the hash. But it'll usually be something more sophisticated than simply sending the hash by itself for just that reason. The server side is going to be doing something mathematically in additional. I'm not real clear on how that all works. But the stuff over the wire is encrypted by a non-hashing method, so if Eve is sniffing, all she gets is gobbledy-gook.

[Narue]

Thread split from here.

[nezachem]

>> with what key?
Encrypted via the https method. I'm not very familiar with that protocol, but the keys use to encrypt and decrypt will have no relation to "bob" or its hash.

Cool. That is, these keys have no relation to Bob's identity, right?

>> Eve doesn't need to know "bob": she only needs to know what is sent over the wire.

If Eve can decrypt what's going over the wire, then she wins, particularly if "bob" is sent rather than the hash of "bob". I have no idea how hard that is, but I assume it's really hard or we wouldn't still be using https. If she intercepts the hash instead of the password, she's still OK since that must mean that everything's hashed on Bob's end and if there's nothing more sophisticated, she can log in with the hash.

You must realize that in this scheme Eve doesn't need to decrypt anything. She doesn't need to know "bob". Hear goal is not to recover Bob's password. Her goal is to impersonate Bob.

But it'll usually be something more sophisticated than simply sending the hash by itself for just that reason. The server side is going to be doing something mathematically in additional. I'm not real clear on how that all works. But the stuff over the wire is encrypted by a non-hashing method, so if Eve is sniffing, all she gets is gobbledy-gook.

Yes. The stuff which goes over the wire is encrypted with a secret shared by both parties, commonly known as password. Initially you claimed that one party may get away knowing only a one-way derivative of that secret. I was wondering how do you envision it.

[VernonDozier]

>> Cool. That is, these keys have no relation to Bob's identity, right?

Correct. They are passwords by however the passwords are created, but specifically NOT created by Bob or Alice. They are created on Bob's computer and Alice's computer and "exchanged". Alice would have a public key and an SSL certificate somewhere. One thing for sure, the password would not be "bob", which is the password that Bob typed in when registering with Daniweb/Alice.

>> Her goal is to impersonate Bob.

Correct.

>> You must realize that in this scheme Eve doesn't need to decrypt anything.

Yes, she does. What's sent over the wire is "afsdhjasd;jkflhsdajklr" or some junk like that. If Eve doesn't decrypt that she's out of luck. If SHE tries to send that, it won't work because "afsdhjasd;jkflhsdajklr" works once and only once.

>> The stuff which goes over the wire is encrypted with a secret shared by both parties

Yes.

>> commonly known as password.

No. It's much more elaborate than that. There are "keys", not passwords, and it's some sort of Diffie-Hellman type protocol. It's one of things with secret keys and shared keys and they're multiplied together, yadda yadda. It's completely different from a log-in password like "bob". It's a behind the scenes shared https password created on-the-fly. It works ONCE and once only. To the extent that a "key" and a password are the same thing, it's a password. But since passwords are generally re-used, it's nothing like a password. In particular, it will never be saved on either end. It's used once, then thrown away.

>> Initially you claimed that one party may get away knowing only a one-way derivative of that secret.

Still do. If it was two-way, the whole point would be moot.

>> I was wondering how do you envision it.

Both sides know the hashed password. Well, Bob may or may not know it. Alice doesn't need to know "bob", so she doesn't. If she ever gets ahold of "bob", it's only when Bob supplies it. She then does her hash and and immediately throws "bob" away. She doesn't need to store "bob", so therefore she has no business storing it and responsible website owners don't.

[VernonDozier]

>> The stuff which goes over the wire is encrypted with a secret shared by both parties, commonly known as password. Initially you claimed that one party may get away knowing only a one-way derivative of that secret.

To clarify, "the stuff which goes over the wire" is encrypted and decrypted, not hashed. The fact that it's decrypted means it's two-way, not one-way. That's an encryption/decryption algorithm, not a one-way hash. The one-way hash part is the password authentification part and that DOES NOT go over the wire. It's run on Alice's server, then checked against a database entry. There's often even a "trusted third party" so Alice is never even involved.

[nezachem]

>> Cool. That is, these keys have no relation to Bob's identity, right?

Correct. They are passwords by however the passwords are created, but specifically NOT created by Bob or Alice. They are created on Bob's computer and Alice's computer and "exchanged". Alice would have a public key and an SSL certificate somewhere. One thing for sure, the password would not be "bob", which is the password that Bob typed in when registering with Daniweb/Alice.

I am afraid that you are missing an important point. It does not matter if Bob played an active role in a password creation. What matters is that Alice must map Bob's something to Bob's personality.

>> You must realize that in this scheme Eve doesn't need to decrypt anything.

Yes, she does. What's sent over the wire is "afsdhjasd;jkflhsdajklr" or some junk like that. If Eve doesn't decrypt that she's out of luck. If SHE tries to send that, it won't work because "afsdhjasd;jkflhsdajklr" works once and only once.

Now I am missing something. How does Alice derive Bob's identity from "afsdhjasd;jkflhsdajklr"?

In particular,
- how this string was created at the Bob's side
- what Alice is going to do with it

It's much more elaborate than that. There are "keys", not passwords, and it's some sort of Diffie-Hellman type protocol. It's one of things with secret keys and shared keys and they're multiplied together, yadda yadda. It's completely different from a log-in password like "bob". It's a behind the scenes shared https password created on-the-fly. It works ONCE and once only. To the extent that a "key" and a password are the same thing, it's a password. But since passwords are generally re-used, it's nothing like a password. In particular, it will never be saved on either end. It's used once, then thrown away.

Well, now there's a behind-the scenes shared secret. If it is also stored as a one-way hash, I'd smell something badly recursive.

Both sides know the hashed password. Well, Bob may or may not know it. Alice doesn't need to know "bob", so she doesn't. If she ever gets ahold of "bob", it's only when Bob supplies it. She then does her hash and and immediately throws "bob" away. She doesn't need to store "bob", so therefore she has no business storing it and responsible website owners don't.

(Patiently) How does Alice gets hold on "bob" when Bob supplies it?

[VernonDozier]

I'm not an expert on the protocols. I'll do the best I can to answer.

First a VERY over-simplified, obviously breakable. Let's suppose that the encryption algorithm is that we add x to each character. We subtract x to decrypt. x will be the "shared key". Again, major disclaimer, this is obviously a stupid, unsophisticated encryption method. We'll make x 1. They've exchanged this key through Diffie-Hellman or whatever. We'll use use letters only. a is 0, z is 25.

dog encrypts to eph
eph decrypts to dog.

Bob Smith has a user-name of "smith" and a password of "bob", so he sends "smithbob", which encrypts to "tnjuicpc". That's what get's sent over the wire. Eve sniffs this, but presumably can't get it back to "smithbob". If she could, she wins.

Alice's computer receives "tnjuicpc" and unlike Eve, can decrypt it to "smithbob". So she has user-name "smith" and password "bob".

Now for the equally dumb hash function. We'll add up all the digits and mod it by 10 to get an integer from 0 to 9.

b 1
o 14
b 1

1 + 14 + 1 = 16
16 % 10 = 6. 6 is the hash. Note that it's impossible to get from 6 back to "bob" because 6 also maps backwards to "cmc" and all sorts of other things. So it's "one way".

Eve has a database with an entry of "smith" and "6". She runs "bob" throught the function and gets 6. Then she queries the database---> "select hashvalue where username='smith'" and gets back 6. She compares 6 and 6 and they match, so use Smith is authenticated and can proceed.

>> Now I am missing something. How does Alice derive Bob's identity from "afsdhjasd;jkflhsdajklr"?

In this example, it would be "tnjuicpc". rather than "afsdhjasd;jkflhsdajklr". Alice knows that the key is 1, so she can decrypt to "smithbob". Eve does not know the key is 1, so she cannot. Let's say that all usernames are 5 characters and all passwords are 3 characters, so Alice can separate "smith" and "bob".

>> What matters is that Alice must map Bob's something to Bob's personality.

Bob's "something" is his username ("smith") and his password("bob"). Bob and Alice's computers created the "1" on their own. Bob also has a something that i his IP address and his unique MAC address, something that would complicate Eve's job if they are used at all as part of the authentification/key creation process.

Bob created the password "bob" when he registered and Alice's script hashed it to 6 and stored 6 in her database. "bob" is not stored anywhere. "smith" is stored in the database, but not "bob".

>> Well, now there's a behind-the scenes shared secret. If it is also stored as a one-way hash, I'd smell something badly recursive.

Two completely different animals. One is https. One is the hash formula. The hash value is 6 and remains 6 always. The 1 is the key from the one-time key exchange and it will be different every time Bob logs in. The 1 and the 6 have nothing to do with each other. If he logs in 5 times, he'll get a different key through https five times.

>> (Patiently) How does Alice gets hold on "bob" when Bob supplies it?

She decrypts "tnjuicpc" with key "1" to get "smithbob", then she isolates "bob". That's assuming the un-elaborate protocol with no "salt" or anything like that, where "bob" is actually sent, albeit encrypted with the key "1". Alice hashes this to "6" and checks the database, as explained above.

In real life it's more complicated. Alice and Bob probably won't share the "1" so they'll have different keys, tehn use their own private key and multiply with other keys and end up with some common number. THAT key is one-way too. You multiply two huge prime numbers easily, but you'll never be able to take the product and figure out what two numbers you multiplied, the basis of public key encryption.

[nezachem]

Do I understand your protocol correctly?

1. Since Alice doesn't have Bob's password, yet she needs it to establish Bob's identity, the password must travel across the wire.
2. This password may not travel in clear. Moreover, the encryption key must be session specific (if it is reused, Eve can simply reuse the encrypted password).
3. Alice and Bob have to exchange session keys before their identities are mutually established.

If so, this is a classical invite to a man-in-the-middle.

[VernonDozier]

>> Do I understand your protocol correctly?

It isn't my protocol. I've just used it. I don't know who thought it up and wouldn't dream of trying to explain the mathematics behind it. No one has broken it yet, not for lack of trying. Websites the world over do it every day. Maybe someone will figure out how to break https someday. MD5 has apparently been "broken" and SHA-1 has been found to be weaker than thought, but then they just keep coming up with better hash functions.

You're far better off trying to plant some malware on either Bob's or Alice's computer rather than trying to do a man-in-the-middle attack on what you sniff going over the wire. You're not going to figure out any sort of shared key by sniffing, not with a few log-ins a day.

>> Alice and Bob have to exchange session keys before their identities are mutually established.

Not a problem at all. Check out the Diffie-Hellman key exchange for how it's done, or at least the basic idea. You're dealing with something like 4 prime numbers, and Bob and Alice each have 3 of them and any eavesdropper will be able get maybe two of them, but that will not be enough. It's sort of like Bob and Alice each have a pair of keys and they each toss one to each other, Eve can catch both, but you need three keys to encrypt and decrypt. It's a pretty cool scheme. Alice and Bob can pass those keys in the clear and Eve isn't helped in the slightest by intercepting them.

So to sum up, two completely separate, though related problems...

1) How do I prevent someone sniffing from getting "bob". Answer --> encryption of "bob" via https.

2) How do I verify "bob" yet still not care if someone gains access to my database of users. Answer --> One way hash of "bob" is stored in the database. You can know the hash function and the hash value, but you'll never be able to get back to "bob". Moreover you can't log in with the hash value, because then THAT will get hashed a second time. It's a tried and tested system and works great.

[nezachem]

>> Not a problem at all. ... Alice and Bob can pass those keys in the clear and Eve isn't helped in the slightest by intercepting them.

A problem right here. Eve doesn't passively listen to the conversation. She actively modifies data, pretending for Alice to be Bob, and for Bob to be Alice (this is an essence of a man-in-the-middle). Since by that time the identities are not established, neither Bob nor Alice may find out what's going on.

So, the identities must be proven in advance.

The augmented schemes rely on an asymmetric techniques, which prove an identity by a public/private key pairs. This is essentially different from the password based authentication.
And we are talking about password-based ones, right?

[VernonDozier]

>> Since by that time the identities are not established, neither Bob nor Alice may find out what's going on.
>> So, the identities must be proven in advance.
>> The augmented schemes rely on an asymmetric techniques, which prove an identity by a public/private key pairs.

The odds of Bob having a publicly registered key are pretty low. Alice, in charge of a large operation like Daniweb, probably has one since she'll be a professional who does this all the time. Bob's just a regular person. I'm not qualified to explain in depth how and why https is safe from the attacks you describe and how/whether identities are authenticated. You'll have to ask an https expert how they manage that key exchange. I'm just assuming it works so when "bob" is passed from Bob to Alice, Eve cannot grab it. If you can find a way to beat https, you'll be a very rich man.

>> This is essentially different from the password based authentication.
And we are talking about password-based ones, right?

The "password" is "bob". That's the one that never changes. That's the one that Alice needs to safely authenticate. That's what Bob types in to log in and that's what Alice decrypts on the otehr side and that's all she cares about. "bob" gets encrypted behind the scenes by the internet protocol however https does it and gets passed just like any other data. Alice's computer decrypts it behind the scenes before it ever gets to her script. She neither knows nor cares at all how https did it. I used to take credit card orders via https, as do people all around the globe. She then hashes "bob" and compares it to what's in her database. If it works...Bob's logged in.

If you want to call the keys or shared secrets https uses "passwords", fine, but to me a password is something a human creates and types in and doesn't change, so by that definition there's only one password in this whole scheme.

Anyway, I'm sure there's a whole bunch of tutorials out there that explain it all much better. My whole point from the beginning was that anyone who stores passwords in their database is violating proper security protocols.

[nezachem]

> You'll have to ask an https expert

I sort of am.

> when "bob" is passed from Bob to Alice, Eve cannot grab it

Surely she can. The trick is not to pass "bob" from Bob to Alice. Ever.

> The "password" is "bob". That's the one that never changes. That's the one that Alice needs to safely authenticate. That's what Bob types in to log in ...

Correct

> ... and that's what Alice decrypts on the otehr side

Incorrect. As I say, "bob" never appears on the wire, neither in plaintext, nor encrypted. An authentication protocol works as follows:
1. Bob sends username
2. Alice generates a random challenge and sends to Bob. Then Alice appends Bob's password to the challenge and calculates a one-way hash of the combined string.
3. Bob receives a challenge, appends his password to it and calculates a one-way hash of the combined string.
4. Bob sends the hash to Alice.
5. Alice compares a hash she calculated to the hash Bob sent.

Eve cannot recover Bob's password, nor she can pretend to be Bob. The only thing she may is to deny service by tampering.

After the parties are authenticated, and only then, they may start key exchange.

> Anyway, I'm sure there's a whole bunch of tutorials out there that explain it all much better.

I am afraid it is you who needs reading.

> My whole point from the beginning was that anyone who stores passwords in their database is violating proper security protocols.

They do not. In fact, they have no other way but keep them. Properly guarded, strongly encrypted, etc, etc.

[VernonDozier]

So the whole frigging time you've been an expert in https, know more about it than I do, and you agreed with my original point that you're not supposed to store the password in the database? You weren't asking questions trying to learn about it, this was all some big test to see if I knew what I was talking about? I haven't touched this stuff in over a year, never claimed to be an expert. Didn't realize you were a professor giving me a pop quiz. Anyway I think I threw in enough disclaimers about oversimplifications, etc. In fact in one of my earlier posts I pointed out that it's safer to have "bob" not go over the wire. I wasn't sure if you understood that there is more than one key involved, etc. Obviously you understand all of it and were just toying with me.

>> I am afraid it is you who needs reading.

I don't have any problem admitting that. I'm not an expert, never pretended to be one, and have only dabbled in it. It's not my job. I knew enough to make sure I didn't allow passwords to pass unencrypted and I knew not to store passwords in my database and I knew a little more, but not much more.

>> Bob receives a challenge, appends his password to it and calculates a one-way hash of the combined string.

I believe I sort of mentioned something similar way back. Not knowing where you were "lost" and whether you understood at all the idea that there are several stages of this whole thing where stuff gets concatenated, etc. So I oversimplified, again not knowing where you were "stuck".

Here's my earlier quote...

A more elaborate version is that it gets hashed AND encrypted on Bob's side, then unencrypted on Alice's side so Alice's side never ever sees "bob"

Anyway, not sure what the point of this whole exercise was. Apparently you've known all about it all along, yet for some reason decided not to mention it, so I've been wasting time explaining stuff (clearly poorly, but I was trying) that didn't need to be explained. I guess I struck you as a braggart who needed to be put in his place. Frankly I don't think see it.

[nezachem]

>> you agreed with my original point that you're not supposed to store the password in the database?

I did???
Sorry if I has been unclear in my last post. I reiterate:
When providers keep passwords in the database, they do not violate the security protocol. In fact, they have no other way but keep them.

>> You weren't asking questions trying to learn about it

I was trying to prove that keeping hashes instead of passwords is inherently flawed. For me, the point of this whole exercise was to make you realize it. Sorry if I sounded offensive or unfriendly.

[VernonDozier]

All right, well then I completely misunderstood your last post and that is indeed news to me. I thought "they do not" meant "they do not store the passwords", and a google search proves I'm not alone in that thought. Definite thanks for pointing that out. I have some reading to do apparently and I'll have to start reading other things than what I've been reading. Everything I read and everything everyone ever told me, including supposed "security professionals", told me the exact opposite.

>> I was trying to prove that keeping hashes instead of passwords is inherently flawed. For me, the point of this whole exercise was to make you realize it. Sorry if I sounded offensive or unfriendly.

OK, thanks for clarifying that and I do appreciate the info.