r.joseph has asked for the wisdom of the Perl Monks concerning the following question:
Hello! I am currently working on an online database of medical reports for an occupational health company. My work requires that I create a login page (without .htaccess, they want it all CGI) for the users to log in, and then store sensitive medical data on a non-secure server securely (oxi-moron I know, but they won't shell out the green to pay for a secure server).
What I want to ask is what systems have my fellow monks come across or created or think would work for 1) creating secure logins via pure CGI/Perl and 2) creating a system that can securely store data in a non-secure environment, preferably via flatfile?
I was thinking of encoding or encrypting the data in the database, which might work alright. But for the login, I am stuck...would using MD5 password a la /etc/passwd do suffciently? Please, fellow monks, help me out here. This is a big project for me and I would like to do it correctly. Thanks!
R.Joseph
Re: CGI Password/Login and Security
by swiftone (Curate) on Jan 12, 2001 at 02:11 UTC
|
1) a secure server doesn't have to cost money, if you stick with open source projects and don't get a signed certificate. (signed by the Big boys (Verisign) at least).
2) Don't use /etc/password with the web at all. If you don't have an SSL connection, that userid/password is sent in plaintext, and could give any blackhat the info to login to your box via that account. Update: oh, you meant LIKE /etc/password. Yeah, you could do that, but again, without the encrypted connection it's not secure. (You'll be as secure as telnet)
3) Without an ecrypted session, there's no way to guarantee the security of the data. You can encrypt the data, but either you use something on the box side as the key, or you use something user-provided.
| [reply] [Watch: Dir/Any] |
Re: CGI Password/Login and Security
by ichimunki (Priest) on Jan 12, 2001 at 02:53 UTC
|
Just noticed CGI::SecureState in the CPAN nodelet. Might be worth a look. I also think that you should take a look at Free implementations of SSL (even if they generate certificate warnings at the browser). Your data is not safe if it leaves the server in an unencrypted form. If these reports are something the company would shred (for data sensitivity reasons) before disposing of them, then they should be encrypted during transmission. | [reply] [Watch: Dir/Any] |
Re: CGI Password/Login and Security
by chorg (Monk) on Jan 12, 2001 at 02:29 UTC
|
My two cents:If you are going to use a flatfile, then you have a choice between a DBM file or an XML file. I'd go with XML - then you have all of the Perl XML toys to play with. Store the file outside of the web tree. You could also use DBM files, which are binary, but I don't think that they are encoded. For the CGI access, you could use HTML::Embperl - it does not require mod_perl to run, you apparently can use it from CGI, and parse the XML file for what you needed. Hell, you could even try using XML::DOM and XML::XQL to query your data (spend the $120 on an extra stick of RAM). You might want to MD5 the password. Not the most efficient solution, but if you can't use .htaccess, or mod_perl, then that should work.
_______________________________________________
"Intelligence is a tool used achieve goals, however goals are not always chosen
wisely..." | [reply] [Watch: Dir/Any] |
Re: CGI Password/Login and Security
by Albannach (Monsignor) on Jan 12, 2001 at 03:23 UTC
|
< security rant >
There has already been lot of good advice on this so I'm
going a bit OT here to suggest that you make sure your
client (employer?) knows the risks of going without a secure server.
Why is it that many (most?) companies think security is a frill? Even
if they don't care a whit about their patients' privacy, have they done
a financial risk assessment to check the costs
of security measures against possible legal action? Are they certain that their insurer
will cover them for something like this? Will they come after you is something
goes wrong? If so, then give them your warnings on paper and try to get them
to sign off on it if you can.
Some may also find the new law in Canada of interest.
I very little idea what the U.S. is doing in this area (and from
what I read in the Risks Digest it seems not much) but sooner or
later people will demand privacy and dealing with it now is
better IMHO.
--
I'd like to be able to assign to an luser | [reply] [Watch: Dir/Any] |
|
Well if the docters can choose between spending the money on my privacy or my health then I say HEAL ME!
But since most docters earn a whole lot of money, I don't think it's too much to ask for a decent frickin' server (some hosting companies even offer you their SSL certificate with virtual server accounts!)
Speaking of SSL, anyone know the best way to set up an encrypted connection? (for a P2P filetransfer)
-CBAS
| [reply] [Watch: Dir/Any] |
Re: CGI Password/Login and Security
by ColonelPanic (Friar) on Jan 12, 2001 at 02:21 UTC
|
Without a secure server, the best you can probably do is use the crypt(); function to encrypt the password. Have an encryption for a password stored in a file with permissions set as strictly as possible. Keep in mind, the login and password are still being sent through the wires unencrypted though. That is the cost of an unsecure server.
#don't name it $password in real life!
my $crypted = $crypt($password, $key);
open (PASSWORD, ".somefile") or die "login failed";
if ($crypted eq <PASSWORD>)
{ let them in }
else { don't let them in }
This code is untested and for example purposes only. | [reply] [Watch: Dir/Any] [d/l] |
Re: CGI Password/Login and Security
by r.joseph (Hermit) on Jan 12, 2001 at 02:35 UTC
|
Thanks for such a quick and awesome response already!! Monks are great!
Two things: Could someone explain exactly what a DBM file is? And also, if I was to encrypt the data file, what would be your suggestions on the best method of doing this?
Thanks again!
R.Joseph | [reply] [Watch: Dir/Any] |
|
a DBM file is a file format that stores a database. There's all sorts of man pages about it, both in and out of the perl docs. THey're useful in perl because you can tie them to a hash, which makes reading/writing very convenient.
As to how to encrypt the data, the "best" way depends on many things, mostly having to do with how big the data is, how often it is accessed, etc.
| [reply] [Watch: Dir/Any] |
|
|