[dryicerx]

Since most people already talk about the backend of it, let me share how to securely send the password from the browser to the server encrypted, instead of simply in clear text. (when you can't use SSL for some reason)

+ Server has your passwords stored as sha1(password+salt(password)). salt function isn't secret (eg. reverse the text)

- Client visits login page

- Website generates random token. Then sends back HTML with the random token

- Client generates passresponse = sha1(token + sha1(password + salt(password)))

- Client sends the passresponse, token, and username back

- Website checks for existence of token, removes it, then computes it's own sha1(token + password_hash_from_db) and checks against the sent passresponse.

This way the password is never sent in clear text. Unlike HTTP authentication, this works nicely with html forms since you can do all the crypt in js. Then again, this might be a bit overkill... and using SSL is probably a better option.

Just sharing another solution.

[tptacek]

You're describing the simplest possible challenge-response scheme. It has two problems, both severe enough that you shouldn't recommend people waste time implementing it:

* First, because no browser bakes this crypto protocol in, you have to deliver it over Javascript. The protocol basically stipulates that you don't have SSL/TLS. So all you've done is move the goalposts. No matter what kind of dance you do (for instance: Meebo actually delivers a JS implementation of RSA!), the action is now in the JS delivery, which is trivially compromised.

* Second, secure authentication schemes aren't vulnerable to trivial dictionary attacks. This one is: the attacker is stipulated to have access to your traffic. She sees the nonce the server sends and the hash the client responds with. She can solve for the password by (very fast) brute force against a wordlist.

[dryicerx]

To your first point, yes js would be doing the crypt, if the js delivery can be compromised, then the login html delivery can be equally compromised (which would send the login information somewhere else)

I agree with your second point, a eavesdropped can use a dictionary attack. It makes it just a tiny bit harder for them since they need to generate their own cleartext-crypttext and cannot use a pregenerated table.

I am curious, is there a better way to do this (other than SSL or using RSA)

[tptacek]

In that first sentence, you need to take the we word "if" out. The exact same attack that motivated you to come up with the challenge-response scheme works against the JS delivery.

In the third sentence, take the "or RSA" out. There's no way to get a browser to safely do RSA authentication without SSL.

I have good news for you. The answer to this problem doesn't involve complex technology. What security practitioners are going to recommend to you is, just put up a login page, and send usernames and passwords. I have just released you from having to waste time and energy thinking about this.

[lsc]

sure sounds like you've re-implemented http digest authentication.

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

[dryicerx]

That's what I had been using earlier, problem with that is the ugly login box the browsers prompt (there is no way to integrate HTTP Authentication in to HTML)

[lsc]

ah. well, I obviously have a very poor sense of aesthetics (look at my webpage- it would have been ugly in 1995) but thanks, that answers my question. (my question is "why don't people use http auth anymore?)

I really like http auth because it's a system level solution, and I'm the computer janitor; I know where the problems with http auth are without wondering if the dev who wrote the webapp made a mistake or not.