Well depending on what the scripts do, they don't necessarily have
to run as root. Ideally they don't whenever possible but obviously
sometimes it is necessary. And yes of course if someone were to get root
access, that pretty much seals the deal, it is indeed very bad. But as you
said, it is a bit unnerving that the passwords are just sitting in there.
You know how security goes, it is just basically how hard can you make it.
And while someone may compromise the machine, or they may need to use that
account for something else, but they may not necessarily need database
access, i'd rather not scrawl the passwords on the bathroom wall so to
speak. Make it at least difficult enough so the merely curious do not trip
over it, that someone has to work a little to put together a database,
username, and password :-)
-Dave
-----Original Message-----
From: Moritz von Schweinitz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 11, 2001 3:49 PM
To: 'Dave Feinberg'
Subject: RE: security and dbi
if it's a maintanence-script, i guess it runs as root, right?
so if it's only readable as root, then i don't get the problem, since if
anyone somehow gets unallowed root-access to the machine, you're screwed
(pardon my french) anyhow.
but i'm actually kinda looking for a nice solution too: i'm using a
standard LAMP-combination, and i simply don't like the fact that
("castrated", i.e. highly restiricted) passwords are lurking in my
cgi-scripts.
anybody now if there's a way around this (except giving user
wwwrun@localhost access without passwords), please help,
M.
> -----Original Message-----
> From: Dave Feinberg [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 11, 2001 2:39 PM
> Cc: [EMAIL PROTECTED]
> Subject: RE: security and dbi
>
>
> well this makes sense of course narrowing it down only
> giving accounts access to what they need but we have scripts
> that run at 3am from the cron demon, so i can't be there to
> type in passwords. obviously the most secure (aside from
> locking a computer in a room with no network connection and
> no removable drives) is to have the password in someone's
> head. But i can't do that so i am looking for the next best
> way to 1) prevent someone from reading a perl script and
> accessing our database (of cours emodifyign it is worse than
> reading it, but if it is sensitive information reading it is
> still unacceptable) and 2) making it easier to modify thses
> scripts when we do change a password (ie having them all read
> it or use code in a central location, that we carefully
> monitor and limit access to).
> -dave
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 11, 2001 3:26 PM
> To: Dave Feinberg
> Cc: [EMAIL PROTECTED]
> Subject: Re: security and dbi
>
>
>
> Being a newbie I am not sure what I am doing is the best way
> BUT it works for us. I create accounts with ONLY the access
> the accound needs. I have no 'system wide' accounts. If the
> username/password is used for reporting (as most of mine are)
> they get only the ability to read data not modify it. If the
> user (script) needs to modify it, I have the user enter a
> password. I use this as an audit trail.
>
> My $0.02.
> Vince
>
>
>
>
>
> Dave Feinberg
>
> <DFeinberg@ClubMo To: [EMAIL PROTECTED]
>
> m-inc.com> cc:
>
> Subject:
> security and dbi
>
> 12/11/01 02:26 PM
>
>
>
>
>
>
>
>
>
> I have a security related question. How does one
> deal with database security such as connect usernames and
> passwords in plain text perl scripts? Obviously encoding them
> directly into the scripts is not optimal. This also makes it
> difficult to alter all these scripts if you need to change a
> password. Considerations are to use perl bytecode, and then
> the passwords are harder to get. Or possibly to store them
> encrypted and then read them in, but of course then they can
> always be decrypted if some can access the computer. Really
> i think ultimately the answer is you are relying on the
> security of the physical machine. But atleast having them in
> one place makes it easier if you change them. Just curious
> about what your thoughts might be, what is the most effective
> solution you have found for the amoutn of work it takes.
> -Dave
>
>
>
>
