accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2464) Trace user password required in plaintext in accumulo-site.xml
Date Wed, 12 Mar 2014 23:47:42 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13932663#comment-13932663
] 

Christopher Tubbs commented on ACCUMULO-2464:
---------------------------------------------

I fear that any attempts to protect the tracer user password is just obfuscating, and not
actual protection. I think the first step is to isolate the trace server's configuration,
and run it as a separate user, with locked down permissions on its configuration file. The
other options just seem needlessly complex to me, and these steps seem to be what other system
services are doing.

PHP, for instance, might need to store a mysql username/password, or httpd might need access
to an SSL certificate's passphrase to unlock a private key non-interactively. It seems to
me that the best practices precedents seem to be to isolate the config and lock down file
system permissions to the config file.

> Trace user password required in plaintext in accumulo-site.xml
> --------------------------------------------------------------
>
>                 Key: ACCUMULO-2464
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2464
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: trace
>    Affects Versions: 1.5.1
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: 1.5.2, 1.6.1
>
>
> The {{trace.password}} property is used by the Tracer to authenticate with Accumulo and
persist the traces in the trace table. Presently, this is required to be in plaintext which
is rather sub-par, but has been overlooked mostly because that password is for an isolated
user account which shouldn't have access to any sensitive data.
> I'm thinking of the following: provide some new storage in ZK akin to the acl + salt
that's currently done for the passwd db and instance.secret (with a new secret for this, of
course)
> Another option might be to provide a hashing command that will hash the password, store
that instead of the plaintext, and then use the hash with a salt to authenticate (not exposing
the hash-authentication method to users). Not sure how I feel about that.
> Leveraging some BCrypt library might be nice too (if there's an ASF license compatible
lib somewhere). 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message