Posted 9 February, 2015 by Maya Richman

What we’re learning about roles, permissions and security

Image from page 404 of "Dante and the early astronomers" (1913)

Deciding permissions can feel similar to mapping the cosmos in the 13th century. (Credit: Evershed, M. A. (Orr))

As our engine room family continues to grow, we are also changing and strengthening our organizational digital security practices and policies. After considering our threats and risks, we discovered our digital Achilles heel: the backend of our website was only as secure as our users’ weakest account password. So we knew we needed to force strong and regularly updated passwords, and we had to be smart about who had access to what information. Beyond improving security, simplifying roles and permissions, by removing access to unhelpful dashboards and irrelevant buttons, could streamline the user’s work experience, while hiding some of the organizations core features from any potential attack.

We know that many other small organizations are in a similar situation – multiple users with access to potentially sensitive information. So, in keeping with our mission to document our evolving organizational security practices, we are documenting the ideas we think are transferable about our approach.

Mapping out Risks and Vulnerabilities

The most vulnerable access point to our website is through our growing list of user accounts and the strength of their login information.

We asked ourselves:

  • Who has access to our website? and Do they still need access?
  • How strong are their passwords? and How did we share their login information with them?
  • What can they access on the website? Forms? Form entries? All Posts and Pages?
  • What can they do and change on the website? Can they edit the php and CSS that make up the theme?

Because we have such a small team we decided to start with each team member and figure out what kind of access they would need to the website CMS. We created a table to plot out what kinds of content they may need to view, edit and delete, and what other actions they would need to perform on the website. The table included rows like: Can add plugins, Edit PHP, CSS and Can create and publish posts etc. etc. After determining what each user needed access to, we grouped them into categories like Technologist, Editor and Basic Staff.

Jabbermaster Project Manager
Edit Plugins          X
Publish posts          X            X


Configuring Roles and Capabilities in WordPress

We use WordPress, a popular free and open source blogging tool and content management system. Thankfully there is a large and active community of support around this CMS that we were able to leverage as we navigated the process of configuring our WordPress Roles and Capabilities.

These categories of team members became our WordPress Roles and the list of actions on the left side became the WordPress Capabilities (like delete_plugins or edit_others_posts) for those roles. Most content management systems allow you to create roles and permissions (capabilities) to limit access for users. If a member needed to edit plugins but never really edited the webpage content, we would only give them access to plugins. Hardening our roles and reducing the amount of capabilities to the barest minimum also helps us with workflow. Fewer unnecessary buttons and less options on the backend can help increase efficiency and reduce mistakes.

Now that everyone on the team has access only to the things they really need, we feel more confident about our website’s security. Even if one of the accounts is compromised, the attacker would not be able to see the whole picture or access all features, and we can sleep better at night knowing this. But we’re not quite done yet!

Enforcing Complex Passwords (or Passphrases)

Although each user’s access will be limited, we still don’t want anyone without an account accessing our website! So it’s important to enforce strong passwords for our WordPress accounts.

We installed a plugin that enforces users to make strong passwords while creating an account. A password like Maya1 will no longer cut it. This is helpful because it takes the responsibility to ensure strong passwords away from individual team member.

Regularly Changing Passwords

A strong password only means longer time required to guess it,  so it’s important to reduce the amount of time any one password is able to be guessed. Changing passwords might seem like a hassle but it could make a huge difference. We installed a plugin that enforces users to change their WordPress password when they first login which ensures team members who create the new user don’t have access to their passwords. We also are planning on having “Password Changing Parties” every three months to ensure the passwords remain new and strong. Here is a section from Security in a Box that can help you choose passwords and provides tips for remembering them. Using KeePass and adding an expiry date for passwords also can help remind you to make the change.

Strengthening organizational security and developing best practice is an ongoing process and this is just the beginning. We are happy to contribute to a growing body of documentation about organizational security practices and share our own success stories. What techniques, tactics and tools have you used to configure effective roles and permissions? How do you enforce strong passwords in your organization? Share your experiences, tips, lessons-learned and ideas in the comments below.

1 thought on “What we’re learning about roles, permissions and security”

Bennett Haselton says:

I would add: have all your users install an anti-virus program on any machines that they usually use to log in to the WordPress site. (I don’t know how the programs compare, but many say that the free ones like AVG are just as good as the ones that cost money.)

If you log in from a machine that happens to be infected, your password can be intercepted. I’ve seen examples of viruses in the wild that capture all passwords typed into password-protected forms. One researcher deliberately infected a machine with one such virus, used a fake login to log in to a dummy website, and a few hours later, observed an IP address in Asia attempting to submit the same username/password to log in to that site.

Unfortunately I don’t know a way to enforce the anti-virus requirement automatically, because there’s no way for a website to check that a client computer has anti-virus installed. So maybe it’s something that you can check everyone is doing when you have your “Password Changing Parties” 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

Related articles