Add the ability to reverify a secret knowing the secret type

[CameronLonsdale]

Description

Reverifying a secret with trufflehog requires re-scanning the source file, since many of the detectors depend on keywords before the secret itself, if you only have access to the secret trufflehog may not identify it as verified.

Preferred Solution

Expose a method to call the verify function on a secret type knowing the secret itself. The scope would be all secrets in trufflehog that have a verifier function, not just those listed in Analyze

Additional Context

It's very similar to the new trufflehog analyze except it's only focused on yes/no verification, not what scopes are present for that secret.

[shahzadhaider1]

Hi @CameronLonsdale

Thank you for opening this issue. We sincerely appreciate your contribution to the project.
We'll review it and get back to you as soon as possible. If we need any further details, we'll follow up here.

Thanks again for helping improve the project!

[rgmz]

Somewhat related to #2128 and #3634 (comment).

[CameronLonsdale]

Very much related to those issues. I've thought through the same solution as #2128 also, and think that the most reliable would be to expose the Verify functions for each secret type via command line argument. For example trufflehog verify Buildkite.

You would likely have to update the function signature of the verify functions so that they all have the same name (cause right now they're often named VerifyBuildkite instead of just Verify), then you can just find the scanner type from the terminal argument and then call the corresponding verify function.

[CameronLonsdale]

Oh but TIL on #3634 (comment), not all rawV2 values are the secret themselves, that does make it trickier 🤔, and uplift might be needed there first.

[CameronLonsdale]

The other caveat here is that not all secrets are a single token, sometimes requiring multiple values and how to structure them (e.g. and ID & secret, or maybe a URL of the host too). That complicates things also, if we update all Verify functions to have the same signature we need to define some kind of shared struct which you can pack, and then each verifier unpacks and uses whatever values it requires to verify. There may be some other elegant solution.