How do I encode passwords in web forms without javascript?

views:

answers:

+4 Q:

How do I encode passwords in web forms without javascript?

It's not that I don't have access to javascript, of course. In most of my CS Web Development courses, we are taught a little bit about server-side validation, and then as soon as javascript is introduced, server-side validation is thrown out the window.

I choose not to just rely on javascript, as the client-side is never a secure place. I have gotten into the habit of writing both the client and server-side code for such things. However, for a web application that I am writing that has optional AJAX, I do not want the password to be send plaintext over the wire if someone has javascript turned off.

I realize I may be asking a catch-22 situation, so let me just ask this: how do we know our users' passwords will be secure (enough) from malicious users on the same network when all we can rely on is server-side scripting. On that first request from the login page, is there any way to have the browser encrypt a data field?

+3 A:

The easy solution is SSL.

Chris S 2010-02-24 01:49:16

+4 A:

SSL Solves this problem. For the record, passwords should never be "encrypted" or "encoded", this employs that there is a method of "Decoding" or "Decrypting" which is a clear violation if CWE-257. Passwords must be hashed, SHA-256 is a great choice, but this is not meant for transmission, only storage. When you transit secrets there is a long list of things that can go wrong, SSL is by far the best choice for solving these issues.

If the attacker can sniff the traffic then they will be able to see the session id and use it immediately, so its a moot point. You have to use SSL to protect the authenticated session anyway.

Rook 2010-02-24 02:57:16

So what I'm getting is this: if a user has to be logged into a site, and you don't want anyone eavesdropping, use SSL for each page, including the ones after the login? How is it that this site is http:// and not https://? Bad practice? Or am I missing another concept?

sdellysse 2010-02-24 21:45:28

Your right, nothing is stopping an attacker from hijacking a stackoverflow session by sniffing the traffic. You could be sipping a hot chi in a cafe using the open wireless and have you session hijacked. Most developers don't understand this, but if you look at any online banking portal like bankofamerica.com they protect all authenticated sessions with ssl.

Rook 2010-02-24 22:04:27

The chances of someone sniffing out your login here are remote at best, and if you use an OpenID for login then that site is responsible for authentication (in my case done via HTTP Digest, which is hashed). To add to the unlikelihood of someone sniffing out your stackoverflow session, most people who have those skill wouldn't care about stackoverflow or defacing your account anyway.

Chris S 2010-02-25 20:37:31

You can also use Digest HTTP Authentication.

Goran Rakic 2010-02-24 03:00:36

HTTP Digest doesn't allow for a form based login.

Chris S 2010-02-25 20:40:20

+2 A:

I think you're mixing up a couple of concepts. The browser does not encrypt individual fields. Client-side scripting, server-side scripting and AJAX are not means to defend against eavesdropping.

As others have said, SSL is the technology that encrypts the data. The entire request and response, including the fields and scripts are contained within the SSL session.

Andrew Strong 2010-02-24 03:24:31

That is true, I was mixing up the wrong things. After reading these answers, it makes perfect sense that SSL encrypts everything, or else it wouldn't be of much use. I think I was missing the forest for the trees.

sdellysse 2010-02-24 21:43:12

ansaurus

tags:

views:

answers:

How do I encode passwords in web forms without javascript?

related questions