Cidaas Fraud Detection System

cidaas uses predictive factors and Big Data analytics to verify customers and detect Fraudsters. It provides built-in tools to detect anomalies and stop malicious attempts to access your application.

While user login to the business we need detect that user is real or not, even though the hackers got the user's username and password. if it is fraud entry we need to ask the 2-Factor Authentication.

The cidaas FDS check the following criteria to detect. if the user is a valid user or not:

  • IP_NOT_MATCHING or NETWORK_NOT_MATCHING
  • FINGER_PRINT_NOT_MATCHING
  • REQUESTED_INVALID_ACCEPT_LANGUAGE
  • NEW_DEVICE
  • NEW_LOCATION
  • UN_USUAL_LOGIN_TIME
  • UN_EXPECTED_DISTANCE_TRAVALLED
  • UN_EXPECTED_LOGIN_LOCATION_AND_TIME

1 . IP_NOT_MATCHING or NETWORK_NOT_MATCHING:

Conditions:

The IP range is verified in combination with the distance travelled (so as not to create any inconvenience for the user by checking only the IP as a string). If the distance travelled is more than 3 (threshold) kilometers, 2-Factor Authentication is triggered.

2 . FINGER_PRINT_NOT_MATCHING:

Conditions:

This is straight forward, just a string comparison between saved and the current fingerprint variable is perfomed.

3 . REQUESTED_INVALID_ACCEPT_LANGUAGE:

Conditions:

Must follow this https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Syntax for Accept-Language

Accepte-Language ="Accept-Language" ":"
            1#( language-range [ ";" "q"="value ])
    language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

Ex: en-US,en;q=0.8

The Primary Language of the user’s device is: "en-US"

The user’s device also has : "en" language (other than “en-US”) with the quality of 0.8 (here 1 is max 0 is less)

In this the check it should tell REQUESTED_INVALID_ACCEPT_LANGUAGE if the quality level varies by .5 or if a new language is added/detected.

4 . NEW_DEVICE:
Conditions:

It should split and evaluate the user Agent variable and ignore the version upgrade of the browser. It should not spam the user by performing only string comparison.

5 . NEW_LOCATION:

Conditions:

The lat and lon values of the user can be derived from 2places:

  • If the user has accepted location sharing in the browser, then the lat and lon values are derived

  • If the user has not accepted location sharing, the lat long values are to be derived from the IP address for which we have a “IP to location” service, that should be used.

Note: The distance threshold should also be considered.

6 . UN_USUAL_LOGIN_TIME:

Conditions:

The user’s login time is captured to create a Login time cluster. Whenever the user logs in, if the login time does not fall within the login times as recorded in the cluster, 2-Factor Authentication is triggered.

7. UN_EXPECTED_DISTANCE_TRAVALLED:

Conditions:

Read the NEW_LOCATION spec,

When a change in distance travelled is detected (i.e. a distance change beyond the set threshold distance value is detected with respect to the Location cluster created for the user), 2-Factor Authentication is triggered.

8. UN_EXPECTED_LOGIN_LOCATION_AND_TIME:

Conditions:

The location cluster of the user along with corresponding time information is created to capture the user behavior (For e.g., on weekdays the user logs in to the business portal from his office, and on weekends from his home)

Example: The user's normal login time and location

From Monday to Friday from Bellandur/Wimsheim (Office)

Saturday and Sunday from Mumbai/Stuttgart (Home)

If this pattern changes we should ask for the 2-Factor Authentication.

APP Profile

Whenever the access token is validated, and the target page also passed, the App profile helps to detect if the app is accessing any unusual API.

UN_USUAL_API_ACCESS_REQUEST

The received ClientID and request URL are verified against the Location vs Client ID cluster created for the user.

Cidaas Fraud Detection Flow:

When the user logs in to the business portal, cidaas FDS detects if the user is a valid user based on the above-mentioned criteria. If all the conditions are satisfied, The FDS send MFA status MFA status like Fraud=False the user is considered to be a valid user and is hence granted access to the portal.

If a mismatch is detected in any of the above criteria, cidaas FDS identifies the user as a fraudulent user and sends the status Fraud=TRUE. At the same time, in the background a webhook trigger event happens and correspondingly notifications are sent to the user (Notifications such as “Your Account was just signed in to from a new device. You are getting this email to make sure it was you”). 2-Factor Authentication is triggered to verify the identity of the user trying to access your business portal.



results matching ""

    No results matching ""