Cookie encryption?

[Walter Sobchak]

The connection is ssl encrypted and I need to write some sensitive
information in a cookie. I'd like to encrypt the cookie on the client so
it could be decrypted later on the server.

1. If I use a symmetric algorithm how do I send the encryption key?
2. Is there any asymmetric algorithm that doesn't have an impact on
performance?
3. Is there a difference in writing cookies with http an https?
I think https in that case doesn't help.

Thanks in advance for any suggestions.

 

[Doug Miller]

The connection is ssl encrypted and I need to write some sensitive
information in a cookie. I'd like to encrypt the cookie on the client so
it could be decrypted later on the server.

Posting this question in a javascript newsgroup implies that you intend to
write your encryption algorithm in javascript.

Consider that doing so exposes your encryption algorithm, including the
encryption key, to anyone with the wit to click View Source.

Does this seem like a good plan?


--
Regards,
Doug Miller (alphageek-at-milmac-dot-com)

Join the UseNet Improvement Project: killfile Google Groups.
http://www.improve-usenet.org

Get a copy of my NEW AND IMPROVED TrollFilter for NewsProxy/Nfilter
by sending email to autoresponder at filterinfo-at-milmac-dot-com
You must use your REAL email address to get a response.

Download Nfilter at http://www.milmac.com/np-120.exe

 

[Bart Van der Donck]

The connection is ssl encrypted and I need to write some sensitive
information in a cookie. I'd like to encrypt the cookie on the client so
it could be decrypted later on the server.

I would usually not perform such a task at the client. The server
could both encrypt the value and set the cookie via a HTTP-header
(still better than document.cookie IMHO).

1. If I use a symmetric algorithm how do I send the encryption key?

If you would use javascript, there is no other choice than making the
key/salt available as plaintext for the script in the web page; thus
making it interceptable for the viewer of the page. I think there can
be little doubt that a server-side solution would be better in this
case.

2. Is there any asymmetric algorithm that doesn't have an impact on
performance?

Encryption is memory-intensive by nature; but I wouldn't care much
about only one en-/decrypt action. The difficuly for asymmetric
cryptography is that there are both the private key (encrypt) and the
public key (decrypt).

A somewhat safe strategy could be to make only the public key
available to the client; so he can only decrypt the cookie with it.
But I believe this would be the opposite of your plan: when you want
to encrypt asymmetrically in javascript, you always need the private
key.

But I think that symmetric cryptography is more recommended in your
scenario (and preferably done at the server).

3. Is there a difference in writing cookies with http an https?
I think https in that case doesn't help.

HTTPS secures the transmission of data along the line, but nothing
more. You are only reasonably safe that nobody can intercept data
between server and client. Most security problems do not relate to
this area.

 

[Mike Duffy]

(e-mail address removed) (Doug Miller) wrote in

Consider that doing so exposes your encryption algorithm, including
the encryption key, to anyone with the wit to click View Source.

Does this seem like a good plan?

You could ask the end user for a password. Then you end up with something
that can only be decrypted by the client. You would need to prompt the user
again for the password when it is needed to decrypt the cookie.

 

[micah]

i think it'd be prudent to change your approach on this one, since
you're running into a fundamental roadblock: you want to put secure
info somewhere that's inherently insecure.

personally, i'd just write the data to the server and associate it
with that user's account. if there isn't a logged-in user involved in
this operation then... well... what sensitive information could/would
you give to someone you haven't authenticated?

-micah

 

[Walter Sobchak]

I would usually not perform such a task at the client. The server
could both encrypt the value and set the cookie via a HTTP-header
(still better than document.cookie IMHO).


If you would use javascript, there is no other choice than making the
key/salt available as plaintext for the script in the web page; thus
making it interceptable for the viewer of the page. I think there can
be little doubt that a server-side solution would be better in this
case.


Encryption is memory-intensive by nature; but I wouldn't care much
about only one en-/decrypt action. The difficuly for asymmetric
cryptography is that there are both the private key (encrypt) and the
public key (decrypt).

A somewhat safe strategy could be to make only the public key
available to the client; so he can only decrypt the cookie with it.
But I believe this would be the opposite of your plan: when you want
to encrypt asymmetrically in javascript, you always need the private
key.

But I think that symmetric cryptography is more recommended in your
scenario (and preferably done at the server).


HTTPS secures the transmission of data along the line, but nothing
more. You are only reasonably safe that nobody can intercept data
between server and client. Most security problems do not relate to
this area.

The thing is that I have the information on the client side. So I want
to encrypt it and out it in a cookie.
I know that should be done on the server side but I don't know how.
Is there a way to call a server function from a client in a way that you
send a parameter to that function and receive the result??

 

[Walter Sobchak]

It sounds like a good solution but the problem is that user enters some
information on the client side and I need to have this information in a
cookie because it is some kind of an authentication ticket.

 

[Bart Van der Donck]

Walter Sobchak wrote:

....

...
The thing is that I have the information on the client side. So I want
to encrypt it and out it in a cookie.
I know that should be done on the server side but I don't know how.

I think the most classic design would be like this:

1. Put the information in an <input> (type=hidden?)
2. submit the form (manually?) as post-request over HTTPS to server
3. server encrypts it (+probably stores it?)
4. send next 'you-are-now-logged-in'-page with cookie in HTTP-header

The javascript way:

1. offer string+salt to the encryption alghoritm on the page
http://www.google.com/search?q=javascript+encryption
2. use document.cookie() to store it
http://www.w3schools.com/JS/js_cookies.asp

Is there a way to call a server function from a client in a way that you
send a parameter to that function and receive the result??

http://en.wikipedia.org/wiki/XMLHttpRequest