You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2014/08/01 23:21:41 UTC
[jira] [Resolved] (ACCUMULO-2464) Trace user password required in
plaintext in accumulo-site.xml
[ https://issues.apache.org/jira/browse/ACCUMULO-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Elser resolved ACCUMULO-2464.
----------------------------------
Resolution: Fixed
Implemented hooks to support CredentialProvider when available (solves forward and backwards compatibility concerns).
Tested a two node instance, one with instance.secret in accumulo-site.xml and another with it in a KeyStore via the CredentialProvider.
While we're not inherently more secure than previously (because the KeyStore is not password protected itself), it gives use a few things:
# Password is not in plaintext (checkbox for system auditors)
# Allows sensitive values to be placed in location not in accumulo-site.xml (it can now be widely sharable)
# Infrastructure in place to use future CredentialProviders which actually provide a meaningful extra layer of security for us.
> 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.0, 1.5.1, 1.6.0
> Reporter: Josh Elser
> Assignee: Josh Elser
> Fix For: 1.6.1, 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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)