You don't find those best practices in Perl fora probably because they're the same best practices for any language.

I don't store that sort of information in the script: I make the script get it from somewhere else. Encoding rarely helps because the script is the recipe to decode it. How you decide to do that depends on your situation, but at some point the script ends up knowing all the secrets.

However, I do create several sets of passwords, and I give them different sets of permissions (read-only, insert-only, update-only, and so on) so that no script can do more than it should. Along with that, your database server may be able to limit access based on host or user names so that even discovery of the password doesn't complete the puzzle for the bad guys.

There is a lot more too it, but look for topics on web security rather than just Perl.

While everyone else is adding the way they do it ... I'll add mine. I don't store the password absolutely anywhere. The database I use allows (mandates) OS authentication for the database. So I can have the user that apache is running under authorised for the database, and then I don't have any password to give.

This has some drawbacks, but I'm not sure that for web apps that it's any worse than other solutions - sure, a co-hosted CGI app may be able to connect to the db as well, but then a co-hosted CGI could also grab the password from wherever I put it (encrypted or not). At least because I don't have a password to steal, no one can use the database other than as a co-hosted CGI app. (And, of course, there are no CGI apps co-hosted on any of my servers that aren't written by me or someone I trust.)

PS - the web user only has as much authority as is needed, definitely not the authority to grant authority to other users.

I'm surprised there isn't a 'security' category in the Q&A section, as this comes up for more than just database questions.

The way I have been doing it is encrypting and storing the username in one file, the password in another file, and placing both outside the public directory, and finally chmodded to 600.

I gleaned this from reading nodes like this one. But I have also come to the conclusion that there are probably no totally secure ways to do this.

1) Make it so you use the /etc/passwd file on a *nix system. This way you already have the file provided. The only issue is you may not want to create accounts for all the users if you are just wanting to provide passworded protection for say a web offered service that uses the database. You would also be able to take advantage of say password shadowing services through system level calls as well, so you didn't have to worry about people stealing and brute forcing your password file as much.

2) Another approach is to have another unprotected database that contains a table with the encrypted passwords for the users in them. That way if you are running more than one application you can have a separate table for each. This would also mean that the person on the outside world would only have access to checking the password through your script (unless they had shell access) so that would again help with not having the entire encrypted list nicked.

thekestrel,
Hope this helps.

I think you might have read something into the question that wasn't there. There wasn't any mention of user provided credentials. It isn't a matter of comparing hashed passwords. The question is if my script needs to generate report X and needs to connect to database Y to do it, how do I store the auth information to make the connection.

I don't have a good answer and am curious to see what other responses there are. When your script is proxying credentials for an external user there are plenty of ways to avoid storing in the clear passwords. This doesn't appear to be the case here. At least it was never stated the web user will be providing credentials (clicking on a button that generates said report).

Cheers - L~R

L~R,
I think I understand now, sorry for the mix up. I've hard-coded auth info before also, but that wan't very nice as you've found. I made a quick module at one time so at least my connections only went through one place for the password so I didn't have to have 10 scripts all with the info and it was only stored in one place, but you still have the password in a file, so you almost might as well not protect the Db, less relying on read priveleges.

Regards Paul