Repository navigation
Why does the detector store a truncated SHA-256 fingerprint instead of the matched value? #1
|
Lifetime tracking keys on a fingerprint, not on the raw string. Why not keep the actual detected value for comparisons - it would make equality across commits trivial. What does hashing cost, and what does it protect? |
Replies: 1 comment
|
Because storing the value would make the tool a copy of the thing it reports. A scanner that keeps raw hits becomes another artifact containing the secret - the report, the cache or the regression fixture then leaks exactly what you were auditing. The fingerprint (truncated SHA-256 of the match) gives the same property comparisons need - one stable logical identity per credential - with nothing to leak. The same value re-appears as the same fingerprint; different values do not collide. It also survives cosmetic churn: the raw text can differ in surrounding quoting between commits while the fingerprint still ties both occurrences to one credential. The report stays actionable with rule, length and fingerprint - and nothing in it is a usable secret. |
Because storing the value would make the tool a copy of the thing it reports.
A scanner that keeps raw hits becomes another artifact containing the secret - the report, the cache or the regression fixture then leaks exactly what you were auditing. The fingerprint (truncated SHA-256 of the match) gives the same property comparisons need - one stable logical identity per credential - with nothing to leak. The same value re-appears as the same fingerprint; different values do not collide.
It also survives cosmetic churn: the raw text can differ in surrounding quoting between commits while the fingerprint still ties both occurrences to one credential. The report stays actionable with rule, le…