-
Notifications
You must be signed in to change notification settings - Fork 807
3039 smarter brute force credentials generator #3048
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
3039 smarter brute force credentials generator #3048
Conversation
Codecov ReportPatch coverage has no change and project coverage change:
Additional details and impacted files@@ Coverage Diff @@
## develop #3048 +/- ##
===========================================
+ Coverage 67.17% 67.23% +0.06%
===========================================
Files 438 439 +1
Lines 12602 12627 +25
===========================================
+ Hits 8465 8490 +25
Misses 4137 4137
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
monkey/infection_monkey/exploit/tools/brute_force_credentials_generator.py
Outdated
Show resolved
Hide resolved
monkey/infection_monkey/exploit/tools/brute_force_credentials_generator.py
Show resolved
Hide resolved
...ey/tests/unit_tests/infection_monkey/exploit/tools/test_brute_force_credentials_generator.py
Show resolved
Hide resolved
...ey/tests/unit_tests/infection_monkey/exploit/tools/test_brute_force_credentials_generator.py
Show resolved
Hide resolved
Credentials(identity=IDENTITIES[2], secret=SECRETS[3]), | ||
} | ||
|
||
generate_and_compare_credentials(input_credentials, expected_credentials) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could also assert the correct order as the output should be deterministic. IMO less UT code to maintain is worth it, but "test one thing only" has benefits as well, so I leave it up to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The interface doesn't make any promises about the order, except that complete credentials from the input are first. But, again, it does not make any promise about the order of those credentials.
identity_type = type(credentials.identity) | ||
identities.setdefault(identity_type, set()).add(credentials.identity) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the point of putting identities/secrets into dicts by types? This is an indirect way of grouping the output by type? Why do we want it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fairly direct. There's a comment below. Basically, orderly output is better than disorderly, IMHO. It might be useful for debugging. If we need to dump out the result, at least there's some order to it.
So, yeah, it's analogous to an SQL GROUP BY
clause. Order isn't guaranteed by the interface (other than ordering complete/known-good credentials first"
identity_filters: Iterable[Callable[[Identity], bool]] = (), | ||
secret_filters: Iterable[Callable[[Secret], bool]] = (), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's everyone's thoughts on this? Would it be better to just allow the user to provide a single filter for each of these, instead of an iterable?
Options:
- Allow the user to provide a single filter for each. This is probably the most common use case. If a user wants to filter on multiple criteria they can build a single compound filter and pass it in.
- Leave it as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I say leave it in, assuming there's no downside to doing that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The interface is arguably more cumbersome if you just need a simple filter, but arguably nicer for those cases with more complex filtering criteria.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's already implemented and it's not something whose logic will change often.
With our end goal being an easy-to-use plugin system, I like the idea of leaving this in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some discussion on webex, we decided to go with a single filter, as this will support the vast majority of cases.
de428f6
to
1c568ae
Compare
1c568ae
to
2ad1ed2
Compare
The vast majority of uses for this function will require filtering certain types of secrets. Only one filter is required to this. Accepting an iterable of filters for identities and secrets unnecessarily complicates the code and interface.
2ad1ed2
to
68507ed
Compare
What does this PR do?
Fixes #3039
Add function for smarter brute force credentials generation
PR Checklist
Was the CHANGELOG.md updated to reflect the changes?Was the documentation framework updated to reflect the changes?Testing Checklist
If applicable, add screenshots or log transcripts of the feature working