I believe password crackers have a useful and valuable role within the security industry. I do not believe they should ever form any part of any operational procedure. The routine use of password crackers can only be a bad thing.

Password crackers simply serve to highlight the weaknesses of chosen passwords. If there is genuine concern about the weakness of passwords then routinely cracking them is not a solution. The only way to ensure passwords are not weak is to improve the validation rules used when they are initially chosen.

I have been advised to change CRACF so that it does not display the actual password found. I have chosen not to change it as I believe this would be misleading. I would feel uneasy about saying, here use this to check for weak passwords, when if it finds one it is obvious that it is one of three values but I'm not telling you which one. Lets face it most installations allow at least three tries so what's the point, other than to try and make the use of password crackers look respectable. Just because it says 'weak password' rather than giving the value found doesn't somehow stop it from being a password cracker.

The only occasions where password crackers can be justified in my opinion, is during reviews, or penetration testing or some other specific and non routine instance.

If you use CRACF and discover weak passwords are being used, then look to improving your password validation. Maybe the bottom line here is that RACF does not provide, as part of the standard product adequate functionality to ensure proper validation against weak passwords? Why isn't there adequate password validation as a standard part of a mature security offering such as RACF?

It has been kindly pointed out to me that CRACF finds not only current UserIDs within the RACF database, but also ones which have been marked as deleted and hence no longer exist. Many thanks for pointing this out, but as I believe it does not affect its ability to highlight the issue of weak passwords I have no plans to develop it any further.

This page last updated: