Re: Securing your scripts on webhoster's server

As the poster mentioned in the first line of b10m's OP, I find this an interesting follow-up. Asking for user and password obviously wouldn't work for database-driven sites where content is being served up for any number of anonymous visitors.

And as I mentioned in my my reply to b10m, I'm trying to avoid hardcoding the DBI connect info into the scripts, just to make it more transportable.

What's the feeling around the monastery towards encrypting sensitive info somehow? Encrypt it when it is put into the text file, and decrypt in the scripts connecting to the DB. Maybe this falls into the realm of "security through obscurity" (still relatively new to Perl, I'm not even sure if descent codable encrytion exists).

It will be interesting to see how other monks weigh in on this one.

Update: After a Saturday of researching, I have started encrypting my DBI log-ons with Crypt::CBC. Yes, it does use a key which I plan to store in a SSL protected directory on the host's server (they offer a shared certificate for $1/mo). That's the best I can hope for now.

Update 2: My host said storing my key in a SSL protected directory won't gain me a thing. They did suggest chmoding a file with my key to 600 and putting it into the root, outside all web folders.

—Brad
"A little yeast leavens the whole dough."

Comment on Re: Securing your scripts on webhoster's server

Replies are listed 'Best First'.
Re: Re: Securing your scripts on webhoster's server by stvn (Monsignor) on Feb 01, 2004 at 04:26 UTC
But what do you do about the key? I have been trying to figure out a similar construct for our sites, but if you encrypt your data with a two-way algoritm, you will need a key to decrypt it. The question then becomes, where do i put that key. One option we are (sort of) considering is that the server will not restart without a user entering a pass-phrase that the server startup script then uses as the key for decryption. The obvious problem is that if the server goes down at 2 a.m. (U.S.) EST, then none of us are going to know about it until 9 the next morning. Many of our applications are deployed globally, so this just wont work. Right now we keep the DB username/password in a single file stored outside of the web accessable directories, and since we are always on a dedicated server (or Virtual Private Server) its reasonably secure. In the end, it really comes down to the clients security needs too, some care more than others. -stvn	[reply]

Replies are listed 'Best First'.

Re: Re: Securing your scripts on webhoster's server
by stvn (Monsignor) on Feb 01, 2004 at 04:26 UTC

But what do you do about the key? I have been trying to figure out a similar construct for our sites, but if you encrypt your data with a two-way algoritm, you will need a key to decrypt it. The question then becomes, where do i put that key. One option we are (sort of) considering is that the server will not restart without a user entering a pass-phrase that the server startup script then uses as the key for decryption. The obvious problem is that if the server goes down at 2 a.m. (U.S.) EST, then none of us are going to know about it until 9 the next morning. Many of our applications are deployed globally, so this just wont work.

Right now we keep the DB username/password in a single file stored outside of the web accessable directories, and since we are always on a dedicated server (or Virtual Private Server) its reasonably secure. In the end, it really comes down to the clients security needs too, some care more than others.

[reply]