Quoting Brett Sanger <[EMAIL PROTECTED]>:
> > Can you not encrypt the param to make it "harder" to get the gist of
> > what it does?
>
> You can. This only makes affecting your system as easy/hard as figuring
> out your algorithm. Historically, that's no real protection at all.
> The user can feed in some values, see what encrypted values come out,
> and start breaking your system.
Well, if you cook up your own algorithm then yes, but if you use one of the
Crypt modules on CPAN, then I think it can be quite secure. Nothing is 100%
secure, but this should be close enough for most situations. And if your data
is really that critical, then follow everyone else's advice and use a session.
I have used something like the following in the past to pass data securely
through a client... I can't guarantee that it is fast, since any Crypto work is
usually slow, but it should be much faster than a database call...
sub encrypt_hash {
die "encrypt_hash requires a hash of data" if @_ % 2;
my %hash = @_;
my $cipher = _get_cipher_object();
return
URI::Escape::uri_escape(MIME::Base64::encode_base64($cipher->encrypt(Storable::freeze(\%hash))));
}
sub decrypt_hash {
my $hash = shift;
my $cipher = _get_cipher_object();
my $hashref =
Storable::thaw($cipher->decrypt(MIME::Base64::decode_base64(URI::Escape::uri_unescape($hash))));
return %{ $hashref } if $hashref;
}
sub _get_cipher_object {
return Crypt::CBC->new( {'key' => $SECRET,
'cipher' => 'Blowfish',
});
}
That will encrypt/decrypt a hash of values, and make it URL safe. You don't
want to throw too much info in there, because your URL's will get too long.
Also, I usually throw a timestamp in the hash so that I can see how old it is.
If it is older than say 1 hour, or 24 hours, then I don't accept the info.
For a different technique, if you are not worried about the contents of the
parameters, but you want to make sure that the end user cannot change them
unkowningly on you, then you can do something like the TicketAccess technique
used in the Eagle book*. Here you make a cryptographic signature of all the
variables you want to protect, and send that along with your data. Once back on
the server, you can double check the cryptographic signature to make sure
nothing was tampered with.
my $hash=MD5->hexhash($SECRET.
MD5->hexhash(join ":", $SECRET, $IP, $time, $expires, $user_name)
);
The resulting md5 hash should be passed along with the 4 parameters to the user.
Once those parameters are returned to the server, you can generate the exact
same MD5 hash using the data provided. If the hash strings don't match, then
you know one of the parameters was changed.
In the Eagle book* they use this in a cookie to allow Ticket based
authentication. You log onto a dedicated authentication server and recieve an
authentication ticket. You can use this Ticket on any of the other servers
without needing to authenticate for the time allowed. The other servers just
need to know the secret so they can recreate the md5 hash.
* Writing Apache Modules with Perl and C, by Lincoln Stein and Doug MacEachern
Let me know if anyone sees any major flaws in the above examples.
Cheers,
Cees
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
