You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Add an option (--potfile-hashtypes?) to enable prepending hashtype ID to potfile output, separated by a tab, as in:
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.
Add a hashtype option to the output file format options, as in:
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
The text was updated successfully, but these errors were encountered:
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
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:
--potfile-hashtypes
?) to enable prepending hashtype ID to potfile output, separated by a tab, as in: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
.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
The text was updated successfully, but these errors were encountered: