If a password hashing mech in DS returns a failure, the password is not hashed and is stored in the database as:
>>> base64.b64decode('e0NMRUFSfVNlY3JldDEyMw==') '{CLEAR}Secret123'
Instead, Directory Server should write "nothing" to the database instead, as this is a potential leak.
Note, to trigger this, the password hashing module must return a failure of some kind. I only discovered this while developing a PW hashing module and returning the failure, so it's not a security bug, only a correctness one.
attachment 0001-Ticket-49027-on-secfailure-do-not-store-cleartext-pa.patch
Looks good. I have one minor request... Could you print the DN of the failed to add entry to the error log? I think it'd help troubleshooting. {{{ 571 slapi_log_err(SLAPI_LOG_CRIT, "op_shared_add", "Unable to hash userPassword attribute.\n"); }}}
{{{ [12/Jan/2017:08:44:22.223807021 +1000] - CRIT - op_shared_add - Unable to hash userPassword attribute for uid=user,ou=People,dc=example,dc=com. }}}
attachment 0001-Ticket-49027-on-secfailure-do-not-store-cleartext-pa.2.patch
commit 9835e2b Writing objects: 100% (7/7), 1.29 KiB | 0 bytes/s, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git dfcef18..9835e2b master -> master
Metadata Update from @firstyear: - Issue assigned to firstyear - Issue set to the milestone: 1.3.6 backlog
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/2086
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.