2

An object needs to be transfered in either URL or Cookie. Object is very simple, a few String fields and a DateTime field. It should be secure and compact. What's the best approach ?

Note: I'm not going to use SSL just for sending such a little object securely.

Xaqron
  • 29,931
  • 42
  • 140
  • 205
  • 1
    Why does the object itself need to be transferred in the URL or cookie? Why can't the object itself be kept on the server and some other identifier passed in the URL or cookie? – Ian Mercer Nov 16 '10 at 21:40
  • For fast synchronization. Since this is one-way validation and receiver would not wait for sender to confirm data security. – Xaqron Nov 16 '10 at 21:49

4 Answers4

3

Do you just need to read it back on the server ? If so, simply serialize the object, encrypt using a symmetric algorithm, then store as a BASE64 encoded string into an URL parameter or cookie.

driis
  • 161,458
  • 45
  • 265
  • 341
  • I was planned exactly to do this. But I was not sure if it's a good idea or not. Thanks. – Xaqron Nov 16 '10 at 21:54
  • +1 driis' process pretty much guarantees that your data will be safe during transfer. Remus Rusanu brought up worries about this type of procedure but those cases require a hacker's access and control of the client and/or server machines. – Paul Sasik Nov 16 '10 at 22:02
  • 1
    @Paul Sasik: my concern is for the case the data is encrypted in the Browser and sent to the server. There is no secure scheme to bootstrap this w/o either SSL or user entering a secret. And the attacker need just to see the packets in transit *at any point* to succeed, no control of client nor server. If the need is just to store an encrypted cookie that is set by the server and read by the server, then the problem is much, much simpler as the server can use any key of choice. Just remember to `HTTPONLY` the cookie http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html – Remus Rusanu Nov 16 '10 at 22:18
  • @Remus: Yeah, i realized shortly after commenting that at some point the symmetric key will have to be transmitted in plain text to the client and thus opening the entire process to be hacked... I agree that SSL and asymmetric encryption are the best. – Paul Sasik Nov 16 '10 at 22:32
  • RE Comments: Obviously, this approach is flawed if it is the client that needs to be able to read the data (ie. if you need to exchange the symmetric key, then this gives you security by obscurity at best). That's also in my answer; this is only a good idea if it is the server itself that needs to decrypt the data at a later stage. – driis Nov 17 '10 at 15:28
1

Use encryption.

I've got my implementation from AES in ASP.NET with VB.NET, which provides good security for these kinds of jobs.

The kind of encryption you are talking about is quite sensitive because you are sending small packages with content that could be guessed (the date/time for example). The encryption scheme described in that article provides good security for specifically that usage.

Community
  • 1
  • 1
Pieter van Ginkel
  • 29,160
  • 8
  • 71
  • 111
  • -1: "The world is full of bad security systems designed by people who read Applied Cryptography": http://www.schneier.com/book-sandl-pref.html. Writing AES encrypt/decrypt demo code is trivial, if one leaves out the **real** problem: figuring out the key to encrypt with in a data exchange. – Remus Rusanu Nov 16 '10 at 22:13
  • @Remus Rusana - So you're giving me a -1 because of the quality of the SO article I linked to? I didn't read Applied Cryptography; I don't know squad about encryption; I just found this article. Maybe you should give the linked answer a -1. – Pieter van Ginkel Nov 17 '10 at 05:58
1

The obvious solution everybody will give is 'use encryption'. But this answer doesn't solve anything actually. The real problem is What key should I encrypt with??. And there is no simple answer there.

You cannot embed secrets inside an application, which renders all hard coded 'known' keys a non-starter.

You can use a user provided secret, like his password, but that is a logistical nightmare in order to get the secret provisioned (and kept secure) on the server too.

Or you can implement a key exchange protocol with the server, like the ones used in SSL or in TLS. These key exchange protocols though start from a public key provided by the server (the SSL cert's key), it is possible to write a similar key exchange protocol (just duplicate the steps TLS does, as per RFC 2246). But one mistake, and you've ruined everything and you won't even know it is ruined.

So the best option, by a overwhelming margin, is to use an off-the-shelf solution, and there is only one with enough deployed base to matter: HTTPS. That is SSL/TLS. It doesn't matter how small the object is. This is your only viable option.

Paul Sasik
  • 79,492
  • 20
  • 149
  • 189
Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
  • Do you plan to transfer from Browser to Server, or just to store the data encrypted on the response (ie. a cookie than only the server can read back when presented with it later)? – Remus Rusanu Nov 16 '10 at 22:04
  • If the data is set by the server and the agent (Browser) simply sends back the same data, then is easy. Use a cookie, mark it `HTTPONLY` (at least deter some kiddies) and have a secret in the server to encrypt cookies with (a realm master secret, which should be rotated frequently). – Remus Rusanu Nov 16 '10 at 22:20
  • BTW, you'll need a secure storage on the server for the 'real master secret' (the current key that encrypts the cookies). Use DPAPI: http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.aspx – Remus Rusanu Nov 16 '10 at 22:23
  • Why are you having to avoid SSL? It's an IT/config solution that removes an incredible amount of programming headache and security pitfalls. – Paul Sasik Nov 16 '10 at 22:35
  • @paul: since it needs 1) a valid certificate (I cannot buy) 2) This is a download server which is not going to secure all heavy traffic for a single light object. – Xaqron Nov 16 '10 at 23:12
  • @Remus Rusana - He asked for something other than HTTPS. -1 for me; -1 for you. – Pieter van Ginkel Nov 17 '10 at 06:01
0

Have you considered just passing values via querystring and encrypting them?

Community
  • 1
  • 1
Ta01
  • 31,040
  • 13
  • 70
  • 99