12

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?

  • How big is the company? How will the password be communicated to the employees? – Neil Smithline Dec 4 '15 at 21:10
  • 1
    @NeilSmithline for the purposes of this discussion, let's assume that the password is communicated securely but that there are no safeguards or policies to ensure users treat it appropriately. Assume a company headcount numbered in the dozens. – Jason Dec 4 '15 at 21:19
  • 9
    A password that everybody knows offers no security at, and a password that must be changed when someone leaves is (a) just a PITA and (b) no stronger than changing or deleting the password of the user who just left. It all seems completely pointless. – user207421 Dec 4 '15 at 22:39
  • Why isn't the user's specific password deactivated when they leave. Wouldn't that be sufficient to disallow the user (or anyone with their credentials) access? – user46053 Dec 4 '15 at 23:27
  • 2
    This scalability is a huge issue here (ignoring the security issues). Even at just a few dozen people as you mentioned, it would probably mean a new password would be needed a few times a year. I shudder to think how bad it would be if the company increased in size – David says Reinstate Monica Dec 5 '15 at 2:43
14

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.

  • 1
    Honestly I wish I could accept several answers, lots of good info on here, but this one gets at exactly the use, and limits, of the additional password in a way that I think covers the original question best. – Jason Dec 7 '15 at 14:46
26

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.

  • It's already company culture to use password managers, I can't guarantee each user's choice is secure from technical attacks but the social vulnerabilities are minimized by this. The choice of the access key method is not mine, and I'm debating recommending scrapping it altogether (i.e. rely on just user/pass) or figuring out an appropriate 2-factor alternative. – Jason Dec 4 '15 at 21:47
7

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.

  • Let's assume that the options are (a) said access-key scheme or (b) no additional security above user/pass, at least for the immediate future until such time as resources could be dedicated to adding that in. Are you aware of any 2-factor options that would allow the user to enter the additional security options with only the click of a button (e.g. for the access key method, not being proper 2-factor auth, they could use a secure password manager to manage the key rather than have to type it in each time)? – Jason Dec 4 '15 at 21:38
  • 1
    Honestly it can be pretty useful for protecting company-wide webapps and stuff like that. Someone scanning for vulnerable php software won't have access to the password, and while there's an ever-wider list of former employees with it, since it doesn't by itsself give you access to anything, it's still a security plus. I've seen them mainly used to add http auth to company websites (like the wiki). – Some Linux Nerd Dec 4 '15 at 22:07
  • @SomeLinuxNerd wouldn't VPN be a better choice for protecting company-wide webapps? – emory Dec 5 '15 at 19:27
  • 1
    it can be pretty useful for protecting company-wide webapps and stuff like that. - protecting against what? If the server is vulnerable then there's no guarantee this company wide password will ever be in play; no point having two locks on the front door if the window is wide open. This scheme as related by the OP sounds like thinking by a novice who hasn't thought of threat models or attack vectors and just thinks "if passwords are secure then more passwords must be more secure". – Rob Moir Dec 6 '15 at 13:36
  • @emory yah it would actually :) – Some Linux Nerd Dec 7 '15 at 3:52
5

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."

  • I like the second example because it is easy to visualize. However, isn't that just a defect of the mechanical combination lock - there is only one combination. If the combination lock allowed for multiple correct combinations, then we could give every lab worker their own combination. – emory Dec 5 '15 at 19:32
  • @emory Yes, it is. In the case of those labs, every worker is given the "access code," which is changed whenever anyone leaves, due to hardware limitations associated with the set of locks that are trusted for those circumstances. Those labs did a tradeoff and found that the trustworthyness of the simple combo lock was sufficiently higher than any of the more fancy tools that supported multiple users such that it was worth the usability cost of making everyone memorize an access code which changes when people leave. – Cort Ammon - Reinstate Monica Dec 5 '15 at 20:01
  • I have worked at a facility that required personal badge + pin access, had a combination lock, and had an alarm that used a separate badge + pin code. The two badges were issued by and controlled by two different agencies, and the combination changed annually and whenever someone who had it no longer required access to the facility. Maybe a dozen people had the combination, but hundreds of people had badges for it. – Randall Dec 5 '15 at 23:19
  • The threat model today would be script kiddies and disgruntled ex-employees. It's not that we don't want to protect against a targeted long-form attack, but rather that this is the low hanging fruit, the easiest fix with the broadest surface; we'll shut down the greatest number of attackers with the simplest fixes as a starting point. – Jason Dec 7 '15 at 14:40
  • I accepted a different answer, but I'd upvote you twice if I could for bringing up some useful thoughts on threat models. – Jason Dec 7 '15 at 14:54

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.