accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2464) Trace user password required in plaintext in accumulo-site.xml
Date Thu, 13 Mar 2014 20:21:43 GMT


Christopher Tubbs commented on ACCUMULO-2464:

I don't disagree that proper kerberos support would be a good idea... I just think it's out
of scope and way beyond what is needed to address this issue. I also think kerberos should
stay optional, rather than required, because it increases the barrier to entry, especially
if you're not already using a kerberos-enabled Hadoop (perhaps you're using some other HDFS-compatible
FileSystem which doesn't have or need kerberos?).

In any case, a simpler solution could satisfy kerberos use cases as well, without making it
mandatory, and while providing the user with many powerful ways to manage their credentials


[~kturner] also mentioned to me that we could just complain loudly if the filesystem permissions
were open on whatever file contained the sensitive credentials, like OpenSSH does. The simplest
thing is to do that for accumulo-site.xml today.

> Trace user password required in plaintext in accumulo-site.xml
> --------------------------------------------------------------
>                 Key: ACCUMULO-2464
>                 URL:
>             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
> 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

View raw message