Re: Best practices for database passwords

Hi,
A few methods I have used in the past...

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.

Hope this helps.

Regards Paul.

Comment on Re: Best practices for database passwords

Replies are listed 'Best First'.
Re^2: Best practices for database passwords by Limbic~Region (Chancellor) on Mar 22, 2005 at 20:49 UTC
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	[reply]
Re^3: Best practices for database passwords by thekestrel (Friar) on Mar 22, 2005 at 23:38 UTC
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	[reply]
Re^4: Best practices for database passwords by Limbic~Region (Chancellor) on Mar 22, 2005 at 23:45 UTC
thekestrel, My mother always tells me that locks are for honest people. By that she means a determined criminal won't be discouraged by a little security. With that said, there are very good reasons to not leave your doors unlocked. While there are ways to minimize threats, some risk must be assumed. When I said I didn't have a "good" answer I was indicating that I wasn't aware of a generic one-size-fits-all solution. Given a specific set of conditions certain choices make more sense then others as indicated by other responses in this thread and elsewhere. Cheers - L~R	[reply]