Page 1 of 2

challenge response authentication question

Posted: Tue Aug 10, 2010 3:46 pm
by shawngoldw
I understand the challenge response process and hashing but how can you make a challenge response system without storing the user's password in the database?

If the user is going to hash their password with a random string, you need to have their password in the database to hash it yourself.
Or you can store a hash of their password with their email, but you're password stored in the database is a very simple hash indeed.
You can also salt their password to store it in the database, but then you need to get the salt out to the user before they hash with the challenge. but if you want a unique salt for each user, you can't really do this.

Thanks,
Shawn

Re: challenge response authentication question

Posted: Wed Aug 11, 2010 1:29 am
by Mordred
It seems like your question is about the registration of new accounts rather than authenticating existing ones.
You can use a javascript crypto library to do the initial hashing on the client side, which may or may not work depending on the exact authentication scheme you are using.
A strong challenge-response authentication scheme is described at http://srp.stanford.edu/.

You'll need to tell us more about your situation in order to get a more meaningful answer :)

Re: challenge response authentication question

Posted: Wed Aug 11, 2010 3:04 pm
by shawngoldw
Haha, I thought and hoped you would be the one to reply to this. I've read your challenge response thread on these forums, it was very good.

I am not talking about registration of new accounts, I am talking about the authentication process, although I guess what I am asking has a bit to do with both. I don't have a particular situation that I am asking for help with, it is a general question about the system/process.


Anyways, i'll try to make myself more clear, this is for the authentication process

1. Server generates a random string
2. Server sends the string in a hidden form element or cookie
3. User enters their username and password
4. Javascript hashes the password with the random string
5. Browser sends the hash to the server.

Now the server has to recreate this hash. In order to do so the server must know all the data which went into the hash; the password and the random string. To me this means that the server must have the user's password stored in plain text, I do not like this. My question is how do you avoid this? And I guess that you are right, a big part of this answer would be in the registration process.

Thanks,
Shawn

Re: challenge response authentication question

Posted: Thu Aug 12, 2010 4:58 am
by Mordred
shawngoldw wrote:Haha, I thought and hoped you would be the one to reply to this. I've read your challenge response thread on these forums, it was very good.
I think you're mistaking me for Maugrim, who wrote one such tutorial IIRC.

If I remember correctly, he still handled the registration procedure with a clear text password, but I'm not 100% sure.
shawngoldw wrote: Now the server has to recreate this hash. In order to do so the server must know all the data which went into the hash; the password and the random string. To me this means that the server must have the user's password stored in plain text, I do not like this. My question is how do you avoid this? And I guess that you are right, a big part of this answer would be in the registration process.
I cannot think of a simple solution without using asymetric cryptography that would work (and even if I could, I wouldn't trust it, he). I suggest you use TLS (https) if you want a secure communication channel.

Re: challenge response authentication question

Posted: Thu Aug 12, 2010 11:01 am
by shawngoldw
Mordred wrote: I think you're mistaking me for Maugrim, who wrote one such tutorial IIRC.
Ya you're right my bad, I still do like to hear what you have to say in the security realm.

But if you're going to use https for registration and store the plain text password, I would prefer to use https on all logins while having the passwords stored in the databaes as salt and pepper hashes.

Challenge - Response is a way to avoid sending passwords in plain text on authentication, I just don't see the advantage over SSL

Re: challenge response authentication question

Posted: Thu Aug 12, 2010 11:52 am
by Mordred
But if you're going to use https for registration and store the plain text password, I would prefer to use https on all logins while having the passwords stored in the databaes as salt and pepper hashes.
Challenge - Response is a way to avoid sending passwords in plain text on authentication, I just don't see the advantage over SSL.
My santiments exactly :)

Challenge-response can be viewed as a "poor man's SSL", it reduces the attack surface as the password never travels in plain text while authenticating. The password (or an attacker-usable derivative of it) does travel in plain during registration though, hence it's a "poor man's". It's still much better than nothing, mind you. A salt-and-pepper hashing scheme still transports the password in the clear BOTH when registering and authenticating, so you need to weigh that against the risk of keeping cleartext passwords in the database.

But in the end, as I see it, either your site/application is not very sensitive, in which case it's okay to let the users take the risk of having their passwords sniffed, or it is very sensitive, in which case nothing less than TLS is suitable. There might be some middle ground between the two, plus there is the argument that users are dumb and reuse their passwords, yadda yadda, but in general it's only these two options.

(*) There might be a way to do the registration with some kind of password verifier that is not the cleartext password, but the argument still stands.
----------

P.S.
Hmm, I think there is a way to avoid keeping the password in the clear:

On registration:
The server generates a random salt and sends it to the browser.
The browser takes the password, hashes it with the salt and sends it to the server. The hash and the salt go to the database

On login:
The server sends the challenge nonce plus the salt
The client hashes the password with the salt (should be the same as what's in the database), then hashes the result with the nonce
The server reads the password hash, hashes it with the nonce and compares the final hash with what the client submitted

In that way the server keeps the passwords salted, but there is still not 100% security against sniffing:

If the attacker sniffs the *registration*, he will not have the cleartext password, but will have the *salted* hash. He can use the salted hash in the challenge-response to impersonate the user.

So it's a reduction of the attack surface, but still not complete security.

With that scheme, the challenge-response becomes equivalent (in what's in the database) to a salted password scheme, with a somewhat better security in the transport part.
There doesn't seem to be an easy way to include a site-specific peppper though, so if that's important to you, you must weigh the options.

----------
Postscript aside, my argument still stands. For most cases it's two options: either use TLS or transport the password in the clear.

Re: challenge response authentication question

Posted: Thu Aug 12, 2010 12:10 pm
by shawngoldw
Yes this is something I was thinking too but I can't see how you get the salt to the user on login. If each user has a unique salt, you can not include it in the login form because it will be different for each user; you don't know which salt to send out until you know which user is trying to login.

Shawn

Re: challenge response authentication question

Posted: Fri Aug 13, 2010 1:37 am
by Mordred
Make two asynchronous javascript requests to the login server - one to tell the username and receive a salt and a nonce, one to send the hash and receive an authentication token (SID). Be careful to return a salt and nonce even if the user does not exist, otherwise one could enumerate (in)valid usernames in the system.

Again, this is only academic, do not use it on a real production site. Use TLS instead.

Re: challenge response authentication question

Posted: Fri Aug 13, 2010 7:46 am
by shawngoldw
Yup, that would work, TLS it it though. I really enjoyed this conversation :D

Shawn

Re: challenge response authentication question

Posted: Fri Aug 20, 2010 5:37 am
by timWebUK
Just referring back to a post I made a while ago, this topic reminded me. I asked a similar question a while ago regarding Challenge-Response. kaisellgren was under the belief that it is nowhere near an alternative SSL and should not be used for the purpose of replacing SSL. I guess you may say it is better than nothing, but in security you can't really get away with settling for second best.

Here is the article (not completely on topic), but food for thought.

viewtopic.php?f=34&t=110430&p=593305

Re: challenge response authentication question

Posted: Fri Aug 20, 2010 6:58 am
by Mordred
Dude, no offense, but do you only read the bold text? 'Cause I said a lot more things than that. Let me quote my main thesis again:
Mordred wrote:But in the end, as I see it, either your site/application is not very sensitive, in which case it's okay to let the users take the risk of having their passwords sniffed, or it is very sensitive, in which case nothing less than TLS is suitable. There might be some middle ground between the two, plus there is the argument that users are dumb and reuse their passwords, yadda yadda, but in general it's only these two options.
Now that I read the thread you posted, kai and me say practically the same thing (which is to be expected, 'cause we're both right :) )

Re: challenge response authentication question

Posted: Mon Aug 23, 2010 3:26 am
by timWebUK
Mordred wrote:Dude, no offense, but do you only read the bold text? 'Cause I said a lot more things than that. Let me quote my main thesis again:
Mordred wrote:But in the end, as I see it, either your site/application is not very sensitive, in which case it's okay to let the users take the risk of having their passwords sniffed, or it is very sensitive, in which case nothing less than TLS is suitable. There might be some middle ground between the two, plus there is the argument that users are dumb and reuse their passwords, yadda yadda, but in general it's only these two options.
Now that I read the thread you posted, kai and me say practically the same thing (which is to be expected, 'cause we're both right :) )
I was agreeing with you!!

Re: challenge response authentication question

Posted: Wed Aug 25, 2010 7:04 am
by Mordred
Sorry then, I have misinterpreted what you mean by the phrase "but in security you can't really get away with settling for second best."

Re: challenge response authentication question

Posted: Wed Aug 25, 2010 9:33 am
by timWebUK
I was just addressing everyone as a whole... that's the problem with forums - can't always get a grasp on what someone means!

I would never disagree with your expertise :wink:

Re: challenge response authentication question

Posted: Wed Aug 25, 2010 10:00 am
by Mordred
timWebUK wrote:I would never disagree with your expertise :wink:
No, you should, if I'm wrong :) "Expertise" means nothing more than an evaluation of whether one is right more often than other people. That doesn't mean that the "expert" can't be wrong!

(Of course I'm only human and would not like being proved wrong, but I'm also a scientist, which means I try to override my ego and accept the truth. The best thing about "hard" science (such as security) is that one can be objectively proved wrong, there's little room for 'let's agree to disagree', etc ;) )