On Tue, Aug 31, 2004 at 08:30:35AM -0600, Siegfried Heintze wrote: > 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. > > Microsoft Access does not scale. Consider using SQL Server if it must be MS, or investigate the open source databases like PostgreSQL and MySQL if cost is an issue. Stray away from using Access for anything production as its meant to be a simple DB. It will burn them. Most of my current job is converting all the Access DB's floating around to our Oracle DB, while the MIS department is figuring out ways to make sure Access will not run on anyone's computers :)
> > > 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. > SSL provides a wrapper around your packets ensuring their encrypted. > > > 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. > You are correct, CA and Certificates are a part of the SSL suite and handled without any provisions in your code. By the time your code executes, this is completely setup. > > > 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. > More than just a random number in most cases. Usually double md5sum of the epoch bitwise or'd or appended with the process id number, ip address, or user id or a combination of thereof might work. > > > 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? > > I believe they mean don't store the credit card information in the cookie. Storing some sort of decent hash of some data that identifies a user on your site is pretty good. Cookies are stored on the client's machine and kept in a place where the browser can send them a malicious site if there exists a bug in the browser. So yeah, don't store social security numbers or credit card numbers in the cookie, but some sort of identifier is fine. In theory, the attacker could take control of the host machine, use that cookie to log in and then extract the credit card information through your interface, but at that point, there's not much you could do anyways. > > Thanks, > > Siegfried > > > > > > > -- Brad Lhotsky <[EMAIL PROTECTED]> -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
