Does an *additional* company-wide password offer any real security?

Question

So, let's say a company has what could be referred to as an "access key". Each user has their own username and password, and there is an additional company-wide access key that people must input with their username and password to access back end resources. When an employee leaves, the old password is removed and a new password is created and communicated to all users.

I don't believe such a scheme reduces security beyond a typical username/password combo. It could guard against the scenario where a user's credentials have been compromised on some 3rd party website but are no longer sufficient to gain access without the access key. It likely offers zero protection against a targeted attack, where it's probably simple to gain knowledge of the access key given its wide dispersal.

I guess my question is, can you think of any real increase in security this affords beyond the 3rd party compromise listed above, and do you feel the overhead of managing such a scheme is worth it?

Answer 1

Works Against Robots

Secondary credentials are useful against non-targeted scripting attacks.

It completely depends on what is being protected from who and from what. In my personal experience as a Linux web systems administrator this kind of secondary credential scheme works well to protect known web apps—like WordPress and other popular web-based systems—from brute force automated scripting attacks that exploit known flaws in those systems.

If—for example—you have a whole slew of web apps such as WordPress installed across servers and just don’t have the time or resources to patch each install whenever an update is released, a set of secondary credentials offers some basic level of protection beyond the normal patching and upgrade recommendations. I typically set an Apache basic auth password on the URLs for control panels and admin screens on those setups and just pass the credentials onto relevant parties via email without worry.

The recipients of those credentials could post these anywhere internally for all I care. Toss it up on a Post-It right on your desk; I’m fine with that. The main purpose of this kind of secondary Apache basic auth setup is not to prevent targeted attacks from someone like a rogue intern or secretary, but rather just stop the brainless scripting bot-nets of the world from using your systems for whatever junk they are designed to inject into known weaknesses on unpatched systems.

Useless Against the Living

Secondary credentials are utterly useless against a targeted attack.

That said, the concept of a generic set of secondary credentials combined with personal credentials is utterly useless against protecting systems from targeted attacks for many of the reasons outlined above. If someone at your company wants access to a system protected with a secondary set of credentials, they can obtain that password with little to no effort via trivial levels of social engineering such as just walking around and snooping around co-workers desks.

Past that, let’s say the systems are targeted by an attacker remotely. Email penetration and someone doing a dump of—and reading—an employee’s mailbox will eventually provide all the info one needs to access a system.

Answer 2

You would be infinitely better off using certificates or two-factor authentication devices than a company-wide password.

The company password method suffers from the issue of key distribution (how do you get it out only to employees, and timely enough), people forgetting or otherwise losing t it, and wide distribution greatly increasing the likelihood of compromise. I guarantee you it will become culturally engrained to give that company password to nearly anybody or write it on post it notes all over the office as the pain of rotations is borne on people with a new password that they didn't choose.

Answer 3

The company-wide password won't offer much protection. It will probably change often it medium/larger company. Users will end up writing them down on post-it. And as you said, a determined attacker will have absolutely no trouble getting that password.

Moreover, you'll need a system to securely distribute said password across your company, which is gonna be a non-negligible overhead to take into consideration.

As an alternative, have you thought about 2 factor auth? Either distribute a physical key, or using an app on a smartphone generating a token. When an employee leaves, take his key/revoke his access, all other user doesn't have to be impacted.

This would be considerably more secure than having one password for everyone and would undoubtedly be easier to implement.

Answer 4

In general it is useless, but there may be some odd side perks to consider.

In any security scenario such as this, step number one is always to develop your threat model. What are they trying to defend against? Script kiddies? Three letter agencies? Foreign nationals who will stop at nothing to hack your servers? Disgruntled employees? How long will you need to defend against them? Are you worried about a offhanded "You pissed me off, so I'm going to hack you" or a "I am so infuriated by your company that I will spend months planning and executing the perfect attack?"

I usually don't recommend this, but in this particular case, we may be able to think of a reverse threat model. We can look at the existing security (user/pass+access) vs your desired security (user/pass) and determine what threat models might distinguish between the two.

In both cases, an attacker must compromise someone else's account, because their own account was disabled or removed. Getting the username is always easy, so the difference is how hard is it to get someone's password plus the company wide access code vs. just getting the password?

The answer to this, as all good security questions is "it depends." How good are your employees at picking passwords? If you regularly find that people are using their own username or "password1" or their dog's name as a password, a company wide access code may be the only thing between you and a disgruntled employee hacking you! (of course, it also implies you have many other security holes). On the other hand, if acquiring someone's password is reasonably hard, the access code won't buy you anything. An access code would be given out far more freely than a password would, so if they can get the password, they can get the code.

So the only threat models which can distinguish between your solution and theirs are threat models which are worried about an ex-employee who can get ahold of another employees password (something we are trained not to give up in this day and age) but for some reason cannot get ahold of an access code that is explicitly shared between everyone. That's a pretty degenerate case.

Bruce Schneier loves to say "Security is always in a balance with usability." In this case, the usability of a shared password is nightmarishly bad. The security gained is quite minimal, if anything. The access code should be thought of as a bad security trade and dismantled.

There are two exceptions I can think of. One is that a company access code may be developed as a token to keep individuals honest. Consider the police badge. Itself, it's just a hunk of metal in the shape of a shield. However, it is a symbol which reminds people (civilian and police alike) that they are accepting a higher responsibility.

The other example is that I have seen labs where, for security reasons, everyone must badge in with their own PIN, but the badge reader is not trusted on its own. In addition to this badge reader and pin, they have a combination lock which is trusted. Every person working in the lab knows the code to the combination lock, so that they can open the lab if they are first in the morning. Once the combo is opened, and there is at least 1 authorized person in there, everyone is allowed to just use their badge/PIN for convenience. At night, the combination lock is locked. If anyone is revoked from the list, they must change the combination, because it was the part of the system that is "trusted."