[
https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203805#comment-13203805
]
Julius Davies commented on CODEC-133:
-------------------------------------
I have a lot of triple-DES stuff in place over here (I'm the author), but I
doesn't do crypt() style password files.
http://juliusdavies.ca/commons-ssl/
It might be posssible to use some of that code, too. It's all apache licensed.
Warning: There's a good chance I don't know what I'm talking about... this
crypt()-file stuff is mostly new to me, though like anyone I have created
.password files to get my personal apache servers to do 1.1 basic auth. :-)
> Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash
> variants
> --------------------------------------------------------------------------------
>
> Key: CODEC-133
> URL: https://issues.apache.org/jira/browse/CODEC-133
> Project: Commons Codec
> Issue Type: New Feature
> Affects Versions: 1.6
> Reporter: Christian Hammers
> Labels: MD5, SHA-512, crypt(3), crypto, hash
>
> The Linux libc6 crypt(3) function, which is used to generate e.g. the
> password hashes in /etc/shadow, is available in nearly all other programming
> languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and
> offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt
> and several iterations to make rainbow table attacks harder. Thus they are
> widely used to store user passwords.
> Java, though, has due it's platform independence, no direct access to the
> libc functions and still lacks an proper port of the crypt(3) function.
> I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES
> based crypt(3) method but would also like to see the much stronger algorithms.
> There are other bug reports like DIRSTUDIO-738 that demand those crypt
> variants for some specific applications so there it would benefit other
> Apache projects as well.
> Java ports of most of the specific crypt variants are already existing, but
> they would have to be cleaned up, properly tested and license checked:
> ftp://ftp.arlut.utexas.edu/pub/java_hashes/
> I would be willing to help here by cleaning the source code and writing unit
> tests etc. but I'd like to generally know if you are interested and if
> there's someone who can do a code review (it's security relevant after all
> and I'm no crypto guy)
> bye,
> -christian-
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
