Removing passwords from the conf file

[Daniel Ruggeri <DR...@primary.net>]

In mod_ssl there is a very handy option of making an exec callout for 
SSLPassPhraseDialog rather than to put a password for your private key 
in the conf file. The obvious benefit here is that one can then design a 
solution to meet any arbitrary number of security challenges before 
allowing that password to be delivered.

One of my TODO patches is to add this same functionality in other 
places. The first that comes to mind (and something that has pestered me 
in the past) is AuthLDAPBindPassword (mod_authnz_ldap). Would anyone 
like to suggest other potential places this should be done before I put 
together a bug report and send in a patch?

P.S.
I am opposed to mod_ssl's check that the argument to SSLPassPhraseDialog 
exec:blah is a file. This prevents calling an arbitrary executable with 
parameters. Thoughts?

-- 
--
Daniel Ruggeri

Re: Removing passwords from the conf file

[Daniel Ruggeri <DR...@primary.net>]

On 11/21/2010 2:38 AM, Stefan Fritsch wrote:
> On Sat, 20 Nov 2010, Daniel Ruggeri wrote:
>
>> In mod_ssl there is a very handy option of making an exec callout for
>> SSLPassPhraseDialog rather than to put a password for your private key
>> in the conf file. The obvious benefit here is that one can then design
>> a solution to meet any arbitrary number of security challenges before
>> allowing that password to be delivered.
>>
>> One of my TODO patches is to add this same functionality in other
>> places. The first that comes to mind (and something that has pestered
>> me in the past) is AuthLDAPBindPassword (mod_authnz_ldap). Would
>> anyone like to suggest other potential places this should be done
>> before I put together a bug report and send in a patch?
>
> Company policies that require passphrases not to be stored in plaintext
> are not that uncommon. Therefore I agree that having a generic
> functionality to be used by modules is a good thing.
>
> But IMHO the documentation should be much clearer that this is only
> security by obscurity and improves security only in some very limited
> areas.
Understood and agreed - I will need to update documentation anyway to 
add this functionality and will be willing to drive this point home a 
little better.

>
> An attacker who is root on the machine that is running HTTPD can still
> get the ssl keys. Either by creating a core dump and extracting the keys
> from that (there are tools that do this), or, if the passphrase dialog
> yields the passphrases without human interaction, by starting HTTPD
> under strace/truss.
Another very valid point - if an attacker has root, you are screwed in 
any event.

>
> The only valid use case I see for this feature is to prevent unencrypted
> ssl keys from going into the normal backup (if the file with the
> passphrases is excluded and is instead backed up on paper). Are there
> more valid use cases?
I stewed on this question for a while because I was *sure* I had a good 
answer somewhere in my gray matter... but no, I can't really come up 
with a solid response to this. If your server admins are putting the 
password somewhere safe and using proper file system permissions to 
prevent that information from being shared, it's all the same.

I suppose the ideas behind the policies you mention surround the fact 
that sometimes people will screw up file system permissions and users on 
the host for other purposes (content managers, appserver admins, etc) 
could see the password. Or, worse yet, your application is coerced into 
reading arbitrary files from the file system. With this in hand, it 
allows the security teams as much obscurity as they could fathom.

--
Daniel Ruggeri

Re: Removing passwords from the conf file

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 11/21/2010 2:38 AM, Stefan Fritsch wrote:
>>
>> One of my TODO patches is to add this same functionality in other places. The first that
>> comes to mind (and something that has pestered me in the past) is AuthLDAPBindPassword
>> (mod_authnz_ldap). Would anyone like to suggest other potential places this should be
>> done before I put together a bug report and send in a patch?

Oh - I'm very happy if you would like to patch mod_info/mod_auth_ldap to obscure such
details from the mod_info output :)

Re: Removing passwords from the conf file

[Stefan Fritsch <sf...@sfritsch.de>]

On Sat, 20 Nov 2010, Daniel Ruggeri wrote:

> In mod_ssl there is a very handy option of making an exec callout for 
> SSLPassPhraseDialog rather than to put a password for your private key in the 
> conf file. The obvious benefit here is that one can then design a solution to 
> meet any arbitrary number of security challenges before allowing that 
> password to be delivered.
>
> One of my TODO patches is to add this same functionality in other places. The 
> first that comes to mind (and something that has pestered me in the past) is 
> AuthLDAPBindPassword (mod_authnz_ldap). Would anyone like to suggest other 
> potential places this should be done before I put together a bug report and 
> send in a patch?

Company policies that require passphrases not to be stored in plaintext 
are not that uncommon. Therefore I agree that having a generic 
functionality to be used by modules is a good thing.

But IMHO the documentation should be much clearer that this is only 
security by obscurity and improves security only in some very limited 
areas.

An attacker who is root on the machine that is running HTTPD can still get 
the ssl keys. Either by creating a core dump and extracting the keys from 
that (there are tools that do this), or, if the passphrase dialog yields 
the passphrases without human interaction, by starting HTTPD under 
strace/truss.

The only valid use case I see for this feature is to prevent unencrypted 
ssl keys from going into the normal backup (if the file with the 
passphrases is excluded and is instead backed up on paper). Are there more 
valid use cases?

Re: Removing passwords from the conf file

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 11/20/2010 4:05 PM, Daniel Ruggeri wrote:
> In mod_ssl there is a very handy option of making an exec callout for SSLPassPhraseDialog
> rather than to put a password for your private key in the conf file. The obvious benefit
> here is that one can then design a solution to meet any arbitrary number of security
> challenges before allowing that password to be delivered.

The right way to solve this is an 'Include secrets.conf' where secrets.conf is 600
owned root/root.

> P.S.
> I am opposed to mod_ssl's check that the argument to SSLPassPhraseDialog exec:blah is a
> file. This prevents calling an arbitrary executable with parameters. Thoughts?

Agreed, patch warmly welcomed.  Same with the actual keys and certs, which might
be fetched via a named pipe or similar.  -f is evil in these cases.