[Cryptography] Brute-force password crackers?

[Arnold Reinhold]

On Thu, 23 Dec 2021 15:54:39 +0000 Henry Baker asked:

> Could someone please explain the current strategies of brute-force password crackers these days?
> 
> I presume that huge dictionaries of existing passwords, words, phrases, etc., + brute force alphabetic enumeration in order of probability?
> 


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. 

I suggest you look at John the Ripper Jumbo, which is a very capable cracker with many options that is currently community supported:

  https://github.com/openwall/john

You can find benchmarks at: 

  https://openwall.info/wiki/john/benchmarks

Hashcat (hashcat.net)  is another good option. 

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.

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.  

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.

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: https://www.researchgate.net/project/Rock-Salt

Arnold Renhold





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20211226/0362d516/attachment.htm>