Open darrellenns opened 7 years ago
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.
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.
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.
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.
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.
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.
@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 ...
@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".
Original issue is solved in pull request #11.
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