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's new password itself is secure enough (to users having problems with hard-to-guess passwords I recommend Password Safe, either the original Bruce Schneier's Counterpane Labs version, or the new one available on SourceForge). The password is stored in the database as a SHA-512 digest of the password salted with other data, as well as a large random number also stored in the database (Crypt::Random).
[2] Having the hashing algorithm compiled to a native binary object improves performance, but not security (for an example see Digest::Perl::MD5 and Digest::MD5).
[3] See DBD::CSV and DBD::AnyData modules for DBI interface to flat files with simple SQL queries (processed by SQL::Statement). It's great for quick prototyping, but quickly gets slow for larger files. What I personally prefer for prototyping and for any situation when there's no access to SQL database on the server, is DBD::SQLite. It's a DBI Driver with embedded SQLite, a simple RDBMS, which is fast and supports transactions with atomic commit and rollback.
[4] I use CGI.pm for parsing input, I use the taint mode, I verify every input variable with appropriate CGI::Untaint subclasses and also I use the DBI placeholders for autoquoting to make sure there's no possibility of SQL injection even if the input validation step fails. I also use CPAN modules for password strenth tests and hashing digests.[1]
[5] Using another database to store the password to the first one answers the question of the first database password security, but introduces a problem of the second database password security. This password cannot be stored in a third database, etc. ad infinitum. It is pointless from the security standpoint.
[6] Subclassing DBI or patching perl itself also doesn't improve the security, but merely introduces lots of obscurity and obfuscation. It doesn't matter if my code with hardcoded password is a CGI script, a module (subclassing DBI or otherwise), or a patch of perl interpreter itself. It's still part of my code and I have to take full responsibility for any security flow I introduce there.
Thanks, -Zedgar.
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
