If you're just trying to prevent the casual user from seeing the password and then connecting to your db another way, a better approach is to lock down on the database server side. Create a stored-proc (or a view) that returns (or contains) just the data the script would return. Then grant your script user permission to access just that stored-proc (or view).

Trying to lock down the script is just not the right approach. Even if it was compilied (and the binary fit your size reqs), It would be in the text area of the binary (accessible via strings). You could obfuscate it but it will still go out on the wire unencrypted (unless you're going to encrypt the wire to).

If it's a web script, don't worry about it. Ensure your db is properly secured (ala para 1) and your web server is properly secured and your firewall is properly secured (all your onion layers) and just embed the password in the script. If everything is correct, just the web user would be able to read it and only your admins could become the web user.

If it's a regular script and you don't want to go to para 1 lengths, you could set up a pki infastructure but that's going to be way more time consuming.

-derby

Update: FoxtrotUniform Good idea but I think the interface to the mysql connect needs the cleartext password (and even if it just needed the hash, you'd still have a problem cause then all I'd need is the hash - same problem different format).

The best I've come up with is to restrict rights to who can view the source of your program, which works pretty well if your program is run only by a few users. However, if you're doing CGI, and your CGI has to talk to the database, well, then your password has to read-able by God and everyone. In such cases I've moved database connection information out of the path of the webserver (and then use'd or require'd it in) which helps a little, but still, global read access makes me nervous.

If anyone has any techniques or thoughts I, too, would like to hear them.

Gary Blackburn
Trained Killer

1. Lock down the database - create views that only allow access to the required data. the user should have select only on the specific areas required (and create session.. ;-) )
2. Passwords may be stored in a 0400 file readable only be the user that executes the script _or_ embed the password in the script, either way if the user is hacked the password can be gained. I personally prefer to embed the passwd in the script as it doesnt make an extra IO. (as always there are pro's and con's)
3. Lock down the machine, make sure the security on the server (users, host.deny|allow et al) are all up to date.
4. Lock down the server ie, make sure no directories are visible, and make sure you've got the latest patches.
5. Consider SSL, better send sensitive data over the wire encrypted than plain.
6. Consider seperating you DB from you WS, on a private network, and having only essential machines access it.
7. Consider a vpn between the DB and the WS.

HTH, and good luck!

I think the Unix approach is particularly elegant.

Don't store the password in plaintext, store the result of running the password through a one-way hash function. Then for authentication, instead of comparing cleartext, hash the candidate password and compare the hashes. You can use the crypt builtin, but if you're really concerned about security you're probably better off looking through the CPAN Crypt namespace.

Update: One thing that I forgot to mention, that derby brought up and is damn important, is that sending the password over the wire in cleartext is a Bad Thing(tm). If this is a client/server app, do authentication at the client or tunnel through SSH. If this is a web app, use SSL. You get no points for security if someone can sniff the username/password pair off the network, regardless of how well you hide the passwords.

Update 2: I just realized how useless this answer is to the original question. *sigh* Of course the password needs to be in cleartext for the DB to read it, and of course it's not going to be going over the wire. (And it was such a nice little rantlet on password security, too.) Sorry, AM.

--
:wq

I dealt with this problem a while back, and posted some advice here.

Bottom line: Keep all passwords off of the web server, and connect to the database through custom proxy (or middle tier) that doesn't allow raw SQL.

Check out theObfuscated Code section. As long as you make your password 'just another perl hacker' you should be set.

<grin>