A translation might be in order here. Can't help you without it.
–
Technik EmpireJan 19 '14 at 13:09

1

Right, which you could easily translate to English for other users to give input. At this point, I don't have a clue what you're asking. You keep saying it's a joke as well, which makes me wonder if this is even a legitimate question. Are you waiting for a French speaking individual to help you? If so, I think that the question would be unsuitable since you're restricting access to the information within this thread to specific people. The text isn't even selectable, it's an image, so using translation tools isn't even possible.
–
Technik EmpireJan 19 '14 at 13:15

Well, the joke is about how password systems tend to work more than they are about how they should work; the refusal to diacritics is another case where many existing systems pointlessly reduce security and of course more annoying to those who use languages with heavy use of diacritics (like French) than those where they are rare (like English). Refusal to accept spaces is a related common flaw, though not as annoying as accepting them on setting and refusing them on actual password input.
–
Jon HannaJan 19 '14 at 15:31

3 Answers
3

You misunderstand what remember does for pam_pwcheck; see the man page:

remember=XX

Remember the last XX passwords and do not allow the user to reuse any of these for the next XX password changes. XX is a number between 1 and 400.

With this option, pam_pwcheck will reject attempts at reusing a password which was previously used by the same user. It does not do anything cross-users; it will not warn you about whether your password of choice is used by anybody else or not.

In fact, such a check would be expensive to implement if proper password hashing is in place (with salts and many iterations for slowness, it would take several minutes to "try" the putative password for thousands of other users). As you say, warning users about how a potential password is already used by another user would be, by itself, a serious security issue; but it would also mean that the passwords are not stored properly, and that is another serious security issue.

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.

I think the issue with non-ASCII characters is that they may have more than one representation, and the rules for which sequences of code points are equivalent are not constant. If canonical representations change, usernames and other clear-text data can be updated; hashed passwords cannot. If, hypothetically, Unicode were to in one year define a combining diacritic for Q with an acute accent, and in a later year define a code point for a Q-with-acute character, it may be difficult for a server to recognize them as equivalent (the only way it could would be to automatically...
–
supercatJan 19 '14 at 17:32

...have every attempted login attempt aautomatically try all representations of all characters in the password for which multiple representations exist--not pretty.)
–
supercatJan 19 '14 at 17:33

1

@supercat If Unicode added such a composed character, the composition would be an excluded composition for NFC.
–
Jon HannaJan 19 '14 at 18:43

A typed-in password will go through various parts of a system (keyboard driver, GUI handlers, password-field handling code, etc.) that may have varying knowledge regarding Unicode and the latest changes. If one version of a client computer's GUI handler returns an incorrectly-normalized string and the database software at the time doesn't recognize that the string isn't normalized correctly, how can one avoid or resolve the troubles that would result if the GUI handler is updated to fix the bug? One might hope such things wouldn't happen, but is all Unicode-handling code correct and bug-free?
–
supercatJan 19 '14 at 23:28

This doesn't answer the question. It's also partly wrong and incomplete. Using the user name as a salt is bad because it will be the same in other databases. MD5 vs SHA-256 isn't relevant here, MD5 is deprecated but not broken for what it is used for here. A password hash needs unique salt and it needs to be slow. Read How to securely hash passwords?
–
GillesJan 23 '14 at 8:37

1

@Gilles My favourite part of this answer is that it links to md5crypt not plain MD5 when it claims that md5 isn't secure anymore. While md5crypt shouldn't be used in new systems, it's still much stronger than plain SHA256.
–
CodesInChaosJan 23 '14 at 12:39