accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4044) Stronger/standardized password hashing
Date Thu, 29 Oct 2015 19:13:27 GMT

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

Christopher Tubbs commented on ACCUMULO-4044:
---------------------------------------------

When UnixCrypt (truncated 8x7-bit chars + 2 byte salt with DES) was replaced with MD5 (and
now SHA-256 and SHA-512), a thin wrapper format was established for compatibility. The old
DES password format was replaced with {{$<id>$<salt>$<hash>}} where {{<id>}}
was a numerical identifier of the algorithm to use (1=MD5, 6=SHA512). This format was established
to be backwards-compatible and future-proof, and is itself (in a way) a "thin wrapper" around
the hash+salted bytes already.

Ideally, I'd like to not create a "thin wrapper" around this already existing wrapper format...
it's unnecessarily complicated and adds code better suited to the library we're using. The
most we should have to do is pull out the bytes using UTF-8 and send them to the library.
If our format cannot start with {{$}}, then we're free to replace our format directly and
distinguish between our old format and the new, while gaining the future-proofing benefits
of this standardized format. The only difference is that anything not in this format will
be assumed to be SHA-256 with 8-byte salt instead of the UnixCrypt DES format. If our format
can start with {{$}} (or is likely to... I'm okay with forcing some users to reset their password
if it's highly improbable), then we do need to add a wrapper on top of the wrapper.

As for doing it for all the data in ZK, maybe that's a good idea, too. I'll withhold judgment
until that use case is articulated in context.

> 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