Citations for inadvisability of globally unique password

Question

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?

[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 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...
[/EDIT]

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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

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.