Encryption of post data

[Peter Young]

I'm looking for ideas on encrypting form data. For example, if a user enters
a password, I would like to encrypt it before it gets posted, then decrypt
it server-side.

The obvious answer for a password is to 1-way hash it. Unfortunately, this
is for data that will not be known ahead of time - I have the requirement of
needing to encrypt any password-style textbox entries, then decrypt them on
the server. This is intended to provide 'better-than-nothing' security when
SSL is not present, and most likely would only be employed over an intranet.

It's my understanding that symmetric algos are fastest, but the problem
there is that the single key to encrypt/decrypt will need to be sent to the
client machine, which means it, along with the post data, is viewable by
anyone snooping.

An asymmetric algorithm, it would then seem, would do the trick. A public
key could be used client-side to encrypt, and then a private key could be
used server-side to decrypt. However, from googling on this, it appears that
javascript might not be up to the task from a performance perspective. I
haven't found any clear answers on this topic.

Any thoughts or direction on this are much appreciated.

TIA,
Pete

[David Dorward]

Peter Young wrote:

I'm looking for ideas on encrypting form data. For example, if a user
enters a password, I would like to encrypt it before it gets posted, then
decrypt it server-side.

http with SSL, AKA https.
--
David Dorward http://david.us-lot.org/

[Steven Dilley]

"Peter Young" <yo*****@comcast.no.net.spam.please> wrote in message
news:JwbYa.54410$cF.19329@rwcrnsc53...

I'm looking for ideas on encrypting form data. For example, if a user enters a password, I would like to encrypt it before it gets posted, then decrypt
it server-side.

It's my understanding that symmetric algos are fastest, but the problem
there is that the single key to encrypt/decrypt will need to be sent to the client machine, which means it, along with the post data, is viewable by
anyone snooping.

An asymmetric algorithm, it would then seem, would do the trick. A public
key could be used client-side to encrypt, and then a private key could be
used server-side to decrypt. However, from googling on this, it appears that javascript might not be up to the task from a performance perspective. I
haven't found any clear answers on this topic.

Any thoughts or direction on this are much appreciated.

Here is what you need: You do a normal encoding of the text. You send
the decoding key with the text, but you encode it using public/private key
encryption (with as many bits as the law allows).

The simplest way to do that is to use built-in security: secure sockets and
secure http.

[Peter Young]

"Steven Dilley" <steven.dilley.at.compuware.com> wrote in message
news:3f********@10.10.0.241...

Here is what you need: You do a normal encoding of the text. You send
the decoding key with the text, but you encode it using public/private key
encryption (with as many bits as the law allows).
Is this so that it performs fast enough, vs. just encrypting everything with
public/private?
The simplest way to do that is to use built-in security: secure sockets and secure http.

I understand that, which is why I said this is intended to provide
'better-than-nothing' security when SSL is not present.

Thanks,
Pete

[Disco]

Peter Young wrote:

I'm looking for ideas on encrypting form data. For example, if a user
enters a password, I would like to encrypt it before it gets posted,
then decrypt it server-side. .... Pete

Not sure if this will help, but here is a link to a javascript MD5 thing....
http://pajhome.org.uk/crypt/md5/

* Encrypt on the client.
* Send encrypted to server.
* Make use of encrypted. (either as is, or MD again)
eg...
md5("password") returns 5f4dcc3b5aa765d61d8327deb882cf99
....then...
md5("5f4dcc3b5aa765d61d8327deb882cf99") = returns
696d29e0940a4957748fe3fc9efd22a3

.... as i say, not sure if this will help, but it may.

[Peter Young]

> >> http with SSL, AKA https.

As I said in my original post, this is intended to provide
'better-than-nothing' security when SSL is not present.

Yes, but you're being silly, the effort involved in doing this for the
limited security it might give is not worth the effort, when you could
just enable SSL, what is stopping you?

It's not up to me. This is a product that we sell. If the customer wants
true security, we tell them to use SSL. However, they don't all want to use
SSL, yet they expect us to say we've at least tried to make it secure. I
want the implementation to be as secure as possible given that SSL is not
being used. Is that silly? Probably. But in a competitive marketplace, we do
what we have to do to keep the customer's interest.

-Pete

[Steven Dilley]

"Peter Young" <yo*****@comcast.no.net.spam.please> wrote in message
news:D6eYa.54979$cF.19380@rwcrnsc53...

"Steven Dilley" <steven.dilley.at.compuware.com> wrote in message
news:3f********@10.10.0.241...

Here is what you need: You do a normal encoding of the text. You send
the decoding key with the text, but you encode it using public/private key encryption (with as many bits as the law allows).
Is this so that it performs fast enough, vs. just encrypting everything

with public/private?

Yes, exactly.

The simplest way to do that is to use built-in security: secure sockets

and

secure http.

I understand that, which is why I said this is intended to provide
'better-than-nothing' security when SSL is not present.

What is the reason for avoiding ssl? Cost? Inconvenience?

--
Steve

[Andy Fish]

you might also find this link useful:

http://simrsa.netian.com/english/

[Grant Wagner]

Peter Young wrote:

> http with SSL, AKA https.

As I said in my original post, this is intended to provide
'better-than-nothing' security when SSL is not present.

Yes, but you're being silly, the effort involved in doing this for the
limited security it might give is not worth the effort, when you could
just enable SSL, what is stopping you?

It's not up to me. This is a product that we sell. If the customer wants
true security, we tell them to use SSL. However, they don't all want to use
SSL, yet they expect us to say we've at least tried to make it secure. I
want the implementation to be as secure as possible given that SSL is not
being used. Is that silly? Probably. But in a competitive marketplace, we do
what we have to do to keep the customer's interest.

-Pete

And in this case, doing what's in the customer's best interest would be to
explain to them that any "security" without SSL is not secure and they are
fooling themselves if they think otherwise.

The costs of development on this "security" to this point could have been put
towards purchasing a certificate to enable SSL.

When I discover I am doing business with a company that relies on half-assed
security measures, I move my business elsewhere.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 6/7 and Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html

[Peter Young]

> And in this case, doing what's in the customer's best interest would be to

explain to them that any "security" without SSL is not secure and they are
fooling themselves if they think otherwise.
We do.

The costs of development on this "security" to this point could have been put towards purchasing a certificate to enable SSL.

We aren't the ones buying the certificate. Once again, we build a product
that is sold to many customers. For whatever reason, some of the customers
don't want SSL, but they still want a warm fuzzy from us saying we've done
all we can short of SSL to make it secure.

Steven gave me a very good suggestion elsewhere in this thread, and it looks
like it will work fine.

[Jim Ley]

On Thu, 07 Aug 2003 15:18:29 GMT, "Peter Young"
<yo*****@comcast.no.net.spam.please> wrote:

And in this case, doing what's in the customer's best interest would be to
explain to them that any "security" without SSL is not secure and they are
fooling themselves if they think otherwise.

We do.

The costs of development on this "security" to this point could have been

put

towards purchasing a certificate to enable SSL.

We aren't the ones buying the certificate. Once again, we build a product
that is sold to many customers. For whatever reason, some of the customers
don't want SSL, but they still want a warm fuzzy from us saying we've done
all we can short of SSL to make it secure.

If it's intranet, you don't even need to purchase a certificate, self
signed one with authority pushed out to the desktops, or just ignored.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Peter Young]

> If it's intranet, you don't even need to purchase a certificate, self

signed one with authority pushed out to the desktops, or just ignored.

That's good to know, thanks.

-Pete

[Douglas Crockford]

> > And in this case, doing what's in the customer's best interest would be to

explain to them that any "security" without SSL is not secure and they are
fooling themselves if they think otherwise.

We aren't the ones buying the certificate. Once again, we build a product
that is sold to many customers. For whatever reason, some of the customers
don't want SSL, but they still want a warm fuzzy from us saying we've done
all we can short of SSL to make it secure.

Security is the bane of the internet. Link encryption does not by itself provide
secure distributed systems, but it is a necessary precondition. SSL provides
link encryption. It has been well tested over many years. It is madness to not
use it in environments that provide it.

Whatever you roll on your own is necessarily less trustworthy than SSL. If your
customers don't want SSL because they don't trust it, they should not be
satisfied by this effort. A better use of resources would be to educate them and
you on secure distributed architecture. False security can be horrendously
expensive.