Univention Bugzilla – Bug 30981
Unsalted user password hashes in pwhistory
Last modified: 2013-11-19 06:44:23 CET
Currently the pwhistory user attribute uses unsalted password hashes.
it's not a bug, it's a feature and allows password synchronization to GoogleApps. Would be nice to allow some kind of configuration, like:
* Default/Neu-Install: use salted hashes
* Optional/Backward: use unsalted hash
We will not ship a UCS 3.1-2 release; the next UCS release will be UCS 3.2.
As such, this bug is moved to the new target milestone.
A salted password history is impossible, or at least anything but trivial, because a new random salt is/should be generated for every new password which means that comparing the new salted password hash would never match any old salted password hash in the history.
In course of this bug I have changed another strange thing about how passwords were stored in the history:
Formerly, they have been stored as SHA1 hash while the current password salted hash is created using the hashing method defined in the UCRV "password/hashing/method".
I've adapted the password history to also evaluate the UCRV "password/hashing/method".
OK this seems to work , but (In reply to Lukas Walter from comment #3)
> A salted password history is impossible, or at least anything but trivial,
> because a new random salt is/should be generated for every new password
> which means that comparing the new salted password hash would never match
> any old salted password hash in the history.
save the salted hash in pwHistory
and during password change for every entry in pwHistory do
get salt (ClLgXni.ShrHOMhS), method_id (6) and run crypt.crypt() with the new password
crypt.crypt("univention".encode('utf-8'), '$%s$%s$' % (6, "ClLgXni.ShrHOMhS",))
and than compare this with the pwHistory entry
If we use a new pwHistory compare function all old pwHistory entries are pretty much useless so we need to check both, the new and the old way
Passwords will be stored in history as suggested. For backwards compatibility, the password history check defaults to the 3.1-1 behaviour for comparison when detecting an old style password hash.
Changelog entry has been modified to match the new changes.
OK - old pwHistory entries are checked correctly
OK - new pwHistory entries are stored as salted crypt hashes (according to
OK - new pwHistory entries are checked correctly
OK - changing password/hashing/method does not break pwHistory
OK - Changelog
(In reply to Fabian Zimmermann from comment #1)
> it's not a bug, it's a feature and allows password synchronization to
> GoogleApps. Would be nice to allow some kind of configuration, like:
Today we released a SAML app for UCS. We also documented the Google Apps for business configuration:
UCS 3.2 has been released:
If this error occurs again, please use "Clone This Bug".