I am having a disagreement with a client about the user authentication process for a system. The nub of it is that they want each user to have a globally unique password (i.e. no two users can have the same password).

I have wheeled out all the obvious arguments against this:

  • It's a security vulnerability.
  • It confuses identification with authentication.
  • It's pointless.
  • etc.

Still they are insisting that there is nothing wrong with this approach.

I have done various Google searches looking for authoritative (or semi-authoritative , or even just independent) opinions on this, but can't find any (mainly it's just such an obvious faux pas that it doesn't seem worth warning against, as far as I can tell). Can anybody point me towards any such independent opinion, please?

EDIT: Thanks for all your answers, but I already understand the problems with this proposed approach/requirement, and can even explain them to the client, but the client won't accept them, hence my request for independent and/or authoritative sources.

I'd also found the Daily WTF article, but it suffers from the problem that Jon Hopkins has pointed out - that this is such a self-evident WTF that it doesn't seem worth explaining why.

And yes, the passwords are going to be salted and hashed. In which case global uniqueness might well be difficult to ensure, but that doesn't solve my problem - it just means that I have a requirement that the client won't budge on, that's not only ill-advised, but is also difficult to implement. And if I was in a position to say "I'm not budging on salting and hashing", then I'd be in a position to say "I'm not implementing globally unique passwords".

Any pointers to independent and/or authoritative sources for why this is a bad idea still gratefully received...

  • 3
    This is an odd enough idea that I think you're going to be lucky find much written about it at all. To my mind it's so obviously flawed that it wouldn't be considered as serious enough to write about by security experts. Commented Dec 2, 2010 at 17:36
  • 4
    I really, really hope you aren't storing plaintext passwords, but rather salted and hashed. If they're salted and hashed, it's going to be difficult to ensure global uniqueness. If not, then I don't care about your security, since I already know it's bad. Commented Dec 2, 2010 at 18:03
  • 1
    Security vulnerabilities notwithstanding, couldn't you just reject the password if it fails to uniquely hash? Commented Dec 2, 2010 at 19:24
  • Post edit, I re-iterate my answer - this is not a "won't" its a "can't" (because of the way passwords need to be stored) - so instead of explaining why its bad to someone who isn't interested you need to move back up the process and understand why the client feels that this is necessary in the first place.
    – Murph
    Commented Dec 2, 2010 at 19:38
  • 4
    Interesting that they trust you enough to design their system, but not enough to advise them on the design of their system.
    – Gary
    Commented Dec 2, 2010 at 20:01

9 Answers 9


Whenever a client tries to create a password that already exists, it receives feedback that some user already uses that password, usually a violation of the privacy agreement.

Next to that, usernames are much easier to guess (and if there is a forum, you could just find alot of usernames there) and you're hinting the user ways to hack the website.

There should be some page on the internet somewhere that describes the privacy agreement violation part, other than that it's just common sense: they'd basically be giving someone a key and a list of home addresses.

EDIT: Not close to authorative, but perhaps helpful after you explain them what WTF means: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx

  • +1 Also, most authentication schemes let you try as many usernames as you want, while only giving you three tries at a password.
    – Michael K
    Commented Dec 2, 2010 at 16:00
  • 1
    That WTF is for using the password as a primary/foreign key more than anything else. Well maybe also for plain text passwords.
    – Murph
    Commented Dec 2, 2010 at 16:54
  • 3
    +1: You should never ever ever let on that any other user has the same password. Talk about a massive security flaw...You could run brute force password attacks by changing your password repeatedly. That'd fly under the radar of a lot of monitoring systems. Commented Dec 2, 2010 at 20:11
  • Actually, in some contexts having a single field for a login credential would be reasonable, if passwords were required to be chosen so that some particular portion [e.g. the first letter] was unique. If one has 26 or fewer users, for example, one could say that each user has to pick a password that starts with a different letter. Such a system would be equivalent to having 26 distinct single-character user names, but would avoid the need to hit 'tab' or 'enter' between the name and the password.
    – supercat
    Commented Mar 14, 2014 at 17:12

Enforcing unrepeatable passwords leaks information

How? Because every time a cracker attempts to create a new user with a simple password your system responds with "Nope, can't have that password", the cracker says "Goody, that's one for the list".

Leaking information about your security is generally a bad thing. OK, third parties knowing the algorithm is fine (it needs peer review) but allowing a dedicated cracker to infer keys - bad, really, really bad.

Resources describing good and bad password management policies

Read this article by security expert Bruce Schneier for an in-depth discussion of password strength.

Read this PDF by security researchers Philip Inglesant & M. Angela Sasse for an in-depth discussion of "The True Cost of Unusable Password Policies". To quote from the conclusion:

Against the world-view that “if only [users] understood the dangers, they would behave differently” [12], we argue that “if only security managers understood the true costs for users and the organisation, they would set policies differently”.

False sense of security

So the client pipes up with, "If no-one has the same password then if one is cracked then only one person is affected." No. Everyone is affected because the cracker has demonstrated that your password system is fundamentally flawed: it is vulnerable to a dictionary attack in an on-line system. It should not have been possible for a cracker to attempt multiple guesses against a password in the first place.

For on-line access 6 characters is enough

Going off-topic, but I thought it would be worth mentioning for interested readers. In security terms an on-line system is one that has an active security management process monitoring and controlling access to the data. An off-line system is one that does not (such as having encrypted data on a hard disk that has been stolen).

If you have a password system that is on-line then you don't need high security passwords. The passwords only have to be sufficiently complex to prevent guesses within 20 attempts (so a simple "name of spouse/child/pet" attack will fail). Consider the following algorithm:

  1. Cracker guesses password using "root plus suffix" approach to minimise guesses
  2. Credentials rejected and further login attempts prevented for N*10 seconds
  3. If N > 20 lock account and inform administrator
  4. N = N +1
  5. Inform user that next login can occur at time T (calculated above)
  6. Goto step 1

For a simple 6 character password the above algorithm will prevent dictionary attacks, whilst allowing even the most inept user on a mobile keypad to get through eventually. Nothing will prevent the so-called "rubber hose attack" where you beat the holder of the password with a rubber hose until they tell you.

For an off-line system when encrypted data is lying around on a flash drive and the cracker is at liberty to try anything against it, well you want the most resilient key you can find. But that problem is already solved.

  • 1
    What do you mean by "on-line" access? Is there another kind? Commented Dec 2, 2010 at 23:52
  • See the last sentence for the difference in security terms.
    – Gary
    Commented Dec 3, 2010 at 7:47

Best practice gets in the way of meeting the requirement:

You can't do this because you don't know what the passwords are so you can't compare them because all that you store is the hash of the password and a salt (which you can store next to the hashed password). This is best practice, so that's what you do. Done.

Another edit: Doh! Hindsight is easy - you could still check for uniqueness because (of course) you have the salt... just shoot me now... of course you don't have to mention this detail to the client.

FWIW, its not quite as dumb as you think it is - the aim is to prevent groups of users agreeing and sharing the same password, which people will do in the belief that it will make their lives easier.

If applied with a requirement to change the password regularly and a constraint that prevents people from re-using a current or previously used password (at all, ever) and sensible "strength" requirements (or at least a pre-loaded dictionary of "blocked" passwords) you're going to get to a point, fairly rapidly, where the odds are not in the hacker's favour anyway.

Ok, my answer originally started with:

There's notionally very little wrong with this given a couple of provisos - most of which are that I'm being thick...

Inappropriate humour apparently - point was that if you don't have the globally unique constraint you're creating different opportunities, perhaps less dangerous - I don't know.

  • 5
    +1 for offering some insight as to why someone might ask for unique passwords Commented Dec 2, 2010 at 17:06
  • 5
    But it is a security vulnerability - if you are a user, enter a new password and you're told it's invalid you now know at least one user has that password. Combine that with other factors (say the language the word is in, or some context / meaning it might have to someone) and you've discovered a very limited number of options that could easily fall to a brute force attack - even potentially a manual one. Commented Dec 2, 2010 at 17:16
  • Erm, I didn't say it wasn't a potential problem, I said that it wasn't entirely as dumb as was suggested in the question because it prevents multiple users having the same password (which does happen) and which is worse if those passwords are weak in the first place. Allowing users access to a system at all is security vulnerability... but one we have to put up with and hence everything after that is a compromise.
    – Murph
    Commented Dec 2, 2010 at 17:58
  • +1 for pointing out that you can't do that if you're handling passwords correctly. Commented Dec 2, 2010 at 18:01
  • Can we also please note that my answer is that you can't test for uniqueness because you should be hashing the password anyway? So if I've got a downvote for suggesting that I'd like to know why?
    – Murph
    Commented Dec 2, 2010 at 18:02

I just want to reinforce Murph's answer. Yes, it's a security problem and there is information disclosure vulnerabilities in implementing it. But from the client's point of view, he doesn't seem to be too worried about that.

What you should point out is that it's physically infeasible to actually implement a "unique password" check. If you're salting and hashing password, and not storing them as clear text, then it's O(n) (expensive) operations to actually perform the uniqueness check.

Can you imagine if you have 10,000 users, and it takes 30 seconds to go through every user's password to check for uniqueness every time someone new signs up or changes their password?

I think this is the response you need to take to your client.

  • Yeah. This would be a good point to make. Commented Dec 3, 2010 at 16:11

If you have advised them against this course of action, and supplied them with reasons, I would take them at their word and just implement the system as they suggest. It may not be satisfying, but you have done your job, and they are footing the bill, so they ought to get what they want.

There is one exception. If the negative consequences of a system breach would be severe (e.g. if very private information is likely to be compromised by a security breach) you may in fact have a professional duty not to implement the system they want. Don't expect it to make you popular if you refuse, but don't let that be your guide.

  • "I can't legally do that" is a good response, given you can support it using the facts from these answers. Commented Jul 10, 2023 at 8:49

Obviously if I have the same password as someone else, that is either an incredible coincidence, or a re-used password, or a very weak password. (I once left a company and started there again four years later, and even though I was the same person, I was two different users. I might have used an old password if I had remembered it).

So you might have an indication of a weak password. But what you want to avoid is weak passwords, not duplicated passwords. If you have thousand users, a duplicated password would likely need 1000 guesses to find out, but one that needs a million guesses is already too weak. So to find weak passwords, finding duplicated ones is an awfully bad method.

In itself, two people having the same password is no security problem at all. What is a problem is some process having access to all passwords in your company. If a hacker manages to get that, it’s game over. Passwords shouldn’t be stored anywhere ever.

Another problem: As a hacker, I might be able to pick a username and try various passwords and have a tiny chance to find one users password. With this setup, I can try passwords and have a much much better chance to find that a password is used, and then find the user who uses it. So you make it a lot easier to hack into the company.


He would probably like RSA two factor encryption. If you're using Active Directory, or ASP.NET membership this is a no-brainer.

alt text

The hardware or software token generates a time dependent unique password that is followed by a PIN code. This together provides a unique password for each user.

  • Two-factor is useless for preventing man-in-the-middle attacks.
    – BryanH
    Commented Dec 2, 2010 at 16:16
  • True, but that statement doesn't seem to relate to the question at hand. Commented Dec 2, 2010 at 16:21
  • But now I know your 2nd factor!!! Oh wait...please update your picture Commented Dec 2, 2010 at 17:05
  • 4
    Hmm, I think it would be cool to make that an animated GIF Commented Dec 2, 2010 at 17:35

This is relatively easy to achieve, provided you don't allow users to choose their own passwords:

  1. Create and seed a secure PRNG with suitably long cycle time
  2. Use that PRNG to generate each password
  3. Ensure the PRNG's stored state is held extremely securely!

The security of the PRNG against prediction from previous values is obviously of critical importance here.

However, most users want to be able to choose their passwords, which would yield all the obvious problems with attempting to ensure uniqueness.


I've seen many systems where users enter a single string of digits to identify and authenticate themselves. This seems to be common practice for tasks like disarming burglar alarm systems. While entering six digits, preceded by a gap of a few seconds, may be more convenient than a two-digit user id, hitting enter, entering a four digit passcode, and hitting enter again, I would suggest that this shouldn't be treated as entering a single monolithic credential, but rather as a combination of a credential entry and a passcode entry.

If a system supports a maximum of ten supervisor credentials and 900 user credentials, it could reasonably securely allow users to log in by typing six digits and supervisors to log in by typing ten digits, with no need to press anything except digits when there are no erroneous entries. Following a successful entry, a long interval with no keypresses, or an unsuccessful entry followed by a moderate interval with no keypresses, use the first entered digit to select whether to expect a five or nine more digits (expect nine if the first digit is zero, and five otherwise). Then once the expected number of digits has been received, interpret either the first two or first three digits typed as a user identifier, and the remainder as a secret passcode. Every user or supervisor would have a different assigned six-digit or ten-digit code, which would contain either a three- or eight-digit secret passcode, but users could select passcodes in any manner they saw fit without regard for duplication, and someone who happened upon the system wouldn't be given any information about what users actually existed based upon the number of digits they were able to type, since any ten-digit sequence of digts starting with zero, or any six-digit sequence starting with any other digit, would be viewed as complete.

As an alternative variation, if there were a maximum of 300 users but some users might want longer or shorter passcodes, then one could specify that a user ID would need to be typed with a leading digit of 1, 2, or 3 followed by a three-digit passcode, or such a value plus three (yielding 4, 5, or 6) followed by a five-digit passcode, or plus six (yielding a 7, 8, or 9) followed by a seven-digit passcode. Changing a user's passcode length would require having the user also change the first digit of the ID, but an adversary would gain no information about what users existed or how long their passcodes might be.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.