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 12 12865
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/
"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.
"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
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.
> >> 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
"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
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
> 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.
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/
> 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
> > 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. This discussion thread is closed Replies have been disabled for this discussion. Similar topics
1 post
views
Thread by Chris |
last post: by
|
6 posts
views
Thread by Richard |
last post: by
|
9 posts
views
Thread by Mike Cronin via DotNetMonster.com |
last post: by
|
34 posts
views
Thread by jlocc |
last post: by
|
7 posts
views
Thread by helmut woess |
last post: by
|
113 posts
views
Thread by Bonj |
last post: by
|
6 posts
views
Thread by larry mckay |
last post: by
|
25 posts
views
Thread by eggie5 |
last post: by
|
8 posts
views
Thread by manmit.walia |
last post: by
|
19 posts
views
Thread by klenwell |
last post: by
| | | | | | | | | | |