> 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 :) >
I second this, *please* use something other than Access. <snip> > > > > > > > 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. > I don't understand how you are using this info? The process id number would change between requests, as might the IP address (think proxies). I wrote up a fairly common idiom in a previous message to this list, it goes like such: "Generally the idiom goes something like, create a private key (aka a passphrase or something that no one else knows), take the key and some reproducible non-private information (such as the user name/id) and hash the two together. Provide the hash, and the information used to create it (NOT the private key!) in the cookie. Then during the requests check to see if the information provided back by the user from the cookie can be used to reproduce the same hash using the same private key as before. If the hash is reproduced then the user is authenticated. Assuming no one else has the private key, then the hash should be unique for the user and the private key should be non-guessable from the hash, generally if this holds an attacker can't produce a string that will authenticate correctly. In general using the IP address in this is not a good idea unless you know precisely what IP a particular user is going to come from. The complexity of your hash inputs can vary what you can do, aka adding expirations, etc. I don't take credit for this, the idiom is yanked from the Writing Apache Modules with Perl and C book from ORA, it provides an excellent discussion as well as code samples of how to implement this." Also not sure about the double MD5, are you positive that doesn't introduce a vulnerability, by MD5ing a hash you seemingly have reduced its power since it is a hash of a relatively short string which could definitely be brute forced very quickly? I would skip MD5 completely and go with SHA-1 (although there are recent concerns about it), and would definitely double check hashing a hash with an encryption expert before doing it. > > > > > > 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. > Agreed. > > > > Thanks, > > > > Siegfried > > > -- > Brad Lhotsky <[EMAIL PROTECTED]> > http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
