-
Suggestion
-
Resolution: Won't Fix
-
None
Currently OpenLDAP connector does not support CRYPT. See also CWD-427. Although CRYPT is not recommended as an encryption method any more, some customers might still need it.
Additional work in this to make sure OpenLDAP password are saved with the correct prefix all the time.
- relates to
-
- Closed
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CWD-481] Support CRYPT encryption in OpenLDAP connector
Justin Koke
added a comment - Hi Aggelos,
This is my plan, I will be adding in the Atlassian Plugin Framework to Crowd in either 1.3 or 1.4, so after this time we should be able to implement all the encoders as plugins.
Justin
Justin Koke
added a comment - Hi Aggelos,
This is my plan, I will be adding in the Atlassian Plugin Framework to Crowd in either 1.3 or 1.4, so after this time we should be able to implement all the encoders as plugins.
Justin Hi Dave,
that was a real blow 
This way you avoid the support costs but you pass on the maintenance costs to the customer. Every time we (our customer) need to upgrade Crowd, we have to patch the release in order to support the encryption scheme. And the upgrades are not that rare.
Is there any chance you can make the encryption schemes pluggable in order to develop it as a plugin?
Regards,
Aggelos
David O'Flynn [Atlassian]
added a comment - Hi Aggelos,
We're not going to put CRYPT support into Crowd. We've looked into the issue in detail, and crypt(3) implementations vary too much across platform to include the protocol in the product. For example, OpenLDAP compiled for Windows will not accept passwords crypt()'d in Java. The support costs outweigh the benefits, particularly given that crypt, being based on DES (at least in some implementations) is horribly insecure.
Regards,
Dave.
Crowd Team Lead.
David O'Flynn [Atlassian]
added a comment - Hi Aggelos,
We're not going to put CRYPT support into Crowd. We've looked into the issue in detail, and crypt(3) implementations vary too much across platform to include the protocol in the product. For example, OpenLDAP compiled for Windows will not accept passwords crypt()'d in Java. The support costs outweigh the benefits, particularly given that crypt, being based on DES (at least in some implementations) is horribly insecure.
Regards,
Dave.
Crowd Team Lead. Justin, sorry for being negligent on the IP part. Thanks for the research too. I'll try to grab UnixCrypt and give it a try.
Cheers,
Aggelos
Thanks for this work Aggelos.
I have a few issues around the jcrypt.java file ( origins and license), doing a bit of research it appears it is from John Dumas and is based on work originally done by Eric Young. Eric Young's work was done under a BSD license but the Dumas derivative is not clear around license.
These is also a Mortbay UnixCrypt implementation which is based under an Apache 2.0 license. I think when we pull a Crypt implementation into Crowd we should attempt to use the Mortbay version.
A general run down on Java crypt work is available here: http://www.dynamic.net.au/christos/crypt/
Justin Koke
added a comment - - edited Thanks for this work Aggelos.
I have a few issues around the jcrypt.java file ( origins and license), doing a bit of research it appears it is from John Dumas and is based on work originally done by Eric Young. Eric Young's work was done under a BSD license but the Dumas derivative is not clear around license.
These is also a Mortbay UnixCrypt implementation which is based under an Apache 2.0 license. I think when we pull a Crypt implementation into Crowd we should attempt to use the Mortbay version.
A general run down on Java crypt work is available here: http://www.dynamic.net.au/christos/crypt/
Attaching several files that add CRYPT support. Used a java implementation and not a JNI call as Shihab initially suggested. Authentication seems to work, along with updating passwords thorugh Crowd UI.
Hi Justin,
this is good news indeed. Thanks for letting as know.
Cheers,
Aggelos