Quick web app question!

[Jon-86]

Would using JS to hash a password before its sent to the server be any more secure?
Currently most login systems I have seen do this server side and then compare.

[BoneIdol]

Not really. If you're worried about the password being intercepted between the client and the server, you should use SSL.

[elbekko]

It'd add a bit of extra security, yes.

[Jon-86]

Hmmm mixed responses. BoneIdol, can you explain why that is?

[BoneIdol]

At 5/12/08 04:29 PM, elbekko wrote: It'd add a bit of extra security, yes.

And assuming that the user has javascript turned off? You'd have to make a work around for them... only that would defeat the whole point of doing it in the first place.

Javascript is NOTa tool for security, it is a tool for user convienence. All serious validation should be done on the server. The only reason to do any validation in javascript is to save users from some mild frustration and an extra page load.

[Jon-86]

I used to make an exception for JS being disabled. And that could be done server side. But you missed the point. The validation is not done client side. The idea is simply hashing the password client side so it cant be sniffed over the network.

It would then be compared server-side. This is instead of it being sent plain text over the network. Then hashed and compared server-side.

[BoneIdol]

At 5/12/08 04:36 PM, Jon-86 wrote: Hmmm mixed responses. BoneIdol, can you explain why that is?

Sorry didn't catch that when I posted.

Let's assume that you did hash the password, and set a POST variable to true to say that javascript has encrypted it. Let's also assume that this request is intercepted halfway through by some script kitty with a packet sniffer. (Odds of this are pretty damn slim)

Only, what's to stop our would be hacker from just sending the hashed password he's got alongside the POST variable?

The only way to seriously stop passwords from being intercepted 100% of the time is to use an encrypted connection. (Secure Socket Layer) Only they have a few drawbacks...

Encrypted connections use something like 4x as much bandwidth, require a valid SSL certificate, (which can cost obscene amounts per annum, depending on several factors) uses more cpu resources per request and requires you to code specially for them. Unless you're deal with money or emails it usually isn't worth it.

[Jon-86]

Theres something to think about :) I know SSL costs quite a bit and thats why I thought of this.
But its only the username and password thats being sent. My pseudo code is along the lines of.

//Client

- Enter name & password
- Click submit.
- JS hash password and send that with name using POST

//Server

- Use name to retrieve record from database
- Compare recieved password with hash in database

- If they match login
- Else send error message#

Normaly the server hashes the password it recieves and then compared. I think that doing this step client side would be benificial in some way.

[BoneIdol]

At 5/12/08 04:54 PM, Jon-86 wrote: Theres something to think about :) I know SSL costs quite a bit and thats why I thought of this.
But its only the username and password thats being sent. My pseudo code is along the lines of.

//Client

- Enter name & password
- Click submit.
- JS hash password and send that with name using POST

//Server

- Use name to retrieve record from database
- Compare recieved password with hash in database

- If they match login
- Else send error message#

Normaly the server hashes the password it recieves and then compared. I think that doing this step client side would be benificial in some way.

Only that they can just send the hashed password they sniffed and it would still work let them in...

Sorry to sound such an odious git about this, but you would be better off on the security front if you just sent the username and password as some obscure post variable. Both methods are security through obscurity. I say obscurity, it's more like security through being ever so slightly more unfamiliar.

[Jon-86]

No your alright their. I get you now. Sometimes the obvious needs to be pointed out. Ah well back to the drawing board in my head I guess. Thanks.

[elbekko]

It won't prevent sniffing, but atleast the passwords won't be sent as plaintext.

[Jon-86]

It is still worth doing yes because of that. But it dosnt solve the whole problem that using SSL would.
Although it should stop a few script kiddes. 'I hope' another hoop for an attacker to jump though I guess.

The more the merrier.

[BoneIdol]

At 5/12/08 05:12 PM, elbekko wrote: It won't prevent sniffing, but atleast the passwords won't be sent as plaintext.

True but it's code bloat. Trust me on this, when a project accumulates a dozen or so features like this you will find it extremely difficult to maintain it effectively.

Yes, it's important to protect your users and everything but sometimes you have to make compromises. Sacrificing usability and compatibility for tiny security advantages is a silly way to go about things; just look how well it's worked out for the UK.

Stupid-Million security cameras, can be held without trial for 28 days (which was a compromise!), can't protest within a county of parliament without a license (and guess who grants those?) no right to silence and you can now be arrested for thought crimes regarding terrorism.

Let that be a lesson to you.