I am well aware of the points you both make, I'm just stating that it's technically, and easily achived to encrypt before sending. The best option is oc to use an ssl connection.

If you simply use JS encryption, a hacker can still catch the password between you and the server, and just resubmit it. There's no way to tell if the hash was sent as a result of being calculated through a form, or just being sent directly.

If you simply use JS encryption, a hacker can still catch the password between you and the server, and just resubmit it. There's no way to tell if the hash was sent as a result of being calculated through a form, or just being sent directly.

 

I never said it was good either!

 

Or infact worthfull in anyway.

If you simply use JS encryption, a hacker can still catch the password between you and the server, and just resubmit it. There's no way to tell if the hash was sent as a result of being calculated through a form, or just being sent directly.

 

quick question: as long as the js encryption is asymetrical, could you include, as part of the encryption prosess, something dependant on, say, the time/date. thus, the password will not be the same twice, and resubmits would be easy to spot.

 

not that making asymetric encryption keys sounds all that easy

quick question: as long as the js encryption is asymetrical, could you include, as part of the encryption prosess, something dependant on, say, the time/date. thus, the password will not be the same twice, and resubmits would be easy to spot.

 

not that making asymetric encryption keys sounds all that easy

 

Or the IP of the sending user, it's very very very falable though.

Then there'd have to be a way to decrypt it back to some sort of hash that stays the same, so you could check it to be valid. If that was possible, they could easily decrypt it to a plain hash, and then re-add new time/date data.

quick question: as long as the js encryption is asymetrical, could you include, as part of the encryption prosess, something dependant on, say, the time/date. thus, the password will not be the same twice, and resubmits would be easy to spot.

 

not that making asymetric encryption keys sounds all that easy

 

 

Don't forget with sufficient skill and a little knowledge in the language all these can be manipulated. The date and time objects in JS allow you to mess with dates so the hacker could set their own date ID, as for the IP they could intercept that too... Client side encryption is a bad idea period, if you want it - use SSL as was suggested earlier