Dev diary: Phishing prevention behind the scenes

We recently released a new feature that prevents employees from reusing their SSO password on other sites. Our goal with this feature is to stop high-risk credentials from being compromised (via phishing or data breach). If you aren’t reusing your Okta password for example, there’s no risk of it being compromised in another breach, and any attempt to dupe a user into using it on a phishing site will fail.

To read more about why we developed this feature and how it works, check out this earlier blog post. 

While the concept for this feature is simple, we learned that there were several important nuances and design choices to make it both effective and practical:

• Should employees be allowed to reuse their SSO password if they’re doing it intentionally?

• If allowed, how do you give employees the right context to help them be sure they’re only reusing in the intended places?

• How do you make the content for an employee-facing feature work for all organizations?

• How feasible is it to block all password reuse without encouraging the wrong behaviours or workarounds?

• Where does threat intelligence fit into a password phishing prevention feature?

To warn or to block?

Fundamentally, the feature works by looking for when an employee enters their password for an app into somewhere that isn’t that app. Simple, right? 

The initial plan was that when detected, we’d block the form submission, let the employee know they almost got phished, and ride off into the sunset having saved the day.

Unfortunately, despite password managers becoming more popular, some people still use the same password across multiple apps. In fact, our data shows around 1 in 3 people reuse passwords between accounts and we actually see higher levels of password reuse on IdP apps in particular.

Since password reuse is so common, this feature would cause friction by forcing employees to change their reused SSO passwords. Some security teams will consider this a good thing, but others might not be so comfortable. To support both cultures, we introduced WARN mode, where employees are stopped from reusing their password, but they’re given the option to continue anyway.

Customizing block screen content

Through our app banner feature, we’ve already learned that orgs like to customize any messages their employees see. This helps them give company-specific information (like how to contact the security team), match the tone of the business, or even just deliver the message in the right language if that’s not English.

Adding helpful context

To help employees tell the difference between a phishing attack and their intentional password reuse, they need to know the context. Specifically, they need to know which password they’re about to enter and where they’re about to enter it. 

For example, a sensible default warning might look something like:

Are you sure? You're about to enter your Okta password into evil.com. This is not Okta.

This is distinctly different from:

Are you sure? You're about to enter your Okta password into openai.com. This is not Okta.

Although I shouldn’t be using the same password for Okta and OpenAI, this extra information gives me the context to make a decision about whether this is intentional. Hopefully it has the added benefit of making me think twice about my intentional password reuse.

This extra context means the message shown to the employee needs to be dynamic. Since we have also established it’s important for our user to be able to customize the message shown, we needed to support these as variables. As such, the final default warning message looks like:

Are you sure? You're about to enter your $IDP password into $URL. This is not $IDP.

Focusing the scope

This feature could be applied to all passwords to just forcibly prevent password reuse. However, applying it everywhere increases the chances employees will trigger this feature due to intentional password reuse on less sensitive apps. The more they see the block or warn screen, the less weight it will hold.

Password phishing attacks are increasingly targeting identity provider platforms such as Okta and Microsoft 365 and for good reason. With this in mind, we decided to reduce the scope of this feature to only monitor identity provider accounts. This means that when it triggers, it really matters. Hopefully, this ensures employees take the notice seriously.

In the future, if there’s appetite from our customers, we could open this feature up to let security teams choose which apps are protected, so you can apply it to other systems you might consider highly sensitive, such as GitHub or AWS.

Reducing false positives

It’s imperative the accuracy of this feature is high, since false reports have the potential to cause alarm or annoyance.

As our browser agent is already monitoring for password reuse, we were well positioned to ensure this feature wouldn’t trigger incorrectly by analyzing existing password reuse alerts. 

There were some unexpected examples we needed to make sure were handled correctly, such as the newtab page in Edge – did you know you can login to Microsoft 365 right inside the newtab page? Since the URL is not login.microsoftonline.com, this looks like strange password reuse! Also, certain shopping websites (which shall not be named) resubmit your credentials on every page, which caused the warn screen to be shown for each page visited.

Inside your organization, it is reasonable that you might have your own examples of this - sites which aren’t hosted by your IdP but use the same underlying authentication. To the browser agent, this would look like password reuse, even though it isn’t, because the URL is different. To manage this, the feature starts in MONITOR mode so you can see where, if anywhere, this feature would trigger, and you can build up an ignore list for the browser agent.

The threat intelligence question

We’ve come all this way and I’ve not mentioned threat intel even once! Surely that is a component of any phishing prevention tool? We considered it – and decided against it. Here’s why.

Primarily, you’d think threat intel could be used to detect known-bad sites and outright block them. And sure, we could do this, but we’d really just be reimplementing Google Safe Browsing. On the assumption we aren’t going to access a better threat intel feed than Google, we wouldn’t be adding anything above what your browser is already doing.

We hope this approach adds an extra layer of protection to the whack-a-mole of threat intel. Back in 2013, David Bianco introduced the pyramid of pain which captures this concept well. By generally preventing the TTP of password phishing, we hope to introduce much more pain for an attacker than focusing on known-bad indicators, such as domains.

Let us know what you think!

Give it a go, we’d love to hear how you get on and whether you have any ideas for how we could strengthen the feature in future.

I didn’t focus on it here, but hopefully it goes without saying that any account that uses a password should be backed with MFA. If you don’t have a good view of which of your employees are using MFA across your cloud identities, Push can do this for you too!