There are two ways to look at this. One is from a security aspect, the other is from a human use standpoint.
You may call it naive, but other people won't. Let me give a real world example. My boss has an executive assistant. My boss's assistant does things in my boss's name, including making calendar reservations, sending and reading e-mail, etc. Some people might say that an authentication system that forbids an assistant (or other delegate) from operating with the primary identity is naive, not the person with the assistant. Assistants are as old as human history.
If you allow my boss and his assistant to use the same account with different passwords, then your logging and auditing system can tell which one did which things (assuming, of course they keep their mutual passwords secret). If you don't let them do that, you know what they're going to do, don't you? They're going to just share the password. Come on, what's the security implication of that?
You can pretend to make the requirement go away by asking, "But who really needs to do that?" However, the obvious answer is, "Your CEO." Add to that anyone else who has a delegate, as well as accounts that are role-based, rather than person-based. For example, the accounts typically called postmaster, webmaster, root, abuse, etc. are role-based. You *want* more than one person to be able to share that identity, and you want them separable. The whole pseudo system in many Unix systems is there for separable use of root. It's needed. Why not put it in? Why not believe your customer when they tell you it's a requirement?
So let's look at the security issues. You've noted a number of implementation issues, but they aren't security issues. Make a decision. My own personal opinion is that you have to have inside of your system the notion of a "sub-user" or perhaps an external user versus an internal user. The best solution is to increment a counter based on the username/password combo and to lock out only that combo. If that turns out to be too hard for you to implement, then so be it. Tell your users. I think you're probably smart enough to code it up yourself. I've designed in my head a couple of solutions while typing this reply.
On the other hand, if I were the one giving you the requirement and you replied, "I can give you a simple solution in N days and a complete one in 3N days" I might happily nod and take the simple one.
But, let's sum up here: It's a requirement that some customer has given you. If you balk on it, two things will happen:
(1) You'll get in an argument that wastes a lot of time.
(2) They'll just start sharing passwords.
I think it's a lot easier to do what they want and sufficiently innovative that it will look good on your resume when you're done.
This was first published in December 2002