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.

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

Include username-based filtering #6

Open
darrellenns opened this issue Feb 23, 2017 · 9 comments
Open

Include username-based filtering #6

darrellenns opened this issue Feb 23, 2017 · 9 comments

Comments

@darrellenns
Copy link

It would be great to include username-based filtering, so that a password is not allowed to contain the user's name. Microsoft's built in filter already does this. The details of how it handles it are here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms722458(v=vs.85).aspx

@brockrob
Copy link
Contributor

brockrob commented Mar 8, 2017

Agree that this would be nice. I'll have a go at it in my fork. The DLL is aware of the username but only sends the password over to the C# service, so in theory it wouldn't be a difficult addition.

@jephthai
Copy link
Owner

At some point, my thought has been to create a facility for arbitrarily complex rules, probably by embedding an interpreter of some sort in the policy service. That way, you could essentially write scripts that execute with input coming from LSASS. To make that most useful, then all possible metadata should be included in the submission from the DLL to the service.

@brockrob
Copy link
Contributor

The ability for the service to take in the username and apply something like hashcat's rules would be really nice - keep user 'James' from building a password containing 'J4m35', for example. Perhaps we could adopt their rule syntax for simplicity/familiarity? It's a pretty similar problem with a good and powerful solution.

@jephthai
Copy link
Owner

Exploring that possibility, the same rule-based mutation of dictionary entries could be done as well. The only concern would be spiking CPU by applying too many rules. That's not such a concern for the username, though, since there's only one.

@brockrob
Copy link
Contributor

Interesting, but yeah, you'd have to be very careful about performance. May be worth examining Hashcat's source and see if that implementation could just be extracted for use here. It'd be the shortest route.

@darrellenns
Copy link
Author

I think regex matching would probably work better for rules. The hashcat syntax is more designed for generating every permutation, while regex is an excellent and well established tool for matching patterns in an already existing string. It shouldn't be a performance problem at all to match against a few regex rules on each password change - it's probably much faster than the dictionary lookups you are already doing.

@kcdsb-csd
Copy link

@jephthai I think that "Password Hook" is what you're describing. The tool invokes an arbitrary script on every password change request. With that added feature you might then also consider passing the username along with the password. Now users can create more complex password rules (if user in OU and user in ad-group and password not in badlist.txt). Of course possible issues with latency and also exposing username/password to other applications ...

@perederyaev
Copy link

@dack As it's shown in item 4 at https://msdn.microsoft.com/en-us/library/windows/desktop/ms721766(v=vs.85).aspx
you can "enforce both the default Windows password filter and the custom password filter".

@brockrob
Copy link
Contributor

Original issue is solved in pull request #11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants