#50657 pbkdf2 check bits of extraction from saved cred
Closed: wontfix 4 years ago by firstyear. Opened 4 years ago by firstyear.

Issue Description

At the moment we have hardcoded the number of bytes (bits *8) into pbkdf to extract. This means that from other sources (ie django) we can't import their hashes because they are shorter in number of bits.

Instead we should have pbkdf encoded a certain amount on create of the hash, but then when we do the comparison, we length check the current credential we got from the entry, and we use that as the amount of bits to extract.

This would allow us to put in shorter pbkdf2 hashes into 389 allowing migrations from other pbkdf2 storage sources.

A key note is we must have a minimum acceptable number of bits so that some migrated sources, or attacker manipulated sources that truncate the bits to less than say ... 256? would be rejected as "too short to compare".

Package Version and Platform

Steps to reproduce

1.
2.
3.

Actual results

Expected results


This was raised by colby prior of github via direct email to me.

Metadata Update from @firstyear:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

4 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.2

4 years ago

arrghh William of the past made some pretty fundamental mistakes here.

While we could update this to have variable bit-outputs from the hashes to accomodate different sources, the format I chose for the storage as a binary blob was intended to make the C code easier because C string parsing ... well. Sucks. But as a result, this mean the salt length is now fixed, so any scheme with a different salt length OR format, can't work.

This means even if I was to write this, we couldn't import django pw's because they use a salt that's 13 characters long, where as we extract a 64 char salt.

I'd like to say William-of-the-past made some fundamental flaws here, and really that if we want to support this, we'll need to actually write a second pbkdf2 module that actually supports variable length formats such as the django style hash.

Metadata Update from @firstyear:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)

4 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/3712

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: invalid)

3 years ago

Login to comment on this ticket.

Metadata