> On 23 Nov 2022, at 00:43, Mark Reynolds <mareynol@xxxxxxxxxx> wrote:
>
>
> On 11/22/22 9:30 AM, Thierry Bordaz wrote:
>>
>> On 11/22/22 10:28, Julian Kippels wrote:
>>> Hi Thierry,
>>>
>>> that's a nasty catch…
>>>
>>> On the one hand I think this is a nice feature to improve security, but on the other hand PBKDF2_SHA256 is the one algorithm that freeradius cannot cope with.
>>>
>>> I suppose there is no way to revert all changed hashes after I set "nsslapd-enable-upgrade-hash" to "off"? Other than to reinitialize all affected suffixes from the export of the old servers?
>>
>>
>> Indeed this is a bad side effect of the default value :(
>>
>> If you need to urgently fix those new {PBKDF2_SHA256}, then reinit is the way to go. Else you could change the default password storage to SSHA and keep nsslapd-enable-upgrade-hash=on. So that it will revert, on bind, to the SSHA hash.
>
> This reminds me of an enhancement I thought proposed awhile ago, where the upgrade hash plugin can be configured to use a specific algorithm (upgrade or downgrade). Might be worth considering it now...
>
> Mark
It just uses whatever you have set as default. We don't have a concept of "hash strength" in the project, so the "upgrade hash" is more like "force rotate the hash to what I have configured".
> to the SSHA hash.
Do not use SSHA. Never use SSHA. SSHA is plaintext in 2022. You may as well be setting "clear".
You *must* not use a verification hash to store passwords. You certainly must NOT use one that is cryptograhically broken.
In 389-ds today the following algorithms should be considered INSECURE and UNSUITABLE for password hashing and in many cases MAY be a violation of your legal requirements for user data protection.
clear
NS-MTA-MD5
MD5
SMD5
SHA
SSHA
SHA256
SSHA256
SHA512
SSHA512
CRYPT_UNIX
CRYPT_MD5
PBKDF2
PBKDF2-SHA1
The following ARE suitable.
CRYPT_SHA256
CRYPT_SHA512
PBKDF2_SHA256
PBKDF2-SHA256
PBKDF2-SHA512
The *BEST* choices are:
1) PBKDF2-SHA256 (note this is the hyphen version, not the underscore version)
2) CRYPT_SHA256
It is *STRONGLY* recommended you use one of these two.
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
