differentiate hashtype in potfiles and outfiles

[roycewilliams]

Long term, the best ecosystem play is to enable per-hash annotation of what hashtype each hash was. Mixed potfile cleanup / parsing / management is a regular FAQ item. Instead, this information can be preserved and recorded when it is clearly known.

To make the transition easier / voluntary / gradual, I propose two changes:

1. Add an option (--potfile-hashtypes?) to enable prepending hashtype ID to potfile output, separated by a tab, as in:

0	8743b52063cd84097a65d1633f5c74f5:hashcat
10	01dfae6e5d4d90d9892622325959afbe:7050461:hashcat
100	b89eaac7e61417341b710b727768294d0e6a277b:hashcat
1000	b4b9b02e6f09a9bd760f388b67351e2b:hashcat

This would govern both output (writing to the potfile) and input (reading from the potfile). If --potfile-hashtypes is enabled and a non-prepended hash is encountered, hashcat could either abort (leaving it to the user to clean up their potfile or whatever), or assume that any non-prepended hashtype is the one that the user has specified on the hashcat command line with -m.

2. Add a hashtype option to the output file format options, as in:

- [ Outfile Formats ] -

  # | Format
 ===+========
  1 | hash[:salt]
  2 | plain
  3 | hex_plain
  4 | crack_pos
  5 | timestamp absolute
  6 | timestamp relative
  7 | hashtype

Note that by making both of these optional, users are empowered to manage the transition themselves.

Option 2 is easier to add right away. Option 1 might require discussion of ecosystem impacts and timing. But I believe strongly that, if "we" (the cracking community) knew in the beginning what we know now, we would have never constructed the potfile format without some per-hashtype field. It is this way for historical reasons only - primary because early development of password crackers only dealt with a single hash type, and the idea that thousands of hashtypes would someday be possible was distant and mostly hypothetical. :D

[PenguinKeeper7]

How would you feel about having potfile folder (potfolder?) instead, such that each -m has its own file? I can see the advantages as well as the disadvantages of it.
Advantages:

• Much faster startup with lots of founds
• Easy to transfer a single potfile type between machines
• No problems with current potfiles because it doesn't touch the typical hashcat.potfile file

Disadvantages:

• Cannot find another algorithm in the potfile, so if you select -m 0, you wouldn't be able to find a 2600 found like you could currently, (may also be a potential issue with your solution too)
• Difficult to import old potfiles to the new format (could be problematic even with your idea too)

I'm not saying im fully supporting this "potfolder" idea, just generating discussion

[mohemiv]

Sometimes, it's difficult to determine the type of hash we are dealing with. For example, distinguishing between MD4, MD5, and MD5(MD5) is impossible.

Currently, Hashcat checks all compatible formats, thereby revealing the required hash type if one of the hashes is in the porfile.

If a format check is implemented, this benefit will be lost. Also, this feature helps to spot command line errors.