My client has had me implement some very proprietary algorithms. He wants
to charge his clients money every time someone requests these calculations
be preformed on their very sensitive.
In addition my client anticipates storing this extremely sensitive data
using Microsoft Access on his site which is largely implemented in Perl CGI.
Are there any special considerations with regard to Perl when we start
incorporating SSL? My understanding is that SSL/https is completely
transparent: our only change is that our URLs will contain https instead of
http - correct? Since all our data will be sensitive, we will not only be
using Perl to keep passwords safe, but everything we transmit and receive.
Now what about incorporating a certificate server like Verisign? I think
this is completely transparent too. We want Verisign to prevent an imposter
from creating a web site that looks identical to ours. I believe there are
no changes to our Perl CGI code for this either.
Finally, what about using cookies for authentication and authorization?
Assuming his clients are amenable to turning cookies on, I believe the
favorite algorithm is to generate a random number when we prompt for a
password and (assuming the user enters a valid username and password) store
this number both in the cookie on the browser and in the database. The
browser always presents this number to the Perl CGI code and we look up the
number in the database to find the username and bump a counter in our
database everytime the user requests an evaluation.
Is this approach secure? I am suspicious because in the Microsoft .NET
literature they suggest that cookie (or forms) security is only medium
security appropriate for storing things like frequent flyer miles or email
and is not appropriate for credit cards. What would be a more secure
approach to authentication and authorization?
Thanks,
Siegfried
