pam_pwcheck only remembers passwords for a given user, as the other answer says.
The other part of the question is, "What could be the goal of this kind of check?"
There are indeed systems that do checks of all existing passwords. Generally such systems are either storing passwords in plaintext, or an un-salted hash that doesn't depend upon the username or anything else that would prevent a match being quickly found. I've come across this as a user, as a functionality request (which I have refused as impossible to do with any reasonable means of storing the password, along with being inherently flawed as per below) or as an objection to fixing the use of plaintext storage.
And the goal is two-fold:
Since passwords should be hard to guess, the ideal would be if they were close to random in terms of unpredictability (the problem of remembering the password is another matter*, and one often forgotten when people develop a new enthusiasm for password strength). Since intuitively, random means there is little in the way of repetition (something anyone here will likely know is a fallacy but certainly a fallacy that is held), then repetition is hence a bad sign.
More reasonably, if someone else is using the password, it likely is a weak password that we couldn't detect (e.g. using details of a company office like the phone number to create the password in a way that another employee might try but otherwise passes strength tests), that could be guessed, as essentially the user has indeed just guessed it.
The flaws with the first thought is the flaw of not understanding repetition in randomness, and with expecting perfectly random password unless backed up with a policy that allows hard-to-remember password to be securely remembered.
The flaws with the second thought are:
- We need to store password relatively insecurely in order to make the check in the first place.
- We've just leaked a password to someone.
- We've likely identified a weak password, but not warned the person actually using it.
But still, those flaws don't mean it doesn't happen. There is after all another flaw in the system in the joke; refusing carottegéante because of the diacritic. There are technical reasons to refuse diacritics in various places (though unless you're having to interoperate with other people's code, those reasons are utterly inexcusable in modern code), but I've rather bizarrely seen it refused by systems that would accept diacritics in usernames! Likewise many systems refuse spaces in passwords, and so on. Generally, I'd put this down to cargo-cult programming; someone else did it, so you copy it. To a degree this isn't entirely unreasonable; I certainly copy what those that know better than me do when it comes to security, so I wouldn't entirely blame someone for blindly copying such policies. Still, it takes only a short pause to realise that there's no way that accepting "jdiwmfojkslofklo" but not accepting "ﬤסּוּﭞﻘﺪӐӓҾӌȕ" improves anything, and indeed it reduces the range of possible passwords to attack.
Anyway, the rule some systems have against spaces gives us an approach to translating the joke into English; make the second password attempt "giant carrots" with a space.
*That's what post-it notes are for, isn't it?
