#47462 Stop using DES in the reversible password encryption plug-in
Closed: wontfix None Opened 11 years ago 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-<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

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>

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!

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

8 years ago

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)

4 years ago

Log in to comment on this ticket.

Metadata