Okta Response to Security Report

On July 19, 2022, a security consultancy released a blog post with claims related to the security of specific features of the Okta service. Prior to the release of their blog post, the security researcher reached out to Okta, sharing the technical details of their findings. After a thorough review, our internal product and security teams affirmed that the areas of concern highlighted are not vulnerabilities. We highlight below a number of security best practice recommendations.

Our goal is to support our customers on their terms, working with their requirements and integrations to help ensure they can connect to whatever technologies they need. We support a wide range of configuration options as we have a large number of customers with unique challenges that they need to solve. Some of these configuration options are less secure, such as enabling HTTP instead of HTTPS. We also provide synchronization capabilities that include the use of clear-text credentials in support of migration scenarios, system integration, and extensibility, enabling customers to solve complex use cases. Cleartext passwords are collected during authentication events for immediate synchronization with systems that require this. After synchronization we store Okta-mastered credentials in our cloud service, using the bCrypt password hashing algorithm with a high number of iterations and unique salts.

What to do if you are an Okta customer

If you are an Okta customer, we advise the following best practice recommendations, which you should consider in the context of your specific configuration.

1. Always use HTTPS to ensure the secure transmission of data.
2. Enable MFA for all user accounts. MFA on an admin account is non-negotiable and is enabled by default in Okta. Okta encourages all users, not just admins, to require MFA on their accounts.
3. Perform periodic access reviews of admin role assignments and ensure that admin access is limited to authorized personnel.
4. Consider the use of delegated administration scenarios with the custom administrator roles framework to grant fine-grained permissions.
5. Monitor and periodically review the actions performed by admins recorded in the Okta System Log, the logging platform in every Okta administrative console. 
6. Ensure that the Sync Password feature is enabled only where required. This feature provides the capability to push passwords to downstream systems to synchronize them with Okta and is used only in special cases for interoperability and hybrid identity deployments. This can be automated with the Apps API and Roles API.
7. For customers who use a Federated identity provider, review the RegEx Filter and ensure this appropriately restricts authentication to the intended subset of users.
8. For customers who use a Hub and Spoke architecture (also known as Org2Org):
   1. Review the identity providers configured to ensure these are trusted. 
   2. Review the use of the name duplication feature that controls whether the Spokes are able to create users within the Hub. To turn off this feature, you can disable the “Update attributes for existing users” option. 

Our continued focus on security

We are continually iterating and improving on the features and functionality of our products and rely on the feedback of a number of different groups - including customers, partners, security researchers, and even our own employees—to identify ongoing product enhancement opportunities. 

Below I have outlined some of our recent product investments that demonstrate our commitment to delivering an even larger variety of robust security controls and better defaults.

Okta Identity Engine

In March 2022, we made the Okta Identity Engine (OIE) available by default to all new Okta customers. OIE includes key capabilities to build a modern, secure identity and access experiences such as:

1. App-level policies
2. Sign-On Policy Defaults
3. Passwordless Sign-in Experiences & Device Context
4. Flexible Account Recovery

App-level policies

“App-level Policies” is a new policy framework that allows organizations to model security outcomes for access based on industry-accepted digital identity best practices (outlined by NIST). OIE organizes authentication methods into authenticators, and exposes the type of factor and the specific characteristics in a way that allows the administrator to create authentication assurance policies that match the app authentication security requirements.

At a high level, App-level policies enable administrators to set up sign-on policies in the following way:

• FOR [a given application]
• IF [a specific user context]
• THEN [apply a specific authentication]

The IF + THEN combo creates a specific assurance level. It is usually advisable to define a set of abstract levels (like low, medium, and high) and then map the applications to these levels based on their sensitivity and security requirements.

In summary, app-level policies are a new modern framework that allows organizations to model security outcomes for access on a per-app basis. Authenticator assurance is the foundation of app-level policies. You can find detailed documentation on App-level policies here.

Sign-on policy defaults

We recently upgraded our sign-in policy experience to address common misconfigurations that would increase account takeover risks as part of our larger secure by default auditing. As part of this effort, we shipped a new HealthInsight security task to notify admins when a risky MFA configuration is configured. You can find detailed documentation on this feature here. 

You can find the API here: https://developer.okta.com/docs/reference/api/policy/#global-session-policy

Passwordless sign-in experiences and device context

Okta Fastpass enables passwordless authentication into everything you need to get your job done across devices. Here are four key benefits of Fastpass:

1. Always on passwordless: Passwordless authentication and login from any device or location to any Okta-managed app.
    
2. Any device management tool: Passwordless login with no dependency on Active Directory join or a specific EMM (enterprise mobility management)/MDM (mobile device management) provider.
    
3. Combine with device-level biometrics: End to end (from login to app access) passwordless on devices that support biometrics (login to the device with biometrics, no additional prompts when accessing Okta-managed apps).
    
4. Check for Device Trust: Optionally, combine Device Trust with Okta FastPass to deliver passwordless only on managed, compliant devices.

Flexible account recovery

With OIE, Okta expands the choices of factors that end users can use to reset or recover their credentials to include Okta Verify Push. Flexible account recovery is comprised of three sub-features:

• Password change
• Password reset (forgotten password)
• Unlock account (account recovery)

When leveraging Okta Verify push for flexible account recovery, the customer can require end users to change or reset passwords or unlock their user account using two factors. This enables customers to retire the use of security questions that are inherently insecure. Detailed documentation on how to configure flexible account recovery is available here. 

Custom Admin Roles

Earlier this year, we made Generally Available (GA) a significant new platform capability for delegated administration scenarios with our new custom administrator roles framework. This feature has been adopted by thousands of customers to help reduce the number of over-permissioned administrators. Okta product teams are leveraging this new capability to incrementally introduce more fine-grained permissions to existing product functionality. For example, we recently added permissions for authorization servers and customization.

Administrative roles and permissions can easily be audited for your organization by generating a report making it easier to determine over-permissioned accounts.

You can find the API here: https://developer.okta.com/docs/reference/api/roles/

Origin-based IFrame embed permission

Customers have had the ability to embed Okta as an iFrame into legacy solutions. This capability has significant security implications and requires a deep understanding of the web security model to configure. We recently moved this global capability to our “Trusted Origins” framework to enable customers to more finely scope this privilege to a specific origin, dramatically reducing the blast radius. 

You can find the API here: https://developer.okta.com/docs/reference/api/trusted-origins/

Finally, this is a great reminder that regular reviews of security settings and configurations are key to staying ahead of threats. Okta customers who want to increase the security of their organization can utilize our online product documentation to apply the most secure settings.