Whether or not you believe the risk to minimal is irrelevant.

So I would say it depence on the case, if you use it or not.

A good alternative could be having nice wordlists with you on external drive or somethign and you can automate jtr/hash cat to come up with some passwords fast. Or add a rule to john to check different combinations of the client organisation name or frequently used string that you think is likely to be part of a password.

First of all you can avoid sending the hash from the network of the client (if the test is internal). So this problem is solved as it will be impossible for anybody to match this hash to your client.

Secondly the majority of these websites are performing a check in their database to see if the hash is already cracked or not. In the above example the hash is well-known so in these scenarios it can save you time especially when it is impossible for them to associate the hash with your client. If the hash is already cracked by someone else and you discover it through this script then still you will mark the issue as weak password and you will report it. So in this situation the client still needs to change the password ( so the hash will change) so nobody will have nothing.

For me the only problem that I can think with the usage of this script is when a password is the name of the company. So in this situation yes all these third-party websites can associate the hash with the company. But someone can argue and say that if you don’t check a system for default or weak credentials as a pen tester then definitely you are not doing something correctly.

Does the client approve of you posting sensitive password hashes to a website which cannot easily be verified?

Does the third-party website attempt to crack (and therefore compromise) unknown password hashes?

Most testers I know would stay clear of such sites (on a penetration test at least) for the above reasons….