I'm currently working on an Web authentication project. The client wants to allow two users to have the same username. The users will be differentiated by their passwords. In the case that there are two users with the same password, the system should select one of them according to a given policy.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

It seems to me that this approach is naive and raises plenty of security issues. I'd like to find either some good reference that explains why this is not acceptable or some good example of security leaks this policy could cause. For example, what does the system do when a user types a wrong password? Usually a system implements some policy that limits the number of retries. How can you implement something sensible if you have two users with the same identifier? Do you increment the number of wrong retries for both? What do you do when both the counters reach the maximum number of retries? Do you lock both users?

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.

Is that what you want? It's what you'll get.

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.

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy