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 16:55:44 GMT


Christopher Tubbs commented on ACCUMULO-2464:

I don't think protecting sensitive credentials (passwords, keytabs) in configuration files
should require Kerberos. Requiring Kerberos would be a very big change. We can protect non-keytab
creds too.

P.S. I don't think protecting a kerberos keytab is any more well understood than protecting
keytabs is any more well understood than protecting any other private credentials (passwords,
certificates). For instance, FreeIPA describes [filesystem permissions|]
as a solution, and Oracle simply describes using a tool that writes a file (/etc/krb5/krb5.keytab)
that is protected with [filesystem permissions|].
There's nothing novel in these solutions. They are based on precisely the isolation and filesystem
permissions scheme I've mentioned above.

> 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