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-4044) Stronger/standardized password hashing
Date Thu, 29 Oct 2015 17:41:27 GMT

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

Josh Elser commented on ACCUMULO-4044:
--------------------------------------

bq. This would be easy if we stored the new form in a different zookeeper node, but we could
also use a delimiter (not a fan of the delimiter, personally, because I'd prefer the standard
format, unmodified). We might be able to automatically migrate to the new format upon authentication,
so we can eventually drop the old format entirely

Sounds like it would be good to just introduce a thin wrapper around the hash+salted bytes
to get some uniformity in parsing going forward (akin to RFile header). This would keep all
the info in one place which would be good (and avoid the need for proactive "fixing" of data
in ZK). There's a ticket somewhere where I was advocating for this in all the data we have
in ZK now.

> Stronger/standardized password hashing
> --------------------------------------
>
>                 Key: ACCUMULO-4044
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4044
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Christopher Tubbs
>             Fix For: 1.8.0
>
>
> Currently, Accumulo stores hashed passwords using SHA-256 and an 8-byte salt, in a custom
output format.
> Instead, we should switch to using commons-codec's Crypt class to create crypt(3) style
hashes, the default of which is to use SHA-512 with a 16-byte salt. The format is stored in
a standard way, with an identifier to determine the hashing method which was used.
> We'd have to make sure that we can tell the difference between the new format and the
old format, so we know how to properly verify user credentials. This would be easy if we stored
the new form in a different zookeeper node, but we could also use a delimiter (not a fan of
the delimiter, personally, because I'd prefer the standard format, unmodified). We might be
able to automatically migrate to the new format upon authentication, so we can eventually
drop the old format entirely++.
> ++ When we do eventually drop the old format, users will need to reset their passwords,
or have an admin user do it for them. This shouldn't be a big issue if we wait a sufficient
number of releases to drop the old format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message