Storing important data in the url is not a good idea, since everyone has the data handy


So let it be in the URL- if it's encrypted, what does it matter? It's too computationally expensive to figure out quickly, and relatively safe, that is, if in fact these are not the full login credentials (infidel2122 ?). But even if they are login credentials, mixed with enforced frequent password aging, is probably "pretty good" enough.

Or do it with Crypt::OpenPGP as mentioned by edan, but Crypt::Rot13 is easy to figure out and brute force, even with (multiple) URL-encoding of the string.

Thank you for the reply.
So let it be in the URL- if it's encrypted, what does it matter? It's too computationally expensive to figure out quickly, and relatively safe, that is, if in fact these are not the full login credentials (infidel2122 ?).

Yes that's essentially the criteria, though this won't be a login, it will point to a virtual public url. So it's actually okay if search engines/caches or whatever pick it up as the other poster mentioned.

And it's no problem if a key has to be involved to encrypt, decrypt on each end. So I'll take a look at the PGP module, I kind of assumed it'd give me a huge 256 character long url or some such, which I've been trying to avoid.

I'm also wondering if whatever method is used to store passwords in /etc/shadow would work. I gather that is non trivial to decrypt and should be reliable given its wide use.

thanks! Kevin

Crypt::OpenPGP?

Hi, thanks for the reply

I tried that but it looks like about the shortest escaped url I can get is something like:

%8C%0D%04%02%03%02%B2%9F%0B%A1%60%06%1C%E6%60%A4%23%C5%A7%BA%CE%F3%CC%C3%EA%96X%06~%EA%24z%2B!_H%B5%CCi%23B%A0y%8E%13d%A4%F8F%0A%BFP

Which is quite a bit longer than I was hoping for.

thanks, Keivn

Perhaps you could create a one time pad on the server (assuming you have a source of true randomness, like /dev/random under Linux), then pass in the index number of the one time pad in plaintext, and the encrypted data. That's the "most perfect" form of encryption, but generating and transmitting a one time pad is cumbersome.

Since you're maintaining the one time pad file on your own web server, you don't need to transmit it. Generating it may or may not be practical: you need a source of true randomness. You also need some way to keep it from getting too big or too slow: by using the byte offset for your index, you could speed up lookups, but you'ld need some way to periodically trim the file, or it will get too big.

It's just a thought. You'll have to examine for yourself whether it could fit your needs.

--
Ytrew Q. Uiop

If you are really concerned about security, then don't let the data out of your server!

Use some user (session) data stored the server (file, database, ...). Depending on the security required maybe encrypt that data too. (And when stored on the server, size does not matter as much.)

Have the session data identification tagged (signed with MD5 for ex.) and encrypted with a secret key (server only) to identify tampering. Include that in the URL.

---Lars