There is a reason to hash the password on the client side, if you are using a secure connection (https)?
yeah; if you're DB gets hacked, you are facing a lot more liability if you store clear-text passwords than hashes. You should never let a password enter your building; it becomes your liability at that point.
If you form is using GET the password can show up in logs and history. I once saw terribly-written embed code that changed the action of whatever was the first form in the dom. If that happens to you and you send passwords to lord know where, people are going to complain loudly.
yeah; if you're DB gets hacked, you are facing a lot more liability if you store clear-text passwords than hashes. You should never let a password enter your building; it becomes your liability at that point.
If you form is using GET the password can show up in logs and history. I once saw terribly-written embed code that changed the action of whatever was the first form in the dom. If that happens to you and you send passwords to lord know where, people are going to complain loudly.
I know it's bad practice to store clear-text passwords. But i can hash password on the server-side, not client.
Client-side hashing isn't "necessary" over SSL, so long as you transmit the password in POST data, as opposed to GET data.
ADDENDUM: In fact, I think it's actually quite uncommon that web apps will perform client-side password hashing. If you open Firebug or inspector in chrome/safari and log into facebook, for instance, you'll see that your credentials are provided plainly in the POST data. The only transit security is the SSL.
Reply With Quote
Originally Posted by CrazySurfer
Bookmarks