directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thilo-Alexander Ginkel <th...@ginkel.com>
Subject Re: [ApacheDS] Questions regarding possible BCrypt support for hashed passwords
Date Mon, 27 Feb 2017 17:17:30 GMT
Hi Stefan, all,

On Sat, Feb 25, 2017 at 9:37 PM, Stefan Seelmann
<mail@stefan-seelmann.de> wrote:
> On 02/25/2017 06:31 PM, Thilo-Alexander Ginkel wrote:
>> 1. There is an existing BCrypt implementation for Java, jBCrypt [1, 2]
>> licensed under the ISC license, which is compatible with the Apache
>> License 2.0 according to [3]. Do you consider it acceptable to
>> introduce a new dependency to support a new encryption algorithm?
>> AFAICS the dependency would need to be added to
>> org.apache.directory.api:api-ldap-model.
>
> In general that sounds ok. The library is minimal, contains only the one
> BCrypt class, no further dependencies. (side-note: the same class is
> meanwhile modified used in Spring Security [5]). Only question is if
> additional paper work is required [4]?
>
> On the other hand, ApacheDS (but not the API) already uses Bouncycastle
> dependency which also contains a BCrypt implementation.

one obstacle showed up when attempting to use jBCrypt from within the
API: The original implementation does not come as an OSGi bundle
causing the OSGi integration tests to fail. There is a fork [1], which
adds OSGi support, but has been compiled with Java 1.8 target level.
:-/

Would it be an option to "vendor" the class, i.e., copy it to the
directory-shared repo?

Alternatively, we could resort to using Bouncy Castle, but adding a
Bouncy Castle dependency to the API just to get the BCrypt
implementation feels somewhat wrong...

> 3rd option: commons-codec has support for other Unix crypt variants, but
> BCrypt is missing. Maybe it makes sense to add BCrypt there?

I have no gut feeling how difficult and/or time consuming it would be
to get the algorithm added to commons-codec, so I'm somewhat reluctant
to involve a third project. ;-) But in theory that sounds like a
sensible option.

Thanks,
Thilo

[1] https://github.com/svenkubiak/jBCrypt

Mime
View raw message