#47462 Stop using DES in the reversible password encryption plug-in
Closed: wontfix Opened by nkinder.

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]:

Some plugins, like DNA, still decode the replication credentials when it fetches a new range. This needs to be taken into consideration as well.

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-}

And it might be a silly question since this {or} format is not new, but are we supporting unnormalized type like this? If accidentally, put this kind of type, what happens?
{ AES - }

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

2) For the code readability, could you please put this definition in the comment that handles the new format (e.g., in checkPrefix)?
{AES-}

Done

And it might be a silly question since this {or} 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 - }

Thanks!

Thank you, Mark!

ce4ff66..a57494f master -> master
commit a57494fcaffccb6fdd060a93ba605d432e38bc09
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 603501ec6bbe6ee9b3f033e924a4eef2a4925aa7

8078a9e..ea24166 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit ea241668ec7be475092a0da2a5d579e31ade1058
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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

Metadata