You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Thilo-Alexander Ginkel <th...@ginkel.com> on 2017/02/25 17:31:06 UTC
[ApacheDS] Questions regarding possible BCrypt support for hashed passwords
Hello everyone,
I have been asked on IRC to address this question to the mailing list,
so here we go...
First, a brief background: I have an existing user directory, which
does not use LDAP and stores its passwords as bcrypt hashes. I'd like
to migrate this directory to LDAP using ApacheDS as backend without
having all users to reset their passwords.
So considering that ApacheDS currently does not support BCrypt, I
thought about adding such support and contributing it throgh a pull
request.
Upfront, there are a couple of questions, though, which I'd like to
clarify to improve the chances for the PR to be accepted. ;-)
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.
2. Would you prefer an implementation as crypt variant (sub-prefix
$2a$) or a separate algorithm?
Thanks & kind regards,
Thilo
[1] http://www.mindrot.org/projects/jBCrypt/
[2] https://github.com/jeremyh/jBCrypt
[3] https://www.apache.org/legal/resolved
Re: [ApacheDS] Questions regarding possible BCrypt support for hashed
passwords
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 02/27/2017 06:17 PM, Thilo-Alexander Ginkel wrote:
> 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?
That's then probably the easiest option. We can later try to move it to
commons-codec. Can you send a patch or pull request?
My other concern regarding ECCN is resolved, it doesn't apply to one-way
hash algorithms [1].
Kind Regards,
Stefan
[1] https://www.apache.org/dev/crypto.html#faq-digest
Re: [ApacheDS] Questions regarding possible BCrypt support for hashed passwords
Posted by Thilo-Alexander Ginkel <th...@ginkel.com>.
On Mon, Feb 27, 2017 at 7:03 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Can you create a JIRA ticket with the pom.xml attached ?
If that's ok, I'll provide a branch (with a single squashed commit) instead: ;-)
https://github.com/tgbyte/directory-shared/tree/feature/bcrypt-hash-support
Merci,
Thilo
Re: [ApacheDS] Questions regarding possible BCrypt support for hashed
passwords
Posted by Emmanuel Lécharny <el...@gmail.com>.
Can you create a JIRA ticket with the pom.xml attached ?
Le 27/02/2017 à 18:51, Thilo-Alexander Ginkel a écrit :
> On Mon, Feb 27, 2017 at 6:42 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> 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.
>> WHat is the failure you get ?
> Running org.apache.directory.api.osgi.ApiAsn1BerOsgiTest
>
>
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.411
> sec <<< FAILURE! - in org.apache.directory.api.osgi.ApiAsn1BerOsgiTest
> org.apache.directory.api.osgi.ApiAsn1BerOsgiTest Time elapsed: 0.406
> sec <<< ERROR!
> org.ops4j.pax.exam.TestContainerException:
> [file:/home/tg/workspace/directory-shared/integ-osgi/target/dependency/jbcrypt-0.4.jar]
> is not a valid bundle (bundleSymbolicName and bundleName are null)
> at org.ops4j.pax.exam.forked.provision.PlatformImpl.validateBundle(PlatformImpl.java:290)
> at org.ops4j.pax.exam.forked.provision.PlatformImpl.download(PlatformImpl.java:151)
> at org.ops4j.pax.exam.forked.ForkedTestContainer.downloadBundle(ForkedTestContainer.java:354)
> at org.ops4j.pax.exam.forked.ForkedTestContainer.installAndStartBundles(ForkedTestContainer.java:283)
> at org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:165)
> at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
> at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
> at org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:448)
> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>
> Regards,
> Thilo
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: [ApacheDS] Questions regarding possible BCrypt support for hashed passwords
Posted by Thilo-Alexander Ginkel <th...@ginkel.com>.
On Mon, Feb 27, 2017 at 6:42 PM, Emmanuel Lécharny <el...@gmail.com> wrote:
>> 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.
> WHat is the failure you get ?
Running org.apache.directory.api.osgi.ApiAsn1BerOsgiTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.411
sec <<< FAILURE! - in org.apache.directory.api.osgi.ApiAsn1BerOsgiTest
org.apache.directory.api.osgi.ApiAsn1BerOsgiTest Time elapsed: 0.406
sec <<< ERROR!
org.ops4j.pax.exam.TestContainerException:
[file:/home/tg/workspace/directory-shared/integ-osgi/target/dependency/jbcrypt-0.4.jar]
is not a valid bundle (bundleSymbolicName and bundleName are null)
at org.ops4j.pax.exam.forked.provision.PlatformImpl.validateBundle(PlatformImpl.java:290)
at org.ops4j.pax.exam.forked.provision.PlatformImpl.download(PlatformImpl.java:151)
at org.ops4j.pax.exam.forked.ForkedTestContainer.downloadBundle(ForkedTestContainer.java:354)
at org.ops4j.pax.exam.forked.ForkedTestContainer.installAndStartBundles(ForkedTestContainer.java:283)
at org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:165)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
at org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:448)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Regards,
Thilo
Re: [ApacheDS] Questions regarding possible BCrypt support for hashed
passwords
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 27/02/2017 à 18:17, Thilo-Alexander Ginkel a écrit :
> Hi Stefan, all,
>
> On Sat, Feb 25, 2017 at 9:37 PM, Stefan Seelmann
> <ma...@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.
WHat is the failure you get ?
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: [ApacheDS] Questions regarding possible BCrypt support for hashed passwords
Posted by Thilo-Alexander Ginkel <th...@ginkel.com>.
Hi Stefan, all,
On Sat, Feb 25, 2017 at 9:37 PM, Stefan Seelmann
<ma...@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
Re: [ApacheDS] Questions regarding possible BCrypt support for hashed
passwords
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Thilo,
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.
3rd option: commons-codec has support for other Unix crypt variants, but
BCrypt is missing. Maybe it makes sense to add BCrypt there?
> 2. Would you prefer an implementation as crypt variant (sub-prefix
> $2a$) or a separate algorithm?
Using {crypt}$2a$... would be my preferred choice. We already support
the MD5 based {crypt} variant and also $5$ and $6$ variants.
Kind Regards,
Stefan
[4] https://www.apache.org/dev/crypto.html
[5]
https://github.com/spring-projects/spring-security/blob/master/crypto/src/main/java/org/springframework/security/crypto/bcrypt/BCrypt.java
[6] https://issues.apache.org/jira/browse/CODEC-133