Update for BCrypt wrap bug detected#24
Conversation
* Use declared `IDENT_*`'s in corresponding checks
* Handle possible `ValueError` during `_finalize_backend_mixin` if expected * Add and use `passlib.handlers.bcrypt._BcryptCommon.`[+is_password_too_long()+] helper method * Add and use `passlib.handlers.bcrypt._BcryptCommon.`[+hash_password()+] helper method * Override `passlib.utils.handlers.TruncateMixin.using()` for `_BcryptCommon`: set `truncate_verify_reject` if `_fails_on_long_secrets and truncate_error` * Refer to [BCrypt wrap bug detected notypecheck#18](notypecheck#18)
* Update `_bcrypt_test.fuzz_verifier_bcrypt()/check_bcrypt()` to use `passlib.handlers.bcrypt._BcryptCommon.hash_password()`
* Consider `cand_hasher.truncate_verify_reject` to verify if should truncate long secret before comparing
… `TruncateMixin._check_truncate_policy()`
|
I think this PR still misses the mark w.r.t. Additionally, wrapping |
|
@chapmajs I'm not quite sure myself about using |
My issue with this is that the state of The mixin should provide the desired behavior (that a Changing the default probably shouldn't be done on a point release. Since the |
…ng_secrets flag`
… >= 5.0.0" This reverts commit 5ed5618.
This reverts commit 3826f12.
* Rename and improve `passlib.handlers.bcrypt._BcryptCommon.is_secret_truncate_err` helper method * Add and use `passlib.handlers.bcrypt._BcryptBackend.`[+_check_truncate_flag()+] helper method for `TruncateMixin` flags validation * Add and use `passlib.handlers.bcrypt._BcryptBackend.`[+_handle_w_truncate()+] to handle retries for truncate errors * Implement `passlib.handlers.bcrypt._BcryptBackend.`[+verify+] * Update `passlib.handlers.bcrypt._BcryptBackend._calc_checksum` to use `_handle_w_truncate(_bcrypt.hashpw, truncate_error)` * Revert "Detect BCrypt >= 5.0.0 expected `ValueError` for long secrets" - commit 3be3773 * Refer to [BCrypt wrap bug detected notypecheck#18](notypecheck#18)
* Update `_bcrypt_test.fuzz_verifier_bcrypt()/check_bcrypt()` to use `passlib.utils.handlers.GenericHandler.verify`
|
Hi @notypecheck and @chapmajs, Thank you for all your comments, feedback, concerns and suggestions. |
|
There's still a fundamental misunderstanding of what |
* Simplify and update `passlib.utils.handlers.TruncateMixin.using()` to also accept `truncate_verify_reject` * Add and use `passlib.utils.handlers.TruncateMixin.`[+_check_truncate_flag()+] and [+_check_verify_truncate_policy()+] helper methods * Update `tests.utils.HandlerCase.test_truncate_error_setting()` to cover `truncate_verify_reject` setting * Update `passlib.handlers.bcrypt._BcryptBackend` accordingly
|
Local tests run results using BCrypt versions 4.3.0 and 5.0.0:
|
There was a problem hiding this comment.
This existing comment (which was present prior to any of the PR work) explains the crux of the issue I'm seeing:
Setting ``truncate_error=True`` will cause :meth:`~passlib.ifc.PasswordHash.hash`
to raise a :exc:`~passlib.exc.PasswordTruncateError` instead.
Handlers that use the TruncateMixin should not be raising in their own code for truncation, except maybe if they need to completely reimplement hash() and verify() -- it's behavior and functionality defined and implemented in the mixin. See PR #23 -- you will notice that there are no changes to internal state or raising within wrapped methods, etc. It "just works" because it
- uses the default
hash()andverify() - includes the
TruncateMixin
Note that the tests correctly manipulate variables to control TruncateMixin behavior as-is. You can look at some of the other backends that already include TruncateMixin for alternate examples.
Do also note that calling super().hash() and/or super().verify() from within a custom hash() and/or verify() method will also correctly integrate TruncateMixin functionality.
|
Closing PR as per #25 (comment). |
Improved version of PR Update for BCrypt wrap bug detected #19, based on bcrypt improvements, test fixup #23, including usage of
TruncateMixinalong withpasslib.exc.PasswordTruncateError.