20

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]

|improve this question
  • 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. – Jon Hopkins Dec 2 '10 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. – David Thornley Dec 2 '10 at 18:03
  • 1
    Security vulnerabilities notwithstanding, couldn't you just reject the password if it fails to uniquely hash? – Robert Harvey Dec 2 '10 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 '10 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 '10 at 20:01
24

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

|improve this answer
  • +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 '10 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 '10 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. – Satanicpuppy Dec 2 '10 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 '14 at 17:12
10

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.

|improve this answer
  • 4
    +1 for offering some insight as to why someone might ask for unique passwords – Michael Haren Dec 2 '10 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. – Jon Hopkins Dec 2 '10 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 '10 at 17:58
  • +1 for pointing out that you can't do that if you're handling passwords correctly. – David Thornley Dec 2 '10 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 '10 at 18:02
10

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.

|improve this answer
  • 1
    What do you mean by "on-line" access? Is there another kind? – Robert Harvey Dec 2 '10 at 23:52
  • See the last sentence for the difference in security terms. – Gary Rowe Dec 3 '10 at 7:47
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.

|improve this answer
4

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.

|improve this answer
  • Yeah. This would be a good point to make. – PeterAllenWebb Dec 3 '10 at 16:11
1

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.

|improve this answer
0

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.

|improve this answer
  • Two-factor is useless for preventing man-in-the-middle attacks. – BryanH Dec 2 '10 at 16:16
  • True, but that statement doesn't seem to relate to the question at hand. – goodguys_activate Dec 2 '10 at 16:21
  • But now I know your 2nd factor!!! Oh wait...please update your picture – Michael Haren Dec 2 '10 at 17:05
  • 2
    Hmm, I think it would be cool to make that an animated GIF – goodguys_activate Dec 2 '10 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.