Right yeah actually the secret code kept in the html file is never sent as plain text only the hash of the randomly generated number and secret code is so even if a packet sniffer gets hold of the hash it wouldn't do them any good because that hash is only valid for that session and linked to the clients original ip address. The SHA1 algorithm is a 160-bit one-way encryption and is more secure than MD5.

if i'm reading it right, this doesn't sound all that solid to me. what's keeping a password guessing bot from just mimicking all of the javascript's functionality? especially since it looks like all of your 'secret' strings are sent across the network in cleartext.

really, the only way to protect yourself at all from a brute force guesser is to cut off the IP after a couple incorrect guesses. even then, a determined attacker with access to a lot of IP addresses and in no hurry could still be dangerous.

another big problem i see with your approach is just the amount of complexity involved. cryptographic protocols are exceedingly hard to design and implement correctly. the more complex it is, the easier it is to screw up one little piece and comprimise the whole system.

if your client is going to insist on using weak, guessable passwords, probably the best thing you could do would be to implement a public key system. the client creates a keypair on their machine, encrypting the private key with whatever weak password they want to use, and gives you a copy of the public key. then the server generates a random challenge string, encrypts it with their public key and sends it to the browser. the user copies and pastes the ciphertext into a pgp app, decrypts it and pastes the results back into a web-form. the server checks it and sets a session cookie if it matches the original. this would still have to be done over SSL or the session could be hijacked later on by someone snooping the network. as long as the client's machine or private key isn't comprimised, you're ok.

the simplest and most highly recommended solution though is to just convince your client that they need to use good passwords and then use regular HTTP authentication over SSL.

anders pearson

Please read the post I put above this one

Thank you for your help. Yes I am already using SSL encryption but that doesn't stop someone from getting into the page and trying passwords and yes I will block IP adresses after 3 unsucessful tries at a password

To clarify my original posting (since my friend Ryan just informed me to use html tags in my positings this should read better) I am NEVER sending the secret code as plain text. The secret code is SHA1 hashed with the randomly generated number received from the server. So even if the session id is found by a packet sniffer then it wouldn't do any good since it is only for this session (the session would be linked to the client's ip address in addition)

Anyway the only security purpose this really servers is to indentify the remote user's computer.

In simplest terms, if you are the client and I am the server, it is like are you who you say you are? And if so hash this random number with the secret code and send me the result

Then I will do the same with what I know to be the secret code and with the random string I just generated and if our two hashes match I will let you access this part of my site

If you want more implentation details of the javascript see this page

If you were curious as well I am using mod_perl with CGI::Session using /IP-match/ on (I prefer CGI session to Apache::Session, although both are good, I just have more experience with CGI::Session)

ok, is the idea that the HTML file with the 'secret' string is sitting on the client's hard-drive being accessed as a local file and presumably previously copied there in some secure manner? that wasn't clear to me from your initial description but it sounds like that must be what you're doing. (i had been assuming that all files involved were sent over from the webserver).

if this is the case, then i agree with jonnyfolk and perrin below that having the client enter a password is somewhat superflous. you already have a shared secret, just use it as the password over an SSL connection. don't bother with javascript.

anders pearson

The reason I am not just using password security is that I am doing this for a client who has trouble remembering passwords so he keeps his passwords simple

/me re-reads the post and sees this is already done - lol. But, I think your solution is a little overkill. If you're going to all the trouble of encrypting a random string, why bother with the password at all? When you send the request to the server for the random string, why not just lock the login to that IP. That, combined with the existing encryption ideas would surely be enough. (unless there are other people with access to the client's machine, I suppose :)

If you just have the one client who wants access, why not create an html page with a form that submits to the site. Include a nice long hidden field in the form (a long password), or use JS to set a local cookie before login. Then simply get the client to save the html file on their hard drive and open the local page when logging in. That way there's nothing for a bot / outsider to hit.

.02

cLive ;-)

Okay this is my final post for tonight before I go play basketabll

Your right it is a little overkill but this simply assure that someone won't just stumble upon the admistration section of the website and since the implementation of this sounds a lot more difficult that it actually is (I have it done pretty much) I understand your thought. TY for the input