I read a MSDN case study of a web system build using ASP.NET, and I have to say I'm appalled. I'm also not an expert in javascript, I've learned what I need to get by, and I'm using the solution Microsoft seems to recommend.

My login page has two asp.net textbox server controls, one for username and another for password, and when the login button is clicked, these are sent, plaintext, to the server. Then the server calculates an MD5 hash for the password and compares this against the database to see whether the user has entered the correct word or phrase.

Now for a tiny little site like mine with zero IBLs that's fine. But it's not a solution. Surely, you must be able to do the hashing on the client side before sending it out over the network for any hacker with a sniffing tool to see?

Originally Posted by Learning Newbie

I read a MSDN case study of a web system build using ASP.NET, and I have to say I'm appalled. I'm also not an expert in javascript, I've learned what I need to get by, and I'm using the solution Microsoft seems to recommend.

My login page has two asp.net textbox server controls, one for username and another for password, and when the login button is clicked, these are sent, plaintext, to the server. Then the server calculates an MD5 hash for the password and compares this against the database to see whether the user has entered the correct word or phrase.

Now for a tiny little site like mine with zero IBLs that's fine. But it's not a solution. Surely, you must be able to do the hashing on the client side before sending it out over the network for any hacker with a sniffing tool to see?

For what you have described, what would be the diff of sniffing and resending the hashed vs plaintext password?
Answer, nothing.
Use TLS/SSL, read https
OTOH, there are some libraries to perform encruption on the client. Notably dojo.

Dear Newbie,

Consider this: if you send a hash over the network and the server uses the hash (not the actual password, which wasn't sent) to authenticate the user, if someone intercepts this hash, they'll be able to impersonate the user just the same. The only difference is that the interceptor won't know the actual password, but they won't *need* the actual password to impersonate the user.

As our colleague Mr ForBeer has pointed out, the solution is to send all sensitive data over SSL (https protocol).

If for whatever reason you still want a hashing function in JavaScript, feel free to use the SHA1 functions in the attached file.

Cheers!