If you're connecting to Oracle from Unix, you can make use of a handy Oracle feature called "ops id" (Oracle Parallel Server ID) -- which allows you to log on to Oracle using "/" as your username/password -- provided that your Unix logon name is the same as your Oracle name (passwords need not be the same). I don't know what's required to set it up and I don't know if other RDBMS's have a similar feature: those are questions for your DBA.
Tim -----Original Message----- From: Dave Feinberg [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 4:05 PM To: [EMAIL PROTECTED] Subject: RE: security and dbi 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
