Client Side Security Question

[S1L3NC3]

Newbie here, to forums and javascript.

I first wish to thank all of oyu for the glorious input you all contribute, this forum helped me for about a month before i even had to register.

Problem:
I am using a client side javascript password and login, it was discussed and supplied in another thread, located here: http://www.codingforums.com/showthread.php?s=&threadid=10114
Its the one that goes to a chkpwrd.htm file and verifies the name and pass with a javascript file named UserPass.js (respectfully).

I was just curious to know if there was some code snippet you could paste on the intended target to get to when you log in, so that if someone found out the URL they couldnt just go straight to it, skipping the login page.

Maybe a check history to see if they did not come from that page, then force them to log in.

Thanks alot for your help in advance.

[soccer362001]

Your better off using a sever side language like PHP.

[S1L3NC3]

Indeed i am, however, i do not have access on server side. Therein lies the reason behind my question.

[AdamGundry]

And therein lies the problem with client-side password scripts - securing the end result. You could try setting a cookie in the UserPass.js file, then testing if that cookie is set on the "secured" page, and redirecting if it is not. This is still crackable, but slightly more secure.

Adam

[S1L3NC3]

Thank you for the suggestion. I am well aware of the downsides of using client side security with javascript.

So you are telling me that there is no code snippet or anything to check the url from which the browser window just came?

[pyro]

If you're using a gateway script (I'm assuming that that is what the other one is), you should be sure it uses either MD5 [128 bit], SHA1 [160 bit], or some other highly secure method of encrypting the data.) Take a look at http://pajhome.org.uk/crypt/md5/ for the encryption algorithims, or Jeff Mott's implimentation of it at http://forums.webdeveloper.com/showthread.php?s=&threadid=11865#post63856

[AdamGundry]

Pyro, the script basically tries to load a JS file with a name generated from the username and password entered - similar to generating a URL, but slightly more powerful. I don't suppose hashing the username/password would improve security greatly, as it's basically down to password guessing unless a directory listing of JS files can be acquired from the server. It would help a bit though, I guess.

S1L3NC3, I'm pretty certain there is a browser security restriction preventing access to the history except through a signed script. After all, would you want a webpage knowing all the other sites you have visited?

Adam

[pyro]

True, but barring that, I'm doubting you'll get a whole lot of security client side...

[Khalid Ali]

Originally posted by AdamGundry
I'm pretty certain there is a browser security restriction preventing access to the history except through a signed script.
Adam

I second Adams point here and add to it if I may.

The browser security modal does not allow you to access values from the history array/collection for entries( at any cost),if it does that has to be a bug.In my opinion its a useless exercise to even try doing that,there are reasons why somethings are not allowed on the client side.

[S1L3NC3]

Thank you all for the info, i appreciate it greatly.

[S1L3NC3]

Had an idea, what if you used like, history.back, but opened it in a new window, then stored that url in a variable, and if it didnt equal the login pages url, then send them to history.back in the main window.

Didnt know if you could communicate between windows with one script, but then i remember seeing it being done, children and parents can send variables if i remember correctly. (or maybe that was some server side PHP or something..dont remember)

Would this work?

I know they could always get around it by just setting their homepage to the site, and relaunching their browser, but plz still answer question, i am curious.

[pyro]

I doubt you'd be able to use history.back() like that...

[Jeff Mott]

I don't suppose hashing the username/password would improve security greatly, as it's basically down to password guessingIf all that is left for an attacker to do is guess one password after another (more technically known as brute-force search) then that is good. It means the algorithm is secure, and the security of the system now lies fully in the security of the key.

If you were to picture a safe. A secure safe is one with no alternative methods for breaking in (e.g., drilling, cutting, prying). If it is indeed secure then the only method available to the attacker would be to guess every combination.

[S1L3NC3]

Thanks alot guys, especially adam, khalid, and pyro.