Challenge Based Login System?

Hi Guys,

I was readining a bit about the specs of GSM-900 security (completely irrelevant, I know, ), and read that to avoid passwords being sent in clear text, they used a challenge based authentication system.

Now, I was wondering, why have I never seen something like this for the web?

I understand that with a challenge based system, you still have problems with MITM attacks, but I haven't yet seen a solution (other than media saturation for assymetric key encryption, whereby the person floods all possible communication channels with their proper public key on the ssumption that it would be overly difficult to subvert all means of sending a key) to the problem for any protocol, so I'm willing to let that sit, and anyway; it raises the bar for attackers from having to simply sniff passwords to having to become active attackers.

If anyone can see something I've missed tell me! Oh, and the challenge based mehod also prevents replay attacks.

Anyway, ho would you implement something like this? Well, the first step would be to find keyed hashing algoithm (though I'm sure a normal encryption algorithm and a hashing function would work perfectly fine, whereby you encrypt the challenge string with your password, and then hash the resul, and send that off), and create both a server side and client side implementation of it (or both, depending on how you go). (From this point onwards I'm going to pretend this is being done in PHP, because thats what I'm used to dealing with) Next you would have a page which first of all generated a sufficiently long random challenge string, saved it in a sesion, and included it in the Javascript of the page. The user types their username/password in the box and clicks submit. Instead of submitting the form, the browser encrypts the string with the password hash (since you don't want to store the password in clear text, even in the db and maybe you woudl even even salts it with the username for the off chance that the same challenge key gets provided to 2 users with the same password), and then hashes the reult, and sends off the usename/challenge response combination, the server gets the password from the database, does its own encryption, compares the 2, and then logs the user in/out. Then you put the username/password hash into the session for futher identification (because you never want to rely on a single 'logged in' variable, in case someone thinks they got hacked, and changes their password), and then you go about your business normally.

There could be a problem here with resource consumption on the server side when encrypting, but I don't think this would be a problem, as it would only add a single encryption operation to the workload.

Anyway, what do you guys think of this? Or do you think its too much effort, and that websites should just use SSL, which too is only vulnerable to MITM attacks?

[EDIT]: I'm reading up on EKE, and Augmented EKE now as well, but though they provide more security in the transmission of passwords (note that at this point I'm still only readin about EKE at this point), they seem to require quite a large amount of communication between both parties, which without something like a Java client or AJAX is useless, and then there is also the fact that the software you are getting for doing the encryption is sent by the server, so while the system is not ulnerable to MITM attacks, if they can replace the javascript, with say something that looks similar but has some kind of backdoor, and they extract the key, and do their normal MITM thing, so unless someone thinks of a way to ompletely prevent MITM attacks on the web, I tihnk that EKE or similar are a waste of time to implement.

[EDIT2]: Ok, after a bit more thinking (and eating dinner, ), I've seen that the challenge based system is still vulnerable to passive attackers because they can intercept the encrypted string, and brute force it, because the attacker knows the value that has been encrypted, and in this regard EKE seems like a better solution, except you would have to have an AJAX login because of the amount of communication needed between the 2 parties is more than would be feasible with simple HTTP/HTML transmissions (well, it *could* be possible, but it would be rather cumbersome, and AJAX would be much more useful), oh well, back to reading....heh, its funny, I'm still the only person who has read this topic...

[EDIT3]:So I was thinking, this whole system still relies on being able togive your password to the server, and it must be sent in clear (or at least decryptable text), so its still entirely possible for a passive attacker to hit you while you're signing up. So the next step to secure that would be to start using assymetric key encryption, when giving the server the password, and therefore raising the bar there as well for the attacker to have to be an active attacker, but while assymetric key encryption is great, its too resource intensive to use for logins. Also, to prevent MITM attacks occuring on normal logins, it could be interesting for the server to sign all the login pages it sends with its private key, and then the user checks that it was actualy signed by the server, but this method would probaly eat resources up too much, and if you can afford to be chewing those kind of resources, I question why you are even doing this kind of thing over HTTP, hell why is something that requires that kind of security even connected to the internet?..Ah well, some ideas are good (I think the challenge idea is good, but thats me), others like signing every login page, are just too expensive (resource wise) to bothr with...and stil no-one has read my rambling.........on the other hand I can keep making edits and no-one should be affeced.....