Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 13 Mar 2014 16:21:43 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12701109.1394661730888.60572.1394727703394@arcas>
In-Reply-To: <JIRA.12701109.1394661730888@arcas>
References: <JIRA.12701109.1394661730888@arcas>
Subject: [jira] [Commented] (ACCUMULO-2464) Trace user password required in
 plaintext in accumulo-site.xml
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

[~elserj]:

What good is the hash instead of plaintext? At some point, the client software needs the *actual* private credentials, not something computed from them. I don't see how you can work around this, except to integrate with some interactive credential source (direct user prompt) or pass the buck to some other interactive credential source (gnome-keyring-daemon with an interactive prompt for unlocking the keyring, etc.)

You could do something like what [Maven does|http://maven.apache.org/guides/mini/guide-encryption.html] to obfuscate passwords with an encrypted version, and put the decryption key in a separate file... but then you have to protect that other file instead of this one, so I don't see much value gained by such obfuscation. At best, it's no better than simply putting the plaintext password in its own file. And, for that, I like the kind of options that openssl provides for specifying a password source (which also formed the motivation for shell password options in ACCUMULO-1412).

Something similar to ACCUMULO-1412 could be done for configuration, but essentially, these are all just variations on the same general theme of isolating sensitive configuration to a file and locking down file permissions to the user running the service.

> 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)