in today’s cybersecurity environment, a password alone can’t be trusted to secure access to sensitive data. Image: Creative Commons; Christoph Scholz.
January 10, 2019

The basics of multi-factor authentication and single sign-on

 

Enter your details to sign up for NTEN updates. We'll send you about 3-5 emails a month and you can change your preferences at any time by clicking on a link in the footer of our emails.

First Name
First name required.
Last Name
Last name required.
Email
Email required. Invalid email address. You already have an account. Log in or reset your password.
Job Type
Please select a job type.

Beyond 12 is a national nonprofit whose mission is to dramatically increase the number of first-generation, low-income, and underrepresented students who graduate from college.

As CTO & Head of Product, I’m responsible for keeping Beyond 12’s technology and data secure. One of my first steps was to implement single sign-on (SSO) and multi-factor authentication (MFA) with Okta.

What is multi-factor authentication (MFA)?

We’re all familiar with the basic process of providing our username and password to “prove” that we are who we say we are. Since usernames are typically known (i.e. not a secret), your password is the single factor that’s used to authenticate your identity. However, in today’s cybersecurity environment, a single factor alone simply can’t be trusted to secure access to sensitive data.

Multi-factor authentication requires users to provide at least two different types of evidence (“factors”) to prove their identity. For example, users may be required to provide their password (something they know) plus a temporary code generated on their phone (something they have). This increases the likelihood that the user’s account will remain secure should their password become compromised.

Should we be using MFA?

Beyond 12 needed to streamline security and IT functions in order for the organization to continue growing to scale. A near-term priority for that effort was implementing MFA. If we assume that, sooner or later, someone is going to get phished, or get malware, or encounter something that might compromise one of their work accounts, then at the very least we need to make sure that everyone has MFA enabled to mitigate those threats.

Beyond 12 is entrusted with a lot of student data through its technology products and direct-service programs. Even if we didn’t have legal requirements to protect data in certain ways, it’s still ethically the right thing to do because we care about our students and we want to make sure we’re doing right by them. That includes making sure that their data is accessible only to those who should have access to it.

Whether or not your organization manages data that is tightly regulated like education or health records, all organizations should implement MFA as a kind of digital hygiene. Down the road — as your nonprofit grows, as your business model expands, as you start to gather more data — you’ll already have the right processes in place.

Got advice for deploying MFA in my organization?

Of course, every organization is different, but one of the most important things to keep in mind when rolling out any new technology is to understand your team: how do they use technology? How do they navigate change? How might this new program affect their key workflows? Making time to think through these questions will help you design a more human-centered plan.

While it may be tempting to make piecemeal progress, be true to your security policies and plan for the long-term. If you believe that all access to sensitive data should require MFA, then start with that—even if there’s going to be a bit of staff dissent—because if you roll out SSO without MFA, and then a few months later say, ‘Now that you’ve adjusted to that change, we’re going to introduce this additional one,’ then you’ll have to deal with change management twice.

These are the basic steps that Beyond 12 took to deploy SSO and MFA.

1. Make sure all critical applications are plugged in. This may be obvious, but it serves two key purposes. First, it eases the transition for your staff, who benefit from having one place to go for everything they need to do their work. Second, putting all of your critical applications “behind the wall” ensures that all your potentially sensitive data is covered.

2. Configure groups. Most IT leaders are familiar with group- or role-based permissioning. Beyond 12 created user groups within Okta that were based on the type of applications that group members would need. For example, software development applications are available to the engineering team, and core business applications for communications and collaboration are available to all employees. Contractors and partners represent other potential groups.

3. Set policies. Okta’s adaptive multi-factor authentication gives administrators flexibility to design security policies that are right for their organization. This includes allowing a variety of factors such as passwords, push notifications, mobile tokens, biometrics, and more. It also includes the ability to enable contextual access management that takes into account the user’s device, physical location, and network information for authentication.

4. Teach your staff. Change is hard, no matter how simple or necessary. You can’t over-communicate during a transition like this. Be sure to use multiple modes to meet your colleagues where they are. For example, Beyond 12 held time to walk each team through the transition, set expectations, and field questions; there were detailed emails; plus internal office hours. Every organization is different, but everyone likes to be supported through change.

5. Provide (and get) ongoing support. Make sure that your team knows where they can get their questions answered when they arise. It’s also important for technology leaders to invest in their own professional development. Check for available support or training options from your vendors and make sure all staff know how to access them.

What issues came up after implementation?

Beyond 12’s rollout of SSO and MFA went smoothly, and there were only a couple key questions that arose soon after implementation. The first was how often users would be prompted to provide a second factor. With Okta and many other tools, this is configurable. Another issue that came up was ensuring that team members can securely work offline by providing factors that don’t require an internet connection or cell service, such as a YubiKey or a one-time-password generator (Okta offers their own, but is also compatible with others like Google Authenticator).

What’s next?

Beyond 12 continues to partner with Okta to explore new services and functionality, including automated account provisioning/deprovisioning and custom integrations for new apps. Okta For Good provides ongoing support to nonprofits in a variety of ways including product discounts, pro bono services, and events like the Nonprofit Collaborative at Oktane (Okta’s annual user conference, which is free for nonprofits) and regional user groups specifically for nonprofits.

Chris Co
Chris Co is the CTO & Head of Product for Beyond 12, a national nonprofit that provides integrated college coaching products and services aimed to dramatically increase the college graduation rates for low-income, minority, and first-generation students. Chris leads Beyond 12's technology product efforts to scale their proven impact to reach 1 million students annually. Prior to Beyond 12, Chris spent seven years at Workday in product management, security architecture, and team leadership roles, and five years at eBay as a security engineer. Chris has volunteered with College Track and Big Brothers and Big Sisters of the Bay Area and has an unwavering passion for Beyond 12’s mission, paralleled only by his love for problem-solving and photography. Chris lives in Oakland with his wife and has a bachelor's degree in applied mathematics from UC Berkeley.