Shared User Accounts for Temps and Volunteers

Aug 22, 2018

By Ali Ryder

8 min read

76 views

Here's the situation: one of the agencies within your community wants to use HIFIS 4. Everything seems to be going pretty well until they casually mention that they have a lot of volunteers, or students, or temps, and they typically just create one user account for all of these people to use. No big deal, right?

Well, actually, it is a big deal.

Within the IT world, it is very strongly recommended that user accounts are NEVER shared. There are several really important reasons why this is an issue. Here is a summary:

Auditing

We can't audit who is doing what in HIFIS. When the audit trail is not properly in place, accountability becomes an issue.

Let's say we have a username called volunteer. We might find out that volunteer deleted some case notes. They probably did it by accident. Maybe it was the result of bad training. So who did it? How can we fix the problem? We know someone needs more training, but who?

Or, more problematic, we see a newspaper article about a homeless person named Jane and her life story. Jane is concerned about the data breach; she did not talk to the press. We discover that the only user who has accessed Jane's account in the past 6 months has been volunteer. Probably, someone should be fired, but who?

Data breaches should be taken seriously, and sometimes they can be criminal offenses. Like this Ontario story about a nurse who sold personal information about new moms to companies trying to sell RESPs. Sure, an occurrence like that is unlikely, extreme even. But what is much more likely is that case notes and client files can be subpoenaed and defended in court, which is much harder to do when it's impossible to say who entered a given case note.

This is a violation of the first principle of Canada's Personal Information Protection and Electronic Documents Act (PIPEDA): Be Accountable.

Keeping Unauthorized Users Out

Let's imagine that volunteers come and go. They volunteer for a few weeks and then they stop volunteering. But you've given them the username and password for the volunteer account, so when they're at home, they can go log on to HIFIS and access whatever they want, even after they're no longer a volunteer. Even years later.

For shared accounts, you can't deactivate the account after the volunteer or temp staff leaves, because other people are using the account. So your former volunteers, students, and temps retain access even after they no longer need it, like in this story about a National Park Service former employee who kept access to the service's Twitter account and defied a presidential gag order. This is a violation of the fifth principle of Canada's Personal Information Protection and Electronic Documents Act (PIPEDA): Limit Use, Disclosure, and Retention.

So let's imagine further that a past volunteer logs in to HIFIS today, and browses around, and adds some phony data about how this client (who they have a grudge against) has more income than they're reporting, making them ineligible for some programs. Or maybe they book them out of a shelter, knowing that their bed will then be given to someone else. Or maybe they record a false incident, stating that the client was violent and issued death threats. Your other staff might notice that something was off, and report it to a supervisor. But all the supervisor is able to identify was that volunteer logged in today and did these actions. That doesn't seem suspicious. And we can't tell who it was that logged on. We could find the computer's IP address, but maybe it was a local coffee shop. So how can you make sure that only the current volunteers can log in?

Password Policies

There are password policies out there for a reason: making passwords hard to guess protects the password-protected information, and thereby the clients' privacy. There are a number of HIFIS 4 features that promote strong passwords such as forcing new passwords every few months, ensuring a particular password strength, and so on.

However, there's no point to these policies if passwords are shared anyways. Security breaks down. This is a violation of the seventh principle of Canada's Personal Information Protection and Electronic Documents Act (PIPEDA): Use Appropriate Safeguards.

Let's imagine we change the password every month in order to solve the previous problem of keeping unauthorized users out. So how do we let all the appropriate staff know what password they should be using? Probably by posting a sticky note by the computer. Or verbally, from one staff to another. But then anyone who hangs around enough, like clients, might easily learn how to figure out what this month's password is and login.

Maybe your organization even has strict policies about this. No writing down passwords on sticky notes. The only way to communicate the new password every month is via email. But now, maybe, you have twenty different email accounts that all state what the password is and will be for the next month. If one staff leaves the email lying around, or prints it out, or forwards it... well, you see where this is going.

Compromised Accounts

Once an account is compromised, the impact is high since many users share the same account. In other words, let's imagine one of the many users who uses the same account enters the wrong password several times and locks the account. Now nobody can do any work until an administrator unlocks the account, and maybe the administrator is on vacation.

Or, maybe you identify that someone has been using the account that shouldn't be. To counteract this problem, you force anyone using the account to log off, and change the password. But maybe you have some staff working off-site, doing home visits or street outreach, and suddenly they can't log in or do their job. And now we're back to the previous problem of how do we communicate what the new password is to the people that should have it?

Alternatively, anyone using the volunteer account can change the password and prevent anyone else from logging in. Or, perhaps a supervisor accidentally changes the rights to the account, now maybe everybody is unable to do book-ins or something else vital for the job.

Impact: Broader than Just Your Agency

Remember that in HIFIS 4, in most circumstances, clients are shared between service providers. When you go to the Client List, you'll see a list of all the clients within your Cluster, including ones you've never met or served.

That means that if one agency engages in a practice of sharing user accounts, every other agency's clients are also potentially vulnerable. A data breach at one agency could compromise data from all agencies. Security is a weak link problem, so it's in everybody's best interests to make sure the weakest links are up to snuff. You have a vested interest in making sure that all the agencies in your community are taking HIFIS seriously.

But It's What We Did in HIFIS 3

It may be the case that while using HIFIS 3, your staff may have had a shared username and password that they all used, or perhaps they just left HIFIS 3 running on the computer all day long.

There's a really important difference between HIFIS 3 and HIFIS 4 on this topic. HIFIS 3 was software installed on one computer. The user had to be physically present at that computer to be able to access any data. HIFIS 4 is web-based, so it can be accessed from ANY computer.

In HIFIS 3, shared usernames may have been an issue for some of the above issues, like auditing. But in HIFIS 4, there are a lot more issues caused by shared logins.

Okay, So What Do We Do About This?

There are a few things that you can do to solve the problem of shared accounts.

Make sure every agency understands the problem. Each agency (probably) has a privacy officer, who is personally responsible if there is a data breach. They are going to want to make their own jobs easier. For more information, read this White Paper by the SANS Institute on The Use And Administration of Shared Accounts, which goes into a lot more detail on the subject.
Require users to agree to rules of behaviour governing HIFIS 4 use, before they are granted access. These rules should include not sharing their password with anyone, and only using their own username to log in. That way, managers and supervisors can take action if they need to. Also, this practice can reassure cautious agencies - and cautious clients - that you are taking privacy seriously.
Require agencies to agree to rules of their own, promising to create user accounts only after users have undergone appropriate training, ensuring each user has their own account, and deactivating user accounts that are no longer in use. This way, a Service Manager, CE, or CAB can take action if necessary if an agency is not following the rules. This also reassures other agencies that you're not messing around when it comes to privacy.
Make it as easy as possible for users to use their own accounts. Try not to make password requirements too strenuous, and avoid having new users work even one shift without their own login. If they work a shift but can't record their case notes, it is really easy for a coworker to share their username and password, "just this one time..."

What's up with the Geographic Region field on the Client Vitals screen?

Converting Data to HIFIS 4: What You Should Know