21–30 of 58 posts
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…
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…
sure sounds like you've re-implemented http digest authentication. http://en.wikipedia.org/wiki/Digest_access_authentication
I use http auth apache has modules to hook it up to just about any backend; it's supported by all browsers, and it's easy to automate against. I would be interested in knowing why more people don't use it.
Because, at least with mainstream browsers, users can't log out. You can fail certain formal security audits for using HTTP authentication.
hm. I know you can logout by going to https://username:boguspassword@thesiteyouarelogingoutfrom.co... but that will ask you to re-input your password, usually, making it unsuitable for a 'logout' button usually, I think. I wonder if there is a js workaround for that.
Earlier quoted context omitted.
sure sounds like you've re-implemented http digest authentication. http://en.wikipedia.org/wiki/Digest_access_authentication
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)
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.
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…
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 inst…
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)
Earlier quoted context omitted.
how come you don't use http digest? http://en.wikipedia.org/wiki/Digest_access_authentication it is significantly more secure without https
Because digest requires you to store the plaintext of the password on the server, making any database or filesystem exposure a calamity for all your users.
But I suppose that if you are using https, you get most of the advantages of digest anyhow.
Earlier quoted context omitted.
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 inst…
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.…
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.
Earlier quoted context omitted.
Because digest requires you to store the plaintext of the password on the server, making any database or filesystem exposure a calamity for all your users.
do you think a hashed password is going to last long against an attacker? considering how cheap computing resources are (and the common use of botnets, and the fact that most passwords are dictionary words) I treat password hashes as if they were cleartext passwords. But I suppose that if you are using https, you get most of the advantages of digest anyhow.