<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">On Thu, 23 Dec 2021 15:54:39 +0000 Henry Baker asked:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Could someone please explain the current strategies of brute-force password crackers these days?<br class=""><br class="">I presume that huge dictionaries of existing passwords, words, phrases, etc., + brute force alphabetic enumeration in order of probability?<br class=""><br class=""></blockquote></div><div class=""><br class=""></div><div class="">Both of the above plus custom templates and proceedures that assume some knowledge of likely password formats. And of course crackers can do highly parallel searchs using one or more high end graphics processors. </div><div class=""><br class=""></div><div class="">I suggest you look at John the Ripper Jumbo, which is a very capable cracker with many options that is currently community supported:</div><div class=""><br class=""></div> <a href="https://github.com/openwall/john" class="">https://github.com/openwall/john</a><div class=""><br class=""></div><div class="">You can find benchmarks at: </div><div class=""><br class=""></div><div class=""> <a href="https://openwall.info/wiki/john/benchmarks" class="">https://openwall.info/wiki/john/benchmarks</a></div><div class=""><br class=""></div><div class="">Hashcat (<a href="http://hashcat.net" class="">hashcat.net</a>) is another good option. </div><div class=""><br class=""></div><div class="">Cracker programs like John and Hashcat assume that one has obtained the stored hash value of the targets’ passwords. Given the terrible state of enterprise security, exemplified by the recent log4j catastrophe, getting access to those hashes is too often possible. Cracking a user’s password on one, possibly less secure, system may facilitate an attack on their other accounts-- if they use the same password of course, but also if the cracked password reveals information on their password forming habits.</div><div class=""><br class=""></div><div class="">I got hacked earlier this year. I had set up an Instagram account way back when it was getting popular, just to see what it was all about. I didn't use a very strong password since I was just rubbernecking. Fast forward to Facebook buying Instagram, suddenly my throwaway Instagram account had access to all my Facebook addresses. Someone got into my Instagram account and spammed some of my Facebook friends. </div><div class=""><br class=""></div><div class="">Rigs with a dozen or so high end GPUs should be able to test a trillion passwords a second these days—that’s 40 bits of entropy per second. While password cracking is somewhat different from password cracking, the far higher hash rates achieved by miners using custom ICs strongly suggest that storing password data scrambled with fast hashes like the SHA family is doomed. NIST SP 800-63B briefly mentions this in the middle of lengthly paragraph 5.1.1.2, but I know of no push to implement these requirements in the Federal Government, much less in commercial use.</div><div class=""><br class=""></div><div class="">Like it or not, passwords are still the main defense for many systems and things are only getting worse. For my ideas on better ways to store password validation info see: <font color="#0068da" class=""><span style="caret-color: rgb(0, 104, 218);" class=""><u class=""><a href="https://www.researchgate.net/project/Rock-Salt" class="">https://www.researchgate.net/project/Rock-Salt</a></u></span></font></div><div class=""><font color="#0068da" class=""><span style="caret-color: rgb(0, 104, 218);" class=""><u class=""><br class=""></u></span></font></div><div class="">Arnold Renhold</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>