Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 8 down vote favorite

I am looking for an authoritative source to back up my position in a disagreement over password policy.

I am having a disagreement with 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?

I've found a Daily WTF article, but (apart from being too humorous to be authoritative), it suffers from the problem I've mentioned above - the inadvisability of this approach is so self-evident that it doesn't seem worth explaining why.

To clarify, I understand the problems and can even explain them to the client, but the client is reluctant to accept them, hence my request for independent and/or authoritative sources.

Any pointers to independent and/or authoritative sources confirming that this is A Bad Idea gratefully received...

share|improve this question
Has the client provided any reason underlying their desire for unique passwords? Sounds like something they either heard somewhere or which lies on a faulty assumption they're making. If there's a way to politely get to the cause for their weird request, that might help. – user502 Dec 3 '10 at 19:30
It's a "feature" of their existing system, and they want their new system to work the same way. (I know, I know...) – gkrogers Dec 4 '10 at 11:29
1  
Do you need a "source", or is an indisputable train of logic acceptable? – AviD♦ Dec 5 '10 at 17:24
Following on my previous comment, if they wnat security to be taken even half-seriously, they should outline what risk/s they're trying to mitigate with this requirement, and then you can discuss with them if its worth the tradeoff of elevating other risks via the vulnerabilities they're introducing. – AviD♦ Dec 5 '10 at 20:30

5 Answers

up vote 6 down vote

The article points out that the system leaks information: other people's passwords. Every time it rejects your password, you know that someone on the system has that password!!!

Maybe you can approach it from the standpoint of how expensive it would be impose such a situation since you only store salted hashes (or whatever) and not their actual password?

How can you detect if users share the same password? Does this mean you are storing the password?

I think you'll get some better answers, but you need to look more broadly at authentication issues. Start with the wikipedia link and understand the basic issue first. I really don't think you want to be handling the actual password in your central database (AAA).

share|improve this answer
Passwords will be stored in the db, but in salted-and-hased form. – gkrogers Dec 4 '10 at 10:04
1  
@gkrogers, then theres no way to check if the password exists - unless you're going to rehash it with each salt and compare that way - which is ridiculously expensive, as @rox0r stated... – AviD♦ Dec 5 '10 at 17:27
up vote 1 down vote

rox0r makes a good point--one reason there are no authoritative articles talking about the inadvisability of globally unique passwords is that they require combinations of other things which are covered by articles. You don't store user passwords reversibly.

Without storing passwords, there's no way to tell if new users are duplicating them--unless you do something tricky like using a bloom filter, but that definitely adds unwarranted complexity and increases the attack surface. Trying to be clever with authentication or encryption is a bad idea.

share|improve this answer
Well, you could compare hashes without salting them. Problem of course is that you wouldn't be salting them. – SteveS Dec 3 '10 at 19:43
It's a good idea, but a bloom filter won't work because it has false positives, but no false negatives. It is correct every time it tells you that no one is using your password, but it will sometimes be wrong when it tells you that your password is being used. Also, the bloom filter would need the unsalted hash to stick into the filter, and it can't handle deletions/password changes. Usually, you recreate your bloom filter after N number of deletions to overcome this. How do you re-create the bloom filter without the unsalted hashes at a later date? – rox0r Dec 9 '10 at 22:48
1  
There's a few approaches to deletable bloom filters; and the customer did not require passwords which were not duplicates to be 100% accepted. But it's certainly an ugly kludge, your larger point stands. – user502 Dec 10 '10 at 1:20
1  
Thanks for the links. Yes, you are correct. The problem was only stated as "don't let them use duplicate passwords," so false positives don't violate that. In fact, false positives would leak less information, but it would still be better to fix the underlying problem. – rox0r Dec 11 '10 at 19:20
up vote 1 down vote

Are they talking about assigning a globally unique password to each user, or ensuring that when a user changes a password, it's unique?

If the user is permitted to change their password, then the UI will expose other passwords by virtue of the error they get. Obviously a bad thing, and likely goes against their security goals.

On a related note, they may be interested in RSA two factor encryption with a hardware or software token. The token generates a time-dependent unique password that is followed by a PIN code. This together provides a unique password for each user.

If you're using Active Directory, or ASP.NET membership this is a no-brainer.

alt text

If you use RSA, you satisfy the client's request, and increase security in the process. I can't think of any other way to approach this solution that the moment...

share|improve this answer
up vote 1 down vote

After re-reading your question, I've decided to post a second answer:

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

This is a beast of an argument and it borders on a religious argument. Is there a way to falsify their claim? If not, give up NOW.

What does "wrong" mean in this context? Nearly every decision involving security is a trade-off. They could be "right," if their main goal is to make sure everyone has a unique password.

If their goal is security, then the onus is on them to show how the system is made more secure by the requirement. At the very least they need to show how it doesn't make the system less secure and justify the cost of implementation.

share|improve this answer
2  
Why are they insisting this - if you are the security professional hold to the standpoint that the security implications of this are very well known, so what they need to do is provide a business case why they want to reduce security and impact performance! – Rory Alsop♦ Dec 6 '10 at 18:29
up vote 1 down vote

Globally unique passwords are not bad in themselves. What can hurt is how that property is maintained. There are two main ways to get globally unique passwords:

  1. Luck.
  2. By implementing something which makes password storage weak.

"Luck" is safe: with high probability, users will choose distinct passwords: the probability of collision raises when the space of possible passwords shrinks, i.e. when users choose weak passwords.

Anything else which ensures password unicity is unsafe, if only because rejecting a user-generated password implies informing that user that the password he just chose is also the password of one of his colleagues. An actual implementation would also be either quite inefficient, or prevent use of salts; basically, if the system can efficiently detect whether a given password is in use or not, then an attacker could use that to crack all passwords in parallel. It is rather unavoidable.

However, the customer is always right. If he insists on doing something stupid, then you cannot prevent it; he is the one who is paying so he gets the final word. The best you can do (and that's also the least you can do) is to write a formal note warning him about the dangers of his approach. This conforms to your "duty to provide advice" and it will protect you legally when hijinks ensues.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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