DES is no longer considered to be secure. We currently have a reversible password storage scheme plug-in that uses DES for the replication and chaining bind credentials. We should be using something more secure as the default config, such as AES.
We still need to be able to decode DES passwords to support upgrades, but it would be nice if we could decrypt the stored DES credential, then re-encrypt and store it using AES as a part of the upgrade process.
Some plugins, like DNA, still decode the replication credentials when it fetches a new range. This needs to be taken into consideration as well.
Replying to [comment:2 mreynolds]:
I was thinking that we could have the upgrade code convert the DES encrypted credentials to AES as a first step. Any newly created credentials would also use AES. Eventually, we could remove all DES capability from DS.
Currently AES is not available for password based encryption, opened a bug against NSS to have it included.
A nice improvement!
I have 2 requests... :) 1) Could you put 2015 in the new file's copyright?
Copyright (C) 2005 Red Hat, Inc.
2) For the code readability, could you please put this definition in the comment that handles the new format (e.g., in checkPrefix)? {AES-<BASE64 encoded alg ID>}<ENCODED PASSWORD>
And it might be a silly question since this {<HASH>or<CRYPT>} format is not new, but are we supporting unnormalized type like this? If accidentally, put this kind of type, what happens? { AES - <BASE64 encoded alg ID> }<ENCODED PASSWORD>
Thanks!
Replying to [comment:9 nhosoi]:
A nice improvement! I have 2 requests... :) 1) Could you put 2015 in the new file's copyright? Copyright (C) 2005 Red Hat, Inc.
Done
And it might be a silly question since this {<HASH>or<CRYPT>} format is not new, but are we supporting unnormalized type like this? If accidentally, put this kind of type, what happens?
The password will not be decoded (invalid scheme), but this is all handled by server internally. No one should be directly modifying these values. You could argue the same point about: { DES }sudfnbisbdf==
New patch attached...
{ AES - <BASE64 encoded alg ID> }<ENCODED PASSWORD> Thanks!
{ AES - <BASE64 encoded alg ID> }<ENCODED PASSWORD>
revision 0001-Ticket-47462-Stop-using-DES-in-the-reversible-passwo.patch
Thank you, Mark!
ce4ff66..a57494f master -> master commit a57494f Author: Mark Reynolds mreynolds@redhat.com Date: Tue Jan 20 10:59:05 2015
8a8e1fc..603501e 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 603501e
8078a9e..ea24166 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit ea24166 Author: Mark Reynolds mreynolds@redhat.com Date: Tue Sep 6 16:05:49 2016 -0400
Metadata Update from @nhosoi: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.3.2
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/799
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.