Re: hiding username/password in database scripts

in reply to hiding username/password in database scripts

Thanks for all the help. Sorry I didn't do much searching beforehand.

My main focus, I should have said, is the less clueful user. I'm trying to create a script which anyone can drop in quickly and use with minimal setup.

And this is presumably the reason why MT did it that way? What happens if you use the DBD approach mentioned above, but you can't trust your users to know how to set permissions correctly? Is their approach a bit kludgey, but justifiable in the context of security for people who don't understand security?

I'm still not sure how the bad guys could get my username and password if I have it in a regular CGI script and don't use CGI::Carp or anything which would give out error specifics to a browser.

Nobody says perl looks like line-noise any more
kids today don't know what line-noise IS ...

Comment on Re: hiding username/password in database scripts

Replies are listed 'Best First'.
Re^2: hiding username/password in database scripts by WoodyWeaver (Monk) on Jan 14, 2008 at 00:03 UTC
I'm trying to create a script which anyone can drop in quickly and use with minimal setup... What are they protecting against by going to all that trouble as opposed to just putting it in the script? Because you want to maximize convenience and aren't greatly concerned about security, you should ensure your system is robust first. Then it is pretty easy to apply enough security to keep honest people honest -- by splitting the secret into two parts kept in separate locations. Movable Type's is the most honest, where the two parts are in easily read files. "hiding database passwords" had some similar sentiments (I actually like the very last idea, about storing it on a removable token that is used for boot.) The "Balancing two conflicting passwords" approach was to have the separation virtual, where the password is encrypted against a token associated with the script. None of these will protect against malice without additional controls, but that isn't the point here if the extracts are correct. If malice or non-repudiation is an issue, there are other things. Physical token plus operational controls can work, and there are technical controls with password servers and the like, but they are overkill for the kind of problem you describe, impo. (I play an IT Security Architect on TV.) --woody	[reply]

Replies are listed 'Best First'.

Re^2: hiding username/password in database scripts
by WoodyWeaver (Monk) on Jan 14, 2008 at 00:03 UTC

I'm trying to create a script which anyone can drop in quickly and use with minimal setup...
What are they protecting against by going to all that trouble as opposed to just putting it in the script?

Because you want to maximize convenience and aren't greatly concerned about security, you should ensure your system is robust first. Then it is pretty easy to apply enough security to keep honest people honest -- by splitting the secret into two parts kept in separate locations. Movable Type's is the most honest, where the two parts are in easily read files. "hiding database passwords" had some similar sentiments (I actually like the very last idea, about storing it on a removable token that is used for boot.) The "Balancing two conflicting passwords" approach was to have the separation virtual, where the password is encrypted against a token associated with the script. None of these will protect against malice without additional controls, but that isn't the point here if the extracts are correct.

If malice or non-repudiation is an issue, there are other things. Physical token plus operational controls can work, and there are technical controls with password servers and the like, but they are overkill for the kind of problem you describe, impo. (I play an IT Security Architect on TV.)

--woody

[reply]

In Section Seekers of Perl Wisdom