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

[zedgar@despammed.com]

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: <200309131009.FAA25385@gen.by.despammed.com>
[url]http://www.mail-archive.com/beginners%40perl.org/msg46845.html[/url]

Date: Sat, 13 Sep 2003 21:25:55 -0500 (EST)
Message-Id: <200309140225.VAA25344@gen.by.despammed.com>
[url]http://www.mail-archive.com/beginners%40perl.org/msg46856.html[/url]

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.

[Dan Anderson]

I think you're complicating an already quite simple thing.

1. Most major databases support permissions. Use these liberally to
seperate those who only need access to the database to view contents on
a single table and those who should be able to alter one table or one
database and ONLY that table/database.

Fixes: People from looking at, or modifying things which are not theirs.

2. Throw scripts with passwords in them (i.e. $password = 'foo') into a
directory which has the following properties:
a. it is readable only by the owner of the script, directory, and the
scripting language.
b. it is not writable by anybody but the owner.
c. it has an .htaccess file or is dissallowed access without a
password using an Apache directive in the main Apache config file.

Fixes: Several things:

i. Random users on the server who have shell access can't just:
$ less ./script
Nor can they:
$ cd ./directory
Unless they *have a reason* to.
ii. Even users who have access to the cgi-bin directory don't
necessarily have access to the directory to the script's directory. So
they can just tell the program to execute the file but not read it.

(Note: I think clever users could figure out a way to read in the
script. Perhaps you could make the script executable only, or nested --
i.e.:

#! /usr/bin/perl

`./protected_dir/script`

)

3. Tell the database to only accept connections from localhost (or
127.0.0.1 -- or the domain names you need to access it)

Fixes: Let them get the password. If they're not on the right IP
address (which they obviously won't be if they don't have access in the
first place). To prove the point to you try accessing the mySQL
database on mathjunkies.com with username: perlbeginner password:
beginner and database: perlbeginner . It won't work. Why? Because
mathjunkies.com (my server) only accepts connections from localhost.

4. Run the database on a port or socket other then it's default.

Fixes: Any script kiddies port scanning your server won't be able to
readily identify the port on your server's function. (Of course any
bonafide hackers could probably figure out its function by watching the
traffic into and out of the port, or something similarly clever -- but
that's a different issue)

5. Encrypt database transmissions -- mySQL, and Postgresql, (and
probably Oracle and some others) allow you to use SSL certificates to
keep your transmissions private. Use them if you plan on accessing the
database from anywhere other then localhost.

Fixes: Anybody sniffing your packets will get garbage.

All of this stuff is fairly basic and outlined in the various manuals of
the respective programs I have mentioned. It won't make you
impenetrable -- but it will go a long way towards making your box
secure.

-Dan