Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support for calling the HIBP API #18

Open
ryannewington opened this issue Jul 21, 2019 · 14 comments
Open

Add support for calling the HIBP API #18

ryannewington opened this issue Jul 21, 2019 · 14 comments
Assignees
@ryannewington
Labels
enhancement New feature or request pinned

Comments

@ryannewington
Copy link
Member

No description provided.

@ryannewington
Copy link
Member Author

Code started

https://github.com/lithnet/ad-password-protection/blob/hibp-integration/src/PasswordFilter/hibp.cpp

@ryannewington ryannewington mentioned this issue Jul 21, 2019
Closed
@ryannewington
Copy link
Member Author

@AaronG1234

Here is a release with HIBP support for you to test with. (Not LSA signed yet though).

You'll find a new GPO setting to turn on HIBP support

image

Note, this doesn't allow you to audit existing user passwords, only check new passwords being set/changed

Lithnet.ActiveDirectory.PasswordProtection.msi.zip

I'd appreciate any feedback you have to offer as a result of your testing.

@ryannewington ryannewington self-assigned this Jul 23, 2019
@ryannewington ryannewington added the enhancement New feature or request label Jul 23, 2019
@AaronG1234
Copy link

AaronG1234 commented Jul 23, 2019 via email

@bryan4tw
Copy link

Would it be possible to have it fail back to an offline copy whenever the API is down?

@AaronG1234
Copy link

AaronG1234 commented Oct 30, 2019 via email

@ryannewington
Copy link
Member Author

The HIBP module is just another policy module, so you can have local store enabled at the same time as HIBP. You can choose if you want a HIBP failure to result in the password being rejected, or passing (fail open/closed).

@AaronG1234
Copy link

AaronG1234 commented Oct 31, 2019 via email

@ryannewington
Copy link
Member Author

A positive or negative password test result is different from a failure processing the request such as in the case that the api is not available.

Being 'more expensive' the hibp API call is processed last in the chain, so the password would need to be approved by the on prem module first anyway to even get there. So if the on prem passed it, and the hibp api failed, you can choose to allow the password, or reject it.

@bryan4tw
Copy link

Ah, that makes perfect sense.

@AaronG1234
Copy link

AaronG1234 commented Nov 1, 2019 •
edited
Loading

Just to solidify my understanding (and I apologize Ryan, I meant to test it sooo much sooner)

Is it true that we can operate in any one of these three “models”

  1. On Prem Database has been downloaded and configured to use
  2. No On Prem Database exist, The HIBP API has been configured to use
  3. On Prem Database has been downloaded and configured to use, the HIBP API has been configured to us

Note: Honestly I think most admins who want #2, would still benefit from a small, organizational propriety On Prem (without the massive imports) and then HIBP API (if so that would be #3)

I know that If Model 2) “API Only”
We have a setting via GPO/Registry to Fail open or Fail closed (again for password change moments, fail open means we allow the password to be set NOT KNOWING if it is in HIBP)

I assume, based on your latest feedback, that in Model 3) “BOTH”
If the password is in found in the Local “Evil Password” store [via hash, forbidden, regex, or any other method supported by Model 1) “ON Prem Only”]
The password will be denied, and there will be a log that states the password was denied by the module (if HIBP has been configured, can this error be specific that it was the LOCAL DB that triggered the deny?)
Does the module even check HIBP API in this scenario?

If the password is NOT in Local “Evil Password” store, we query HIBP Password API
If there is a hit (Non Zero Count), the password will be denied, and there will be a log that states the password was denied by the module (will this error be specific that it was the HIBP API that triggered the deny? Will the Error have the **hit count in the Data)
If HIBP Password API is unreachable,
Depending on the policy (there is a GPO/Registry specific for this scenario)
(Fail Open) The password change will be allowed, and there will be a log that states the password was allowed by the module, BECAUSE the API Failed and the policy said so? Or a separate log that the API failed? Or both?
(Fail Closed) The password change will be denied, and there will be a log that states the password was denied by the module, BECAUSE the API Failed and the policy said so? Or a separate log that the API failed? Or both?

Aaron

• As far as **Hit Counts from HIBP
o My own code that is doing this (LSA Notification package, but not even close to as smooth as yours 😝) we decided to log a hit count range, instead of the exact number… we were worried that there are some passwords that have a unique hit count.
o So for us, my current logging returns a hit count of:
 NONE (0),
 UNIQUE (1),
 RARE (2-5),
 UNCOMMON (6-10),
 COMMON (11+)

we almost went with Rare was 2-3, and then common is 4+, but wanted a bit more data. (either range is valuable, the point is hit counts are valuable for Support Staff, communication, education, risk metrics, etc.)

@ryannewington
Copy link
Member Author

ryannewington commented Nov 2, 2019 •
edited
Loading

@AaronG1234

Each password check type (regex, hibp, banned word, length, complexity, etc) is an independent module. Each is processed one at a time in 'general' order of processing speed. For example, the password length check is faster than regex check, so that happens first. Each module has the opportunity to reject the password, and each have their own specific event id codes.

The HIBP module appears last in the list, as it is the most expensive. If you choose to enable the option in group policy to allow the password change on a hibp failure, a specific event code is logged for this condition. If you don't enable the GPO setting for this, the password will be rejected. As HIBP is called last, all other modules need to approve the password before it gets here.

I can't remember if the hit counts are logged. I think it does. I've been debating including this feature or not in a new api standard we are proposing. It's increases the data transfer amount by an non-trivial amount, for no tangible security benefit. Happy to hear thoughts on this though.

@ryannewington ryannewington reopened this Nov 2, 2019
@ryannewington
Copy link
Member Author

Didn't mean to close the issue. Fat-fingered on mobile view.

@smwinn
Copy link

smwinn commented Sep 12, 2022

Is this any closer to being in the release channel?

@SeSeKenny
Copy link

SeSeKenny commented Mar 14, 2023 •
edited
Loading

Unless I am misunderstanding something here, adding a call for the new NTLM mode would enhance things as well. The sha1 HIBP isn't the same as the NTLM HIBP lists by the nature of either being OWFs and depending on the raw sources? If I am correct, than having the sha1 API is actually adding more protection too.

NVM I was incorrect - https://twitter.com/troyhunt/status/1635727629021237248

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ryannewington ryannewington

Labels
enhancement New feature or request pinned
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@bryan4tw @ryannewington @SeSeKenny @AaronG1234 @smwinn