Re: Beta Testing a Robot

[Chuck Fox]

Casey,

I would like to chime in on the side of sending the search results 
directly to the poster.  In most cases, the poster is at the mercy of 
the search engine they choose. Whereas, you have the advantage of  
knowing where to search.  Please do not abandon this work.  A digest -- 
to which, one may subscribe -- of this activity may also prove useful in 
the long run to the lurkers like myself.

Thanks for the cool and interesting approach to getting an answer out to 
the questioner.

Chuck

[EMAIL PROTECTED] wrote:

It was Wednesday, December 03, 2003 when Casey West took the soap box, saying:
: I'm beta-testing a robot that searches Google when new questions are
: posed to the beginners' lists.  I have no idea if it will be useful.
: :-)
: 
: I'm going to watch it closely and hope it is.  I'll remove it if I
: find that it does a bad job.

Thank you for your timely and useful responses, they're under
consideration.  Until a decision has been reached (and re-coded), the
bot will be temporarily suspended.
 Casey West

 



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: How to secure database password? (was Re: Perl/DBI newbie: password storage / security question)

[Chuck Fox]

Zedgar,

You are chasing the yourself into circles.  Security is dictated by 
circumstances and resources available.  In our case, we had plenty of 
both and developed for our needs the "best" solution.  Insofar as the 
storing of the password for the login that is used to get the password, 
we took the approach of encrypting the passwords prior to inserting them 
in our password server and using the guest login to get the passwords 
(no password on guest).  So a user could login to our password server as 
guest and get the passwords for a server, however the data is encrypted 
and would require our decryption module to make sense of it.

Again, the point is that, "secure" has to be defined for your particular 
circumstances.  If it makes more sense for you to use the OS to protect 
passwords, then that is your "best" solution.

Good Luck,

Chuck

[EMAIL PROTECTED] wrote:

Hello,

Many thanks to R. Joseph Newton, Motherofperls, essential quint and Chuck Fox for answering my questions, however it is still not what I was asking about. My previous posts were long and maybe unclear so I'll try to get straight to the point this time, adding more details at the bottom of my post.

It is actually an extremely common situation: There is a CGI script written in Perl. It is a frontend to an SQL database.

The script has to connect to the database so it has to send a password. I need that password to be secure. I am not interested in security through obscurity. There are other websites on the web server and other users on the system.

My solution was using SUID wrappers giving my script an EUID of a system user having only one purpose: being the only member of the only group having read privilage to a file storing the database password. The disadvantage of this solution is the large number of system users and groups (few for every website/database) and corresponding database accounts (with the minimum set of privileges each).

I am quite new to Perl and particularly new to database programming, so I'd like to ask how all of you Perl gurus are solving that common problem of database password security. Is there any better solution than mine?

This problem is simple and common, but if there is any better place to ask this questions, I'd be grateful for pointing me there.

I have tried my best to find any related informations on the Web and Usenet archives, only to fail miserably. I will not believe that any sane person has passwords harcoded into the script itself on any production system, like it is suggested in every example of using DBI (which, as I assume, is done only for the sake of the examples simplicity).

For more datails of my original questions and reasoning see:

Date: Sat, 13 Sep 2003 05:09:58 -0500 (EST)
Message-Id: <[EMAIL PROTECTED]>
http://www.mail-archive.com/beginners%40perl.org/msg46845.html
Date: Sat, 13 Sep 2003 21:25:55 -0500 (EST)
Message-Id: <[EMAIL PROTECTED]>
http://www.mail-archive.com/beginners%40perl.org/msg46856.html
I was trying to be very clear this time, moving the most important informations to the top of my message, so everyone could know what I mean before getting lost in the details of my own reasoning. And now some details:

Joseph, I was asking about database password, not password database, but speaking about the latter, I would never use a self-made custom hashing algorithm you suggested, nor would I buy any third-party RSA encryption application for that matter.[1] Also, this is not true that the hashing algorithm is any more secure as a compiled object.[2]

Quint, I was not wondering whether to use RDBMS or flat files, but there are ways to make working with flat files equally convenient.[3] Of course I use HTTPS for client connections, so the users' passwords are safe in transit.[1] I use CPAN modules for everything I can and I make sure my own scripts themselves are written with security in mind.[4]

Quint, you say that the argument againts flat files is that they have to be writable by the httpd process EUID, but then you propose embedding the RDBMS password in the script or module instead (readable by the server process), which essentially makes the whole database world-writable (as anyone with read access to the script or module, like everyone exploiting any other CGI script on the system, can gain full access to the database), which is absolutely unacceptable for any multiuser system connected to the Internet.

Chuck, your solutions of storing the password in another database,[5] or moving the password outside the script[6] don't solve the problem, but only move it to someplace else, where it is still unsolved, not improving the security at all.

Zedgar.

Footnotes:

[1] About the security of users' passwords: See Digest::* modules on CPAN for hashing digests. I use Data::Password::BasicCheck, Data::Password and Crypt::Cracklib (in that order) with good dictionaries to make sure the user'