{"__v":0,"_id":"582b70ce07efc00f00d33073","category":{"project":"56008ba98c0c9d0d00dcaeb0","version":"5719767ec863120e0012a042","_id":"582b71b15403840f008c0410","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-11-15T20:36:01.349Z","from_sync":false,"order":2,"slug":"faq","title":"FAQ"},"parentDoc":null,"project":"56008ba98c0c9d0d00dcaeb0","user":"56008b651503430d007cc929","version":{"__v":4,"_id":"5719767ec863120e0012a042","hasDoc":true,"hasReference":true,"project":"56008ba98c0c9d0d00dcaeb0","createdAt":"2016-04-22T00:55:26.295Z","releaseDate":"2016-04-22T00:55:26.295Z","categories":["5719767ec863120e0012a043","5719767ec863120e0012a044","5719767ec863120e0012a045","5719767ec863120e0012a046","5719767ec863120e0012a047","5719767ec863120e0012a048","5719767ec863120e0012a049","57f45a18da14e71700d12e4a","582b71b15403840f008c0410","58c060cf3eee111b00a8b210"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"2.0.0","version":"2.0"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-11-15T20:32:14.845Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"When a password is incorrect, but the username or email address is correct, we can track failed login attempts to their account. This is useful for detecting when an attacker is trying to guess someone's password.\n\nThe `verb` to send is `log-in-denied`. \n\nThe `user_id` to send depends on your use case. 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. This is true for all event types. If you exclude the user id field, we will treat them as belonging to a single special user, called \"Anonymous\". \n\nHere are some examples, all of which are valid choices.\n\n### You want failed logins to show up alongside any other events for that user\n\nIn this case, you send the user's ID, and [`authenticated: false`](http://help.thisdata.com/docs/apiv1events#section-user-s-authenticated-status). Failed logins are tied to the user who got their password wrong, or the account an attacker was trying to access. If the username _and_ password were wrong, do not send a user ID.\n\n`{verb: \"log-in-denied\", user: {id: 12345, authenticated: false}}`\n`{verb: \"log-in-denied\", user: {id: 67890, authenticated: false}}`\n\n### You want failed logins to be kept anonymous\n\nIn this case, you should not send the user ID at all. We will automatically group all events without a user ID under a single _anonymous_ profile.\n`{verb: \"log-in-denied\", user: {}}`\n\nNote: You _can_ send your own anonymous ID(s) if you want.\n\n### Learn More:\n\n  - [What Events Should I Track?](doc:what-events-should-i-track)\n  - [Setting the user's `authenticated` state](http://help.thisdata.com/docs/apiv1events#section-user-s-authenticated-status)","excerpt":"","slug":"tracking-failed-log-ins","type":"basic","title":"Tracking Failed Log Ins"}

Tracking Failed Log Ins


When a password is incorrect, but the username or email address is correct, we can track failed login attempts to their account. This is useful for detecting when an attacker is trying to guess someone's password. The `verb` to send is `log-in-denied`. The `user_id` to send depends on your use case. 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. This is true for all event types. If you exclude the user id field, we will treat them as belonging to a single special user, called "Anonymous". Here are some examples, all of which are valid choices. ### You want failed logins to show up alongside any other events for that user In this case, you send the user's ID, and [`authenticated: false`](http://help.thisdata.com/docs/apiv1events#section-user-s-authenticated-status). Failed logins are tied to the user who got their password wrong, or the account an attacker was trying to access. If the username _and_ password were wrong, do not send a user ID. `{verb: "log-in-denied", user: {id: 12345, authenticated: false}}` `{verb: "log-in-denied", user: {id: 67890, authenticated: false}}` ### You want failed logins to be kept anonymous In this case, you should not send the user ID at all. We will automatically group all events without a user ID under a single _anonymous_ profile. `{verb: "log-in-denied", user: {}}` Note: You _can_ send your own anonymous ID(s) if you want. ### Learn More: - [What Events Should I Track?](doc:what-events-should-i-track) - [Setting the user's `authenticated` state](http://help.thisdata.com/docs/apiv1events#section-user-s-authenticated-status)