06-16-2020, 03:56 PM
06-16-2020, 04:03 PM
Depends on what you mean by "false positive".
For some hash types, hashcat will automatically show all collisions that it discovers. (You can also get this behavior for other hash types with --keep-guessing.) In theory, for most applications, any collision will serve the same purpose as the "original" plaintext, because they truly produce the same hash. And unless you know what the original plaintext truly was, you can't really tell the difference.
Famously, descrypt collisions can be found with a little effort:
"$C4U1N3R" and "SEEKETH" both hash to "1/ChERhgHoo1o" (Tom Perrine and colleagues, 2003)
"cqjmide" and "ifpqgio" both hash to "hiH9IOyyrrl4k" (unknown, 2010)
etc.
If hashcat finds a crack but that crack doesn't truly produce the expected hash, that would be a bug.
For some hash types, hashcat will automatically show all collisions that it discovers. (You can also get this behavior for other hash types with --keep-guessing.) In theory, for most applications, any collision will serve the same purpose as the "original" plaintext, because they truly produce the same hash. And unless you know what the original plaintext truly was, you can't really tell the difference.
Famously, descrypt collisions can be found with a little effort:
"$C4U1N3R" and "SEEKETH" both hash to "1/ChERhgHoo1o" (Tom Perrine and colleagues, 2003)
"cqjmide" and "ifpqgio" both hash to "hiH9IOyyrrl4k" (unknown, 2010)
etc.
If hashcat finds a crack but that crack doesn't truly produce the expected hash, that would be a bug.
06-22-2020, 06:37 PM
So it's never going to tell me that the password is 25-fghaghaglhfalgh but really it is 2-fglhasdfhladd?
06-22-2020, 06:41 PM
If 25-fghaghaglhfalgh and 2-fglhasdfhladd create the same hash it might. Otherwise it is a bug.