Securing /opt/rt3/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm

Hello,

what are our options as far as securing RT_SiteConfig.pm goes?

My company has pretty strict security requirements, and our security team
will simply not allow us to store the ldap username/password in a plain
text file on the RT server (and I can fully understand their concerns).

What are some options here? Again, keeping in mind that the requirement is
for the password (at least the password, that is) to NOT be plaintext in
RT_SiteConfig.pm

Solutions like “well make the file only readable by root” aren’t going to
be accepted (not by me, but by our security team). Needs to be a hashed
password, may be, or something… I don’t know… soliciting ideas.

–Val

Hello,

what are our options as far as securing RT_SiteConfig.pm goes?

My company has pretty strict security requirements, and our security team
will simply not allow us to store the ldap username/password in a plain
text file on the RT server (and I can fully understand their concerns).

What are some options here? Again, keeping in mind that the requirement is
for the password (at least the password, that is) to NOT be plaintext in
RT_SiteConfig.pm

Solutions like “well make the file only readable by root” aren’t going to
be accepted (not by me, but by our security team). Needs to be a hashed
password, may be, or something… I don’t know… soliciting ideas.

–Val
How are you storing the database userid and password in that case?

Jeff

Plaintext.

But that doesnt matter - because its a RT db, with nothing else on it.
Security has no problem with it.

They only have a problem with storing the domain account credentials in
plaintext.

–Val> On 09/15/2010 12:52 PM, Val Polyakov wrote:

Hello,

what are our options as far as securing RT_SiteConfig.pm goes?

My company has pretty strict security requirements, and our security
team
will simply not allow us to store the ldap username/password in a plain
text file on the RT server (and I can fully understand their concerns).

What are some options here? Again, keeping in mind that the requirement
is
for the password (at least the password, that is) to NOT be plaintext in
RT_SiteConfig.pm

Solutions like “well make the file only readable by root” aren’t going
to
be accepted (not by me, but by our security team). Needs to be a hashed
password, may be, or something… I don’t know… soliciting ideas.

–Val
How are you storing the database userid and password in that case?

Jeff

RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year – Learn how to get the most out of RT!

Any thoughts, anyone ?

Solutions like “well make the file only readable by root” aren’t going to
be accepted (not by me, but by our security team). Needs to be a hashed
password, may be, or something… I don’t know… soliciting ideas.

When people talk about hashes, they are typically talking about
one-way functions. You can tell if two passwords hash to the same thing,
but can’t typically reverse a hashed password into usable credentials.

Have you tried asking your security people for recommendations? Presumably
they have a way they’d like you to do this.

Val Polyakov wrote, On 9/15/10 3:51 PM:

Plaintext.

But that doesnt matter - because its a RT db, with nothing else on it.
Security has no problem with it.

They only have a problem with storing the domain account credentials in
plaintext.

I’m not sure that it will satisfy the people you are trying to satisfy, but
we stay as safe as possible by using an LDAP account that has restricted
read and search access and no write permissions. That account is only used
to do an initial bind, search for a user by the attributes in
attr_match_list, and read the attributes in attr_map. It needs no other
rights in LDAP. After that, actual user authentication is done with a bind
attempt using the found account DN and the password provided by the user.

The way your question is worded makes it seem like you are trying to use
some sort of unique high-privilege account, which would be an unnecessary
and unsafe approach. The limited-account approach works for us because the
attributes it can search and read are significantly less than what any of
our human users can search and read. The added risk of that account password
being in the clear in a file that can only be read by ‘root’ and ‘www’ on a
system that has only admins as human users is insignificant. But of course,
that is our environment, and yours may be a lot different.