November 23, 2016

Tracking Failed Logins

ThisData customers start off by tracking successful log in events, but end-user protection is so much better when other events are sent through too. The more we know, the easier it is to spot unusual behavior.

The event we'll look at today is when a user (or attacker) fails to log in to an account. This can happen for a few reasons: the wrong username or email address, incorrect password, or perhaps failing to provide a Two Factor Authentication code.

Why track bad logins?

There are two key learnings you get from tracking this. The primary learning is being able to spot brute force attacks. It could be an attacker trying to access a single targeted account with lots of password variations, or an attacker using credentials from a breached database to find all the users who reused passwords. Another learning is that many users will get their password wrong the first time, because they can't remember it. In fact research shows that it often takes two or three attempts before they remember their password. Tracking this can help your product team make informed usability decisions.

70% of users forget their password once a month, and on average try 2.4 passwords before they get the right login"
Regina Dugan - Google SVP

How to track failed logins?

Let's learn how to track these failed logins.

The verb to send is log-in-denied. For the user ID, you should send it when you know what it is. Since user IDs must uniquely identify a user, if you send the same user ID each time then ThisData will treat those as all belonging to the same user. If you don't know the user's ID, or don't want to send it, that's fine too! We will treat them as belonging to a single special user, called "Anonymous". And you'll want to send a variable called authenticated, set to false.

Examples

Here are some simple example API requests you could make:

There was an unsuccessful login attempt for user account 12345:

{
  verb: "log-in-denied",
  user: {
    id: 12345,
    email: "[email protected]",
    authenticated: false
  }
}

There was an unsuccessful login attempt for an account which doesn't exist (The username and password were wrong):

{
  verb: "log-in-denied",
  user: {
    # The email is wrong, so there is no User ID
    email: "[email protected]",
    authenticated: false
  }
}

Congratulations! If you're sending through these events you're now able to detect brute force attacks, and more. Get in touch with your success stories or questions - we'd love to hear them!

Learn More

YOU MAY ALSO BE INTERESTED IN

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 ...