December 20, 2016

It wasn’t me!

If you’re a big tech company like Google, Salesforce or Facebook then you’ve already felt the pain of users getting their accounts hacked. You’ve then gone and tasked a team of engineers to work on a way to detect an account breach and immediately notify the user about it.

It's an incredibly effective way to reduce the number of compromised accounts, which is why we're starting to see many more software companies follow suit.

How to detect a breached account

On the face of it, most developers will think about tracking IP addresses and possibly grabbing the User-Agent. They might use a bloom filter or similar as a quick way to check if that combination of IP and browser have been seen before for any given user.

This approach is valid, and to be honest it’s how we started out at ThisData. A simple approach to a seemingly simple problem. However it leads to many false positives because it’s not unlikely that a user comes from multiple IP addresses.

So then you start to think about building personalized behavior models for each user. Is this user a road warrior that spends all of their time on mobile and therefore has thousands of IP addresses, or do they work from home from the same IP everyday?

All of a sudden the simple becomes complex and you realise that doing an effective job of solving this problem will take a lot more thought. After all, if you have high levels of false positives then you’re probably spamming users with unnecessary notifications about their usage of your app.

Notifying the user

So let’s assume you have persisted with your breach detection and are happy with the level of false positive results. Now you’re thinking about how to notify the user about this suspicious access.

Ideally, you want to send an email or SMS to your user that tells them about unusual activity. You really want to think about how to advise and engage the user without freaking them out, or just getting sick of your spam. Avoid using strongly worded messages about being “hacked”. Just keep it simple and show them some details about the suspicious access.

Simple stuff like browser and location is enough here. Most users don’t need to know exactly how you came to the conclusion, just that you did now and they need to take action.

Containing the threat

Here is where it gets interesting. You have notified the user and they have confirmed that the suspicious access was not them. What do you do now?

This is where even companies Facebook, Salesforce or Google fall down. After all this great work to detect the threat and notify the user you have left them with decisions to make and work to do.

Often the notification will say “If this was not you, please log in to your account and change your password”, or for business oriented services it will say “ your administrator”.

The problem here is that you’ve created work for the user, or you’ve added to the ever growing list of alerts that some poor administrator is slowly working through. Chances are by the time the work is done the attackers have completed their mission and are in the wind.

As a way to dramatically increase response times and create a far better user experience I would suggest you give the user an option to interact with your notification message. It could be as simple as having “It was me” “It wasn’t me” buttons in your notification. This gives the user a quick way to respond and enables you to automate what happens next.

Typically, if a user indicates it was not them you will want to disable their sessions and force a password reset. You should also take the opportunity to have your detection models learn from the feedback which will help to further reduce false positives.

The up shot

The reality is that account takeover is the fastest growing threat facing cloud based apps and services today. It’s being fuelled by massive data breaches and dumps online and your users are getting caught up in the middle.

By implementing a system to detect suspicious access to your apps you’re at least giving your users a chance to protect their accounts. And by automating this system you’re setting up for scale and reduced support loads.

At ThisData, with low false positives - which means not sending unnecessary messages to users - we’ve seen fantastic response rates to these notifications. It enables a distributed approach to alerting, reduces fatigue for administrators, creates a better user experience, and most importantly lets you contain threats faster then ever before.

Start thinking about it over the holidays and when you’ve realised it’s more complex than you originally thought, take a look at using ThisData to protect your users.

Happy Holidays!


The future of authentication

Today I’m excited to announce a deal that we have been working on for the past few months and how that will impact the future of contextual ...

Introducing custom security rules

For the past few years we’ve been working hard to create a plug and play adaptive risk engine. We designed our core service using a mix of b ...