Re: Security and JavaScript

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

Comment on Re: Security and JavaScript

Replies are listed 'Best First'.
Re: Re: Security and JavaScript by rlgarris682 (Initiate) on Apr 29, 2003 at 01:43 UTC
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)	[reply]
Re: Re: Re: Security and JavaScript by thraxil (Prior) on Apr 29, 2003 at 15:23 UTC
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	[reply]


P is for Practical
	PerlMonks