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.
| [reply]
[d/l] |
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
| [reply] |
I think the methods used in /etc/shadow (classic unix-crypt or MD5) and the like would not work for you, as these methods are one-way. You cannot decrypt anything, you can only check if a password is valid by putting the user-supplied password though the hashing (not encrypting) algorithm and comparing the result to the stored value in /etc/shadow.
| [reply] |