hmmm interesting. I agree with you and our previous writer. And as
i replied, i would like to make it a little more difficult. What you
suggest however makes good sense. Permissions are important. If you put it
all in one file, it is 1) easier to change when the password changes, 2)
easier to deal with permissions (you only need permissions on one file), and
3) only 1 file to encrypt should we go that route. Thanks for the
suggestions.
-Dave
-----Original Message-----
From: Mr. Sunblade [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 11, 2001 3:56 PM
To: Dave Feinberg
Cc: [EMAIL PROTECTED]
Subject: Re: security and dbi
Dave Feinberg wrote:
> ok this is a different ball of wax altogether :-) We do use
> ssh
> instead of ftp to prevent network sniffing of data, but i am not even
> looking at this yet how to prevent someone from sniffing the connection
> and
> stealing stuff. We use oracle. But that is an interesting link thanks.
> We
> will have to solve this problem eventually as well, but for now we are
> presuming it is all on an internal net so it is pretty secure in that
> regard.
> -Dave
Dave,
Well, you have to accept the fact that if they can access your scripts,
they can ultimately get the login/password information. In other words, if
they've got root access, you're effed anyway.
That being said, you can avoid sniffing by non-root users using any of the
following simple techniques:
1) Permissions. Make all executables 700 and non-executables 600 for the
userid in question (assumes *nix style perms).
2) A resource control file. I often use the .netrc file as a double for
login/password info for DB stuff. There's even a handy Perl interface
(called Net::Netrc). This keeps login/password info out of the calling
script and provides enough security to keep any "accidents" from happening.
3) A continuation of 2, really. Encrypt the resource control file and
decrypt it programatically. Once again, however, if they can read your
calling script, they'll ultimately be able to decipher the control file,
too.
All it really boils to is "how tough do you want to make it"? Just
remember - if someone has root access on your client/server, DB access
violations are probably going to be the least of worries, considering they
could wipe out everything anyway.
Regards,
Mr. Sunblade
