We've moving from DS 1.4 --> DS 2.1
With DS 1.4, we have our password hashing set to PBKDF2_SHA256. Our DS 2.1 defaults to PBKDF2-SHA512.
During the cutover phase, I want to set the 2.1 instances back to SHA256. We'd then advance the storage scheme to SHA512 when we were ready to sever our links to the past.
Through the cockpit-interface, I may choose among:
* PBKDF2-SHA1 * PBKDF2-SHA256 * PBKDF2-SHA512 * PBKDF2_SHA256
Are the two SHA256 choices the same? Is there some significance I'm missing in the "_" and the "-" characters?
On 12 Jan 2024, at 10:19, John Thurston john.thurston@alaska.gov wrote:
We've moving from DS 1.4 --> DS 2.1 With DS 1.4, we have our password hashing set to PBKDF2_SHA256. Our DS 2.1 defaults to PBKDF2-SHA512. During the cutover phase, I want to set the 2.1 instances back to SHA256. We'd then advance the storage scheme to SHA512 when we were ready to sever our links to the past. Through the cockpit-interface, I may choose among: • PBKDF2-SHA1 • PBKDF2-SHA256 • PBKDF2-SHA512 • PBKDF2_SHA256 Are the two SHA256 choices the same? Is there some significance I'm missing in the "_" and the "-" characters?
https://fy.blackhats.net.au/blog/2022-11-25-why-are-pbkdf2-sha256-and-pbkdf2...
tl;dr Use PBKDF2-SHA256. (hyphen, not underscore).
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
Excellent, thank you very much, William!
But know that I've read that, I think I'll want to start with the underscore-implementation. That should result in ldifs from my DS 2.1 which I could, if needed, use with my DS 1.4 instance. This isn't a long-term setting, just a migration step until we turn off 1.4. At that time, we'll step 2.1 up to SHA512 and duck the whole -/_ thing.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston@alaska.gov Department of Administration State of Alaska
On 1/11/2024 3:36 PM, William Brown wrote:
On 12 Jan 2024, at 10:19, John Thurston john.thurston@alaska.gov wrote:
We've moving from DS 1.4 --> DS 2.1 With DS 1.4, we have our password hashing set to PBKDF2_SHA256. Our DS 2.1 defaults to PBKDF2-SHA512. During the cutover phase, I want to set the 2.1 instances back to SHA256. We'd then advance the storage scheme to SHA512 when we were ready to sever our links to the past. Through the cockpit-interface, I may choose among: • PBKDF2-SHA1 • PBKDF2-SHA256 • PBKDF2-SHA512 • PBKDF2_SHA256 Are the two SHA256 choices the same? Is there some significance I'm missing in the "_" and the "-" characters?
https://fy.blackhats.net.au/blog/2022-11-25-why-are-pbkdf2-sha256-and-pbkdf2...
tl;dr Use PBKDF2-SHA256. (hyphen, not underscore).
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia --
On 12 Jan 2024, at 11:21, John Thurston john.thurston@alaska.gov wrote:
Excellent, thank you very much, William! But know that I've read that, I think I'll want to start with the underscore-implementation. That should result in ldifs from my DS 2.1 which I could, if needed, use with my DS 1.4 instance. This isn't a long-term setting, just a migration step until we turn off 1.4.
That's fine - it's what the "upgrade on bind" feature is for. Once you finish your migration, you change the default pw scheme in dse.ldif and then on bind it transparently upgrades the hash format.
At that time, we'll step 2.1 up to SHA512 and duck the whole -/_ thing.
You should use PBKDF2-SHA256 here, not SHA512. Big number != more securerer. The benefit of PBKDF2 is that it many rounds which forces an attacker to do a lot of work. SHA256 is a secure hash here, so you dont practically gain anything by choosing PBKDF2-SHA512 over PBKDF2-SHA256 - they both will end up targeting and achieving the same work factor. Worst case you actually end up less secure if you have a CPU that *doesn't* have hardware accelerated SHA512. This will force fewer rounds as a result, where SHA256 could achieve more rounds because your CPU has hwaccel for the algo. NIST still recommend PBKDF2-SHA256 here as well.
If you don't have FIPS requirements, consider argon2 instead as it's memory hard as well as cpu hard.
-- Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
389-users@lists.fedoraproject.org
-
John Thurston -
William Brown