I am having a disagreement with someone (a client) about the user identification/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.) but 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?

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 wont'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...

  • 2
    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. Dec 2, 2010 at 17:36
  • 3
    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. Dec 2, 2010 at 18:03
  • 1
    Security vulnerabilities notwithstanding, couldn't you just reject the password if it fails to uniquely hash? 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
    Dec 2, 2010 at 19:38
  • 2
    Interesting that they trust you enough to design their system, but not enough to advise them on the design of their system.
    – Gary Rowe
    Dec 2, 2010 at 20:01

7 Answers 7


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
    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
    Dec 2, 2010 at 16:54
  • 2
    +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. 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
    Mar 14, 2014 at 17:12

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.

  • 4
    +1 for offering some insight as to why someone might ask for unique passwords Dec 2, 2010 at 17:06
  • 3
    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. 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
    Dec 2, 2010 at 17:58
  • +1 for pointing out that you can't do that if you're handling passwords correctly. 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
    Dec 2, 2010 at 18:02

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? Dec 2, 2010 at 23:52
  • See the last sentence for the difference in security terms.
    – Gary Rowe
    Dec 3, 2010 at 7:47

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 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. Dec 3, 2010 at 16:11

Just thinking in terms of appropriate place to ask the question, the IT security section of Stack Exchange should be a useful point for you. Try https://security.stackexchange.com/questions/tagged/passwords - a range of individuals focused on IT Security should be able to provide specific answers.


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
    Dec 2, 2010 at 16:16
  • True, but that statement doesn't seem to relate to the question at hand. Dec 2, 2010 at 16:21
  • But now I know your 2nd factor!!! Oh wait...please update your picture Dec 2, 2010 at 17:05
  • 2
    Hmm, I think it would be cool to make that an animated GIF Dec 2, 2010 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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