There is certainly an argument for corporate password cracking as a proactive measure – there's actually quite a narrow dividing line between scanning for "joe" accounts, where the password and username are the same, and scanning for other weak password strategies by dictionary attack – and I don't think anyone has a problem in principle with a systems administrator using appropriate tools to check for weak passwords. That is, as long as the admin remains within the bounds of their responsibility and respects legal or policy boundaries and doesn't inappropriately use or misuse access to users' accounts. Unauthorized access and/or modification is often specifically outlawed by legislation, such as the U.K.'s Computer Misuse Act, and there are also potential issues with quasi-legal standards and internal policies that may specifically address the legitimate privacy expectations of users within an organization.
But there's another concern with Reaver. Because it's based on exploitation of a WPS vulnerability, its authorized presence on a system is potentially useful to an attacker, as well as to a sysadmin. In fact, an administrator can only use it effectively by leaving systems at risk from a protocol that's known to be exploitable. It's a long time since I was directly responsible for any corporate systems other than my own, but if I were still in that sort of role my natural inclination would be to ensure that WPS was disabled wherever possible, and press for lockdown and/or upgrade if and where WPS was actually required, rather than leave one hole open while I could look for other cracks in the brickwork.
I have also been asked whether anti-virus can (or even should) detect Reaver. I'm not sure an AV-centric program could actively detect Reaver because of the nature of the tool, but in principle a security product could detect and flag the presence of the vulnerability, and maybe even evaluate the risk level. You could add pretty much any functionality to a security product you think appropriate, and, in fact, I often see customers and even product testers who assume that vulnerability scanning is (or should be) a standard add-on to AV heuristics.
In fact, AV-centric security software may include functionality to flag system updates that haven't yet been applied or certain known vulnerabilities in legitimate software, especially if these are known to be "of interest" to malware authors, and that's an entirely responsible approach to developing security software. The problems are that the more you extend functionality, the more dependencies and fragilities (and bulk) you introduce, and the more you perpetuate the myth that AV (or an internet security product incorporating AV) is perfect protection. If there is such a thing. There is no single, one-size-fits-all 100 percent-effective solution in my catalogue.
So, customers shouldn't place too much trust in AV vulnerability scanning functionality unless it's there in the product specification (and if it is there, maybe you're looking at a different kind of product). Anti-virus scanning is not the same as vulnerability scanning, even if that functionality may be there in some more general products. I can certainly tighten some screw with my Swiss Army knife, but I wouldn't expect to see it advertised as a cabinet-maker's tool-chest.
