accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2464) Trace user password required in plaintext in accumulo-site.xml
Date Thu, 13 Mar 2014 15:59:46 GMT

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

Josh Elser commented on ACCUMULO-2464:
--------------------------------------

bq. 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.

Ehh, tbh, I've never really cared for that. I always do a double take when I end up in one
of those files and think to myself "wtf is that doing here!". Granted, making a one-way hash
doesn't really prevent you from some rainbowtables/dictionary attack, but at least it's not
visible to the naked eye which is a basic improvement. Maybe separating sensitive params into
their own files to allow better FS-level protection with a hash instead of the plaintext is
a good start?

> 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