11

I know this might be a bit subjective, but it's based on this popular question here. Hopefully this is acceptable.

The problem with that question and answer is that I can't send it to my boss and say "See, this guy on the internet agrees with me!".

So, what is a reliable and respected source that clearly explains why you should never give your password to someone, even an IT guy?

THE JOATMON
  • 571
  • 6
  • 14
  • 2
    How about https://www.grahamcluley.com/2015/07/password-help-desk/ ? Explains why the IT guy doesn't need your password - he can reset it. If anyone objects, point out that there may well be regulatory requirements to monitor who does things - if multiple people have the password for a given account, you can't tell which of them used it easily. If it was reset, there is an audit trail. – Matthew May 04 '16 at 15:25
  • I saw that article. The problem with that one is the context. If I present this to my boss it will look like I'm accusing our IT Admin of being a scammer, which I genuinely don't think he is, and they would defend that assumption and lose sight of the issue at hand. – THE JOATMON May 04 '16 at 15:27
  • Well, the general point is that it protects you from them being a scammer, and them from you being a scammer (you could send emails from your account, and claim that the IT admin did it, since he had your password). All answers are going to come across as one of these, since it's what the advice is defending against. Your IT person shouldn't be asking for your password - if they are, well, they might be a scammer anyway... – Matthew May 04 '16 at 15:32
  • 2
    @Devil'sAdvocate You are actually protecting your sys admin. When someone is doing something wrong on a device, you can point out that it could just as easily have been admin from IT, or anyone else, who has your password. – Dave May 04 '16 at 15:36
  • Is this for temporary debug/research of a specific problem, or are employees generally expected to share individual passwords with IT? If it's temporary, set a temporary password for use during debug, then reset it. (IT can probably do the first part for you anyway.) – user2338816 May 04 '16 at 23:40
  • @AviD is without a doubt an authoritative source – KDEx May 05 '16 at 02:52
  • Are you asking specifically about your OS login password, or passwords in general? – Scott May 05 '16 at 06:13
  • I didn't found anything more to the point, shorter and more accurate than the 4th § from this AviD's answer: http://security.stackexchange.com/a/5542/9792 . ••return•• The **password** was conceived to **prove** a person's identity. Don't play, don't hesitate, don't cheat with that. – dan May 05 '16 at 12:18
  • @Scott OS and Office 365 (Email, Sharepoint, Onedrive, etc) – THE JOATMON May 05 '16 at 15:30

3 Answers3

13

In a corporate environment, there are a few places you can look. Company Acceptable Use Policies generally will have a clause saying not to share accounts or disclose passwords. If your company is subject to certain regulations (PCI-DSS, SOC2, HIPAA, etc.) they will have similar requirements.

Because you want to communicate with your boss, there is a non-technical route you can take.

Those regulations and policies are based on the same general principle: liability. This is a legal concept that has to do with the idea that once you share that access (that is what you are giving them) then they are now liable for that access. In this case, you are sharing liability. What happens if the IT guy uses your account to do something illegal? Because it is your name on the account, you are primarily liable for that activity, but if it is a "shared" account, that liability is shared with those who have access to that account (the IT guy or the rest of the company). If it cannot be known who did something, then there are much fewer options to try and correct or remediate problems.

So, you can tell your boss that you simply do not want to share liability with the entire IT staff. Accounts are intended to be personal so that proper attribution can be made, and that lowers the risk for the company.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • We actually contract our IT work. The statement was that "they are insured and bonded" or something. You bring up a good point about regulations, we are a health IT company. I'll see if there are any regs around passwords and contractors. – THE JOATMON May 04 '16 at 15:32
  • @Devil'sAdvocate THERE WILL BE REGS! I can assure you of that. All you need to do is search your policies and regs for passwords (the fact that they are contractors won't matter) – schroeder May 04 '16 at 15:34
  • 6
    A health IT company that doesn't implement HIPPA/HITECH? You're in trouble my friend. – Dave May 04 '16 at 15:39
  • I keep finding verbiage like this on healthit.gov or other sites "Passwords are not revealed or shared with others." but I'm afraid since it's not very explicit that management will say "Oh that doesn't mean him" – THE JOATMON May 04 '16 at 15:39
  • 2
    @Dave show me where in HIPPA that you can't share passwords to auxiliary systems. Seriously, please show me. – THE JOATMON May 04 '16 at 15:40
  • 2
    If they wanted me to give him a password to a system with PHI I would laugh in their face. This is for Office 365, which he is an administrator. – THE JOATMON May 04 '16 at 15:50
  • 2
    https://www.hipaasecurenow.com/index.php/6-things-organizations-are-doing-that-are-not-hipaa-compliant/ – schroeder May 04 '16 at 15:50
  • OK - Office365 is where things get tricky. That gives the other person your email access (Outlook, I assume) and your documents. If there is PHI or PII in those documents or emails, then it's a no-brainer for HIPAA (but then you have other problems). But if not, then you probably can't claim HIPAA. – schroeder May 04 '16 at 15:53
  • 2
    I just realized another issue. Though the specific password did not provide direct access to PHI, it does allow logging into my PC. Some of the apps I do use to access PHI cache passwords. I know this in itself is bad, but it is what it is. This means giving him my password would potentially give access to PHI. – THE JOATMON May 04 '16 at 20:20
  • 5
    @Devil'sAdvocate there you go – schroeder May 04 '16 at 20:53
6

An authoritative single source for this may be hard to find as it is, ultimately, subjective. However, not sharing credentials is a fundamental expectation of our current computing paradigm. The use of logins and passwords is fundamental to this reality and to step out of this violates that paradigm and every system that has been built around it.

Access Restricted Resources

IT restrictions are similar in intent to a locked file drawer or a bank safe deposit box. It's similar to laws and general expectations regarding opening other people's mail. Sure that hallmark card with a signature isn't sensitive per se, but it has a specific intended audience and access list.

Regardless of the contents and their meaning or value, the items are protected and access has been restricted. Obviously we could argue about value, sensitivity, etc. but that's after the fact.

Impersonation

You don't walk around with your co-worker's name, building access key, or sit at their cubicle. Why would you use their IT resources? All of the issues and concerns of impersonation in a physical setting exist on networks and disks. The impersonation risks are greater given the ability to identify this impersonation is lower and the potential length of impersonation lasts longer with system credentials.

Most Businesses are "at will employers"

As such, and since you are likely accessing their resources, through their systems, your only actual line of legal defense is to quit. The nuances of this, including issues of BYOD is likely out of scope for this site or at least my area of expertise.

The secondary aspect of this though, is that the business already, likely, has access to everything you have or are doing. A good business prompt is risk vs. reward. For no reward you gain significant risk for all parties. The password receiver is now, as noted by schroeder, liable for actions taken under your credentials. You are liable to any actions that anyone using your credentials takes. Who's the next person to get the password? Even if you trust everyone completely, do people make mistakes? How might those impact individuals and the organization?

Additional risk arises as the business is fostering an environment of credential sharing and risks all resources through erosion of basic best practices that counter (spear) phising, social engineering, keylogging, principles of least access, and more. Is the person asking your credential actually tier 1 support? You have nothing of value on your computer, but who in-turn will give "you" their password?

As a final aside, HIPPA/HITECH does not, from my understanding, have specific wording for passwords or password sharing. That's how you make a "good" law though. The ability to meet the numerous data security, segmentation, and auditing requirements is not possible in an environment where credential sharing occurs. When people share passwords then ACLs are meaningless and auditing is essentially forgery of actual access. From my plebeian perspective, this is a violation of federal law.

***Note I speak/write colloquially with "you"s and don't mean to indicate Devil's Advocate but rather any general reader or person this may apply to.

Dave
  • 442
  • 3
  • 13
-5

No, there cannot be an authoritative source because the statement is not true. There are times when you should give your password to other people.

There are plenty of scenarios where the benefit of providing your password to someone is greater than the cost of the worst case scenario of providing them your password, and where logging in for them is made impossible within the required timeframe.

To take a trivial example (although there are plenty that could apply to work), a friend staying at your house who wants to watch your netflix while you are at work.

Scott
  • 192
  • 4