Passwords: a never ending nightmare
Anyone who has been in information security for long enough knows the complexities of maintaining passwordless security at organizations of all sizes. From keyloggers, phishing emails, to password reuse, it seems like passwords are a never ending security headache for practitioners everywhere. Over the past few years, we have begun to see a movement towards a world that is less reliant on passwords. Yet despite this progress, we aren’t quite there yet, with a majority of web applications still requiring users to create a password upon sign up. That being said, there are quite a few tools that are helping security teams reduce the burden of educating users on best practices when it comes to their passwords.
As with many startups, we initially got started with Google Workspace and encouraged our employees to login with Google whenever possible. This was to take advantage of the fact that Google Workspace has 2-step verification built-in. As many of you may know, however, there are still many websites that do not support SSO of any form. We immediately rolled out 1Password to all of our employees to mitigate this risk from Day 1.
Over time, we still ran into issues with users forgetting their passwords, reusing passwords across accounts, or users simply getting frustrated over the user experience when 1Password failed to autofill on certain websites.
Our next step was to roll out Okta for all employees to streamline the user experience. We discovered that a high amount of applications had SAML support even though we weren’t on Enterprise plans. Even with this change to Okta, we ran into the issue of users forgetting their 1Password password, and subsequently, their Okta passwords after PTO or other extended breaks.
A new way to login
Luckily for us, Okta rolled out their Okta Identity Engine, which came with a new set of tools to allow us to streamline the authentication process, while actually improving security. After a brief testing period, we were able to roll out a new, more efficient process for our employees to login to their everyday applications.
The first step we took was to deploy the Okta Verify agent to all employee laptops via Jamf. Okta Verify acts as a built-in MFA on the local device where it’s installed, allowing the user to verify their identity through their laptop (mobile versions of the agent are also available). Not only does this reduce the need for yet another app, like a separate authenticator app, to be installed on personal devices, but it also allows users to use macOS’s Touch ID feature as a login factor for Okta.
We received positive feedback from users who preferred this experience as opposed to always having a Yubikey connected to their laptops. In particular, the Okta Verify agent on desktop allows users to login using Okta FastPass, which, with the click of a button, opens the Okta Verify agent for a Touch ID prompt without the user having to enter their username. All of this makes for a more convenient experience for the user.
After a few weeks, we decided to make passwords optional for most users, allowing them to login to Okta apps without ever having to enter a password.
Next, we decided to classify our applications based on risk level, and grouped them into separate authentication policies. Higher risk applications such as GitHub were configured to always require 2 login factors. Meanwhile, less sensitive applications such as Curricula, our security awareness training tool, simply require one login factor. For the most part, our employees did not notice any major changes or issues.
Finally, we decided to take advantage of Okta’s ability to act as a certificate authority to restrict certain applications to company owned devices only. With Okta as a CA, we were able to deploy this certificate to all of our employee laptops using Jamf Pro. This allowed the Okta Verify agent to determine if a device was managed or not. To make things better, Jamf Pro has an option that forbids users from exporting the certificate secret using Keychain Access, thus preventing them from registering a non-corporate owned device. We then updated our authentication policies for high risk apps to require logins from a managed device, severely reducing the likelihood of unauthorized access.
Considerations
While we are quite happy with our new Okta configuration, it should be said that this didn’t come with some occasional issues. In particular, the Okta Verify desktop agent can occasionally crash and stop responding. When this happens, Okta may not be able to detect that a device is managed, and users will not be able to use Touch ID as a login factor. To account for these scenarios, an Okta admin can add a non-Okta Verify authentication policy for non-managed/registered devices, such as requiring a Yubikey + Email verification for login.
In addition, we have seen issues with 1Password users that failed to link their Okta accounts within the appropriate grace period. Admins may want to exclude employees who are on extended PTO or leave to prevent them from being locked out upon return.
Finally, we ran into an issue with Microsoft Office’s federation configuration that still requires users to enter a password as a login factor. For this reason, a small subset of employees who use Office 365 still use passwords as a login factor. We hope to see this issue resolved in the future to have a true passwordless Okta setup.
That being said, overall we consider this project to be a success, with minimal complaints from users, all while improving the overall security of our SaaS authentication process.
