WO2022045873A1

WO2022045873A1 - System and method for adaptive authentication

Info

Publication number: WO2022045873A1
Application number: PCT/MY2020/050161
Authority: WO
Inventors: Nor Izyani Daud; Galoh Rashidah Haron; Dahlia DIN; Moesfa Soeheila MOHAMAD
Original assignee: Mimos Bhd
Current assignee: Mimos Bhd
Priority date: 2020-08-28
Filing date: 2020-11-20
Publication date: 2022-03-03
Anticipated expiration: 2023-02-28
Also published as: MY205446A

Abstract

The present invention relates to a system and method for adaptive authentication of a user, wherein the system (10) comprises a user device (11) for inputting one or more login attributes by the user and generates an authentication request using the login attributes. An authentication unit (12) receives the authentication request and authenticates the user by comparing the inputted login attributes with a corresponding login template stored in a storage unit (13). A configuration unit (14) selects one or more data fields for categorizing a device ID included in the authentication request. An anomaly detection unit (15) classifies the device ID as anomalous device ID based on the authentication request and previous authentication requests. A data cleansing unit (16) categorizes the anomalous device ID based on the selected data fields.

Description

SYSTEM AND METHOD FOR ADAPTIVE AUTHENTICATION

FIELD OF THE DISCLOSURE

The present invention relates broadly to the field of user authentication. More particularly, the present invention relates to a system and method for adaptive authentication of a user improved attack detection accuracy.

BACKGROUND

In the digital era, illegal hackers use login attacks quite frequently to seize control of computers to access confidential information and to misuse resources. Various methods have been followed during such login attacks, and one of the main attacking strategy is the brute force attack, wherein a burst of different login passwords generated using an automated software, with the hope of hitting the appropriate password and thus gaining access to the target resource.

One common solution to such login attacks is to completely block any communication with an internet protocol (IP) address if a preset number of login attempts failed continuously. However, there are scenarios where a legitimate user may wrongly enter the login details such as faulty input device, multiple accounts and the like. In such conditions, it is very difficult to identify wrong inputs from a legitimate user and login attacks from illegal hackers.

United States patent no.: US 7,934,254 B2 discloses a system and method for dynamically self-adjusting to changes in network activity using a plurality of alert levels wherein each successively higher alert level triggers a corresponding heightened security response from the networked computer being misused. This system is capable of detecting an intrusion and responding to aggressively filter false-positives while still recording necessary information to identify an attack.

However, there is still a need in the art for a system and method for adaptive authentication of a user, wherein legitimate user is protected from false blocking without compromising security of a resource against brute force attacks. SUMMARY

The present disclosure proposes a system and method for adaptive authentication of a user. The system comprises a user device, an authentication unit, a configuration unit, a storage unit, an anomaly detection unit and a data cleansing unit. The user device inputs one or more login attributes from a user and generates an authentication request using the login attributes, wherein the user is registered for accessing a resource. The authentication unit receives the authentication request and authenticates the user by comparing the inputted login attributes with a corresponding login template stored in a storage unit. The authentication request includes a device identification (ID) of the user device and the login attributes.

The storage unit includes a template module for storing one or more login templates generated during each user registration and a success module for storing the device ID if the user is authenticated to access the resource from the user device. The configuration unit selects one or more data fields for categorizing the device ID. The anomaly detection unit classifies the device ID as an anomalous device ID, if the authentication request fails at the authentication unit, if a number of continuously failed authentication requests preceding the authentication request reaches a predefined threshold and if the device ID is not stored in the success module. If the device ID is already stored in the success module, the anomaly detection unit classifies the user device ID as a legitimate ID and the inputted login attributes as a wrong input.

The data cleansing unit categorizes the anomalous device ID based on the selected data fields.

In one aspect of the present invention configuration unit selects the data field based on previously failed authentication requests and assigns a weightage to each data field, wherein the configuration unit updates the selection of data field and corresponding weightage, when an authentication request fails at the authentication unit.

The data cleansing unit categorizes the anomalous device ID as non-suspicious ID if at least one elected data field is not available in the authentication request. On the other hand, the data cleansing unit categorizes the anomalous device ID as a risky ID if all the selected data fields are available in the authentication request.

Furthermore, the data cleansing unit categorizes a risk level of the risky ID based on a number of data fields failed at the authentication unit, wherein the configuration unit selects one or more additional data fields for updating the selected data fields, if the risky ID is categorized as a medium risk ID. The data cleansing unit stores the risky ID to a list of suspicious IDs, if all data fields failed at the authentication unit. If a subsequent authentication request includes a device ID that is stored in the list of suspicious IDs, the authentication unit blocks a subsequent authentication request.

By this way, a legitimate user is protected from false blocking without compromising security of a resource, wherein a level of security is increased gradually for each failed login attempt until the user is categorized as an illegal hacker and a login attempt is completely blocked only after it is confirmed that the login attempt is from the illegal hacker.

In another aspect of the present invention, the method comprises the steps of: inputting login attributes by a user for generating an authentication request, receiving the authentication request at an authentication unit, comparing the inputted login attributes with a corresponding login template stored in a storage unit for authenticating the user, selecting one or more data fields for categorizing a device identification (ID) of the user device, classifying the device ID as an anomalous device ID based on the authentication request, previous authentication requests and the device ID, and categorizing the anomalous device ID by based on the selected data fields.

Various objects, features, aspects and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

In the figures, similar components and/or features may have the same reference numerals. Further, various components of the same type may be distinguished by following the reference numerals with a second numeral that distinguishes among the similar components. If only the first reference numeral is used in the specification, the description is applicable to any one of the similar components having the same first reference numeral irrespective of the second reference numeral.

FIGURE 1 shows a block diagram of the system for adaptive authentication, in accordance with an exemplary embodiment of the present invention.

FIGURE 2 shows a flow diagram of the method for adaptive authentication, in accordance with an exemplary embodiment of the present invention.

FIGURE 3A shows a part of a flowchart of the method for adaptive authentication, in accordance with an exemplary embodiment of the present invention.

FIGURE 3B shows the remaining part of the flowchart of FIGURE 3A.

DETAILED DESCRIPTION

In accordance with the present disclosure, there is provided a system and method for adaptive authentication, which will now be described with reference to the embodiments shown in the accompanying drawings. The embodiments do not limit the scope and ambit of the disclosure. The description relates purely to the embodiments and suggested applications thereof.

The embodiments herein and the various features and advantageous details thereof are explained with reference to the non-limiting embodiment in the following description. Descriptions of well-known components and processes are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiment herein. Accordingly, the description should not be construed as limiting the scope of the embodiment herein.

The description hereinafter, of the specific embodiment will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify or adapt or perform both for various applications such specific embodiment without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation.

Various terms as used herein are defined below. To the extent a term used in a claim is not defined below, it should be understood with the broadest definition given by persons in the pertinent art to that term as reflected in publications (e.g. dictionaries, article or published patent applications) and issued patents at the time of filing.

Definitions:

False blocking - A situation under which an authentication system wrongly identifies mismatching credentials from a legitimate user as a brute force attack from an illegal hacker and completely blocks any communication from the user.

Login attributes - Any type of inputs by a user for demonstrating authenticity of the user to access a resource. Such inputs may include but not limited to inputs made through a keyboard, biometric device, imaging device, microphone, mouse, tactile device and the like.

Data field - Any field of information involved in the process of inputting the login attributes. Such field may include but not limited to login time, authentication method, software application, language, type of input and the like.

Resource - Any information, object or space which is considered highly valuable to a user. It may include but not limited to a software file, folder, drive, server, physical document, safety locker, cash box, room, floor, building and the like. In accordance with an exemplary embodiment of the present invention, an authentication level is gradually increased for each failed login attempt, wherein the number of data fields considered for authenticating a user is gradually increased for each failed authentication request received from the user until the user is classified as a high risk user i.e. illegal hacker. Once the user is classified as an illegal hacker, any communication from the IP address of the illegal hacker is blocked. By this way, a legitimate user is protected from false blocking without compromising security of a resource.

FIGURE 1 shows a block representation of the system (10) for adaptive authentication, in accordance with an exemplary embodiment of the present invention. The system (10) comprises a user device (11 ), an authentication unit (12), a storage unit (13), a configuration unit (14), an anomaly detection unit (15) and a data cleansing unit (16). The user device (11 ) is for inputting one or more login attributes by a user and generates an authentication request using the login attributes. In a preferred embodiment, the user device (11 ) may include but limited to a mobile phone, desktop computer, laptop computer, tablet computer, personal digital assistant, point-of-sale (POS) terminal, automated teller machine (ATM), digital kiosk, home automation devices, burglar alarm devices, vehicle instrument cluster, safety locker, security gate and the like.

Apart from the inputted login attributes, the authentication request also includes a device identification (ID) of the user device. Such device ID includes but not limited to Internet Protocol (IP) address, media access control (MAC) address, International Mobile Equipment Identity (IMEI) number or any other unique ID related to the user device (11 ) used for identifying the user device (11 ).

The authentication unit (12) receives the authentication request and authenticates the user by comparing the inputted login attributes with a corresponding login template stored in the storage unit (13). Similar to any conventional authentication systems, the present invention follows a traditional user registration process, wherein the user selects and/or inputs the login attributes e.g. username, password, biometrics, pattern, image(s), identification number, pin number, secret question and answer, etc. Based on the login attributes, the authentication unit (12) generates a login template corresponding to the user and stores the login template in the storage unit (13).

During authentication, the authentication unit (12) extracts the inputted login attributes from the received authentication request, receives the corresponding login template from the storage unit (13) and then compares the extracted login attributes with the login template. If the extracted login attributes match with the login template, the authentication request is a successful authentication request and the user is authenticated to access a resource (not shown). If there is a mismatch, the authentication request is a failed authentication request and the user is notified of the failure and prompted to input the login attributes once again. Further, the authentication unit (12) transfers the login attributes and data fields of the login attributes extracted from the authentication request to a failure module (not shown) in the storage unit (13). The data fields may include but not limited to time of generating the authentication request, mode of inputting the login attributes, name of the browser used for login, location of the user device and the like.

The storage unit (13) includes a template module (not shown) to store the login templates and a success module (not shown) to store the device ID included in the successful authentication request. Additionally, the storage unit (13) includes the failure module to store login attributes and device ID included in each failed authentication request.

The configuration unit (14) selects one or more data fields from the failure module for categorizing a device ID included in the authentication request. The configuration unit (14) selects the data fields based on the login attributes stored in the failure module of the storage unit (13). During the selection process, the configuration unit (14) prepares a class table by generating two or more classes depending on the number of failed authentication requests and lists out all data fields related to the inputted login attributes, the login attributes and corresponding priority value. In a preferred embodiment, the priority value is determined based on user preferences obtained from past authentication requests or from manual input by the user during user registration. For example, when a user uses a virtual keyboard to input password more frequently as compared to inputting a biometric feature, the configuration unit (14) assigns higher priority value to virtual keyboard and a lower priority value to biometric device under the data field “input method”. A sample set of class table is given below.

Table 1. Sample class table

It is to be understood that the above table is mere for understanding purpose and the actual priority table may vary.

Further, from the class table, the configuration unit (14) generates a priority table by performing a heuristic data analysis of the priority value in the class table. Alternatively, the priority table may also be generated based on an average of the priority value of each login attribute under each data field under each class, wherein the login attribute with highest priority value is selected. A priority table corresponding to the sample class table in Table 1 is show in below table.

Table 2. Sample priority table

It can be seen from the above sample priority table that the data fields including authentication method (password), authentication time (1 :00 PM - 2:00 PM) and web browser (Chrome / Firefox) have the highest priority values, and therefore can be selected for categorizing the device ID.

An anomaly detection unit (15) classifies the device ID as anomalous device ID based on the authentication request and previous authentication requests. Preferably, the anomaly detection unit (15) checks if the authentication request has failed at the authentication unit (12). If yes, the anomaly detection unit (15) checks if a number of continuously failed authentication requests preceding the current authentication request from the same device ID reaches a threshold. If yes, the anomaly detection unit (15) further checks if the device ID is already stored in the success module of the storage unit (13). If no, the anomaly detection unit (15) detects an anomaly and classifies the device ID as an anomalous device ID. If the authentication request is successful at the authentication unit (12), or if the number of continuously failed authentication request preceding the current authentication request is less than a threshold, or if the device ID is already stored in the success module, then the anomaly detection unit (15) classifies the device ID as a genuine device ID and resets the authentication process to prompt the user to input the login attributes once again.

If the device ID is classified as an anomalous device ID, the data cleansing unit (16) categorizes the anomalous device ID based on the selected data fields. In particular, the data cleansing unit (16) checks if all the selected data fields are available in the authentication request.

Risky ID

Suppose, the configuration unit (14) selected the authentication method (password), authentication time (1 :00 PM - 2:00 PM) and web browser (Chrome / Firefox) for categorizing the device ID, and the data fields included in the authentication request received from the anomalous device ID are authentication method, authentication time and web browser, a perfect match is detected at the data cleansing unit (16) and it classifies the anomalous device ID as a risky ID.

Once the anomalous device ID is categorized as a risky ID, the data cleansing unit (16) proceeds to determine a risk level of the risky ID, by checking a number of data fields failed at the authentication device (12). If all the data fields failed at the authentication device (12), the data cleansing unit (16) determines the risk level as very high. For example, if the configuration unit (14) selects password entry as the authentication method, time between 1 :00 PM - 2:00 PM as authentication time and Chrome or Firefox as web browser for categorizing the device ID, and if the authentication unit (12) determines that the data fields included in the authentication requests are biometrics as the authentication method, 3:43 PM as authentication time and Edge as web browser Edge, all the login attributes fail, and thus the data cleansing unit (16) determines the risk level of the risky ID as high. Further, the data cleansing unit (16) proceeds to store the risky ID to a list of suspicious IDs which are blocked from accessing the resource. In other words, if an authentication request received at the authentication unit (12) includes one of the suspicious IDs as the device ID, the authentication unit (12) discards the authentication request.

If the authentication unit (12) determines that all the data fields are successful, then the data cleansing unit (16) determines the risk level of the risky ID as low and proceeds to restart the authentication process. On the other hand, if the authentication unit (12) determines that a number of data fields failed is within a predetermined range, then the data cleansing unit (16) determines the risk level of the risky ID as medium and proceeds to restart the authentication process. Before the data cleansing unit (16) proceeds to restart the authentication process, the configuring unit (12) updates the selected data fields and corresponding weightage.

In a preferred embodiment, the configuring unit (12) selects one or more additional data fields to update the selected data fields for categorizing the device ID. Alternatively, the configuring unit (12) may also replace and/or remove one or more data fields to update the selected data fields for categorizing the device ID.

On the other hand, if one or more data fields in the authentication request do not match with the selected data fields, then the data cleansing unit (16) detects a mismatch and classifies the anomalous device ID as a non-suspicious ID. For example, if the data fields included in the authentication request are authentication method, input device and web browser and if the configuration unit (12) selected authentication method, authentication time and web browser, then the data cleansing unit (16) detects that the authentication time is not available in the authentication request and thus classifies the anomalous device ID as a non- suspicious ID. Further, the data cleansing unit (16) resets the authentication process to repeat the entire process.

By this way, a legitimate user is protected from false blocking without compromising security of the resource, wherein a level of security is increased gradually for each failed login attempt until the user is categorized as an illegal hacker and a login attempt is completely blocked only after it is confirmed that the login attempt is from the illegal hacker.

FIGURE 2 shows a flow diagram of a method for adaptive authentication (20) in accordance with an exemplary embodiment of the present invention. The method (20) comprises the steps of inputting, at a user device, one or more login attributes by a user for generating an authentication request (21 ), receiving the authentication request at an authentication unit (22), comparing the inputted login attributes with a corresponding login template stored in a storage unit for authenticating the user (23), selecting one or more data fields for categorizing a device ID (24) of the user device, classifying the device ID (25) and if the device ID is classified as an anomalous device ID, categorizing the device ID based on the selected data fields (26). If the device ID is not classified as anomalous device ID, then the authentication process is reset.

In a preferred embodiment, the authentication request includes the device ID of the user device and the inputted login attributes. After receiving the authentication request at the authentication device, the user device ID, inputted login attributes and data fields of the inputted login attributes are extracted and the login attributes are compared with the login template. If a match occurs, the user is authenticated to access a resource. Otherwise, the authentication request is classified as a failed authentication request, and preceding authentication requests including same device ID as the failed authentication request are checked if a number of failed authentication requests preceding the current authentication request reaches a threshold. If yes, then the device ID is compared with a list of suspicious IDs. If it matches with one of the suspicious IDs, then the device ID is classified as an anomalous device ID.

On the other hand, if the number of failed authentication requests preceding the current authentication request is below the threshold, then the device ID is classified as genuine and the authentication process is restarted. Otherwise, the device ID is compared with the suspicious IDs. If it does not match with any of the suspicious IDs, then the device ID is classified as genuine and the authentication process is restarted. The storage unit includes a template module for storing the login templates generated during each user registration and a success module for storing device IDs if the corresponding user accessed the resource from the user device at least one in the past. For example, after registration of a user, if the user successfully logged in using a device ID, the device ID is stored in the success module. Any subsequent authentication request carrying one of the stored device IDs is not considered as suspicious login attempt irrespective of the number of continuously failed authentication requests carrying the device ID.

The data fields are selected based on previously failed authentication requests and a weightage is assigned to each data field, wherein when an authentication request fails at the authentication unit, the selected data fields and corresponding weightage are updated. In a preferred embodiment, the selected data fields are updated by selecting one or more additional data fields and assigning a weightage to each additional data fields. Alternatively, updating may also include replacing and/or removing on or more data fields.

The anomalous device ID is categorized as a risky ID if all the selected data fields are available in the authentication request. Otherwise, the anomalous device ID is categorized as non-suspicious and the authentication process is restarted. If the anomalous device ID is categorized as a risky ID, a risk level of the risky ID is determined based on a number of data fields failed at the authentication unit. If all the data fields fail at the authentication unit, the risk level is determined as high. If all the data fields are successful at the authentication unit, then the risk level is determined as low and the authentication process is restarted. If a number of data fields failed at the authentication unit is within a predefined range, then the risk level is determined as medium.

If the risk level is determined as high, then the risky ID is added to the suspicious ID list and any subsequent authentication request including the suspicious ID is discarded. If the risk level is determined as medium, the selected data field is updated by selecting one or more additional data fields and then the authentication process is restarted. If the risk level is determined as low, then the authentication process is restarted. By this way, a legitimate user is protected from false blocking without compromising security of the resource, wherein a level of security is increased gradually for each failed login attempt until the user is categorized as an illegal hacker and a login attempt is completely blocked only after it is confirmed that the login attempt is from the illegal hacker.

The complete functionality of the present invention will now be explained based on the flowchart shown in FIGURES 3A and 3B. For example, before initiating the authentication process, alphanumeric password “57MY00master43”, authentication time “2:00PM - 4:00PM” and web browser “Chrome” are selected as data fields for classifying a device ID based on previously failed authentication requests. When an authentication request fails, a number of login attempts is compared against a preset threshold which is 5 in this example.

If the number of continuous failed login attempts is less than 5, the authentication process is reset and the user is notified to input the credentials. This process is continued until the authentication request succeeds or the number of login attempts reaches 5. If the authentication request succeeds, the access to the resource is granted. If the authentication request continuously failed for the fifth time, then the device ID included in the authentication request is compared with device IDs stored in the success module. If the device ID matches with any of the stored device IDs in the success module, then the authentication process is reset and the user is notified to re-enter the login credentials.

Anomalous device ID

If the device ID does not match with any of the stored device IDs in the success module, then the device ID is classified as an anomalous device ID and the selected data fields are compared with the data fields included in the authentication request to categorize the anomalous device ID as a risky ID or non- suspicious ID.

Non-suspicious device ID

Suppose the authentication request includes the authentication attributes: 57MY00mister43” (authentication method), mobile phone (input device) and “Firefox” (browser used for login), a mismatch occurs as the selected data field “authentication time” is not available in the authentication request. As a result of this mismatch, the anomalous device ID is categorized as a non-suspicious device ID and the authentication process is reset. Further, the user is notified to re-enter the log in credentials.

Risky ID

Suppose the authentication request includes the data fields: alphanumeric password, time of input and browser used for login, a perfect match occurs as all the selected data fields (authentication method, authentication time and web browser) are available in the authentication request, and so the device ID is categorized as risky ID. Further, the data fields that failed while processing the authentication request are counted and a risk level of the risky ID is determined based on the count.

Scenario 1 : Low risk

The count is compared against a threshold range, and if the count is less than the threshold range, then the risk level is determined as low risk. Suppose the threshold range is set as 1 - 2 and all the selected data fields (authentication method, authentication time and web browser) are available in the authentication request. If all the data fields are successful, then the risk level is determined as low level.

For example, if alphanumeric password, “2:00PM - 4:00PM” (authentication time) and “Chrome” (web browser) are selected as data fields, and if the authentication request includes an alphanumeric password as authentication method, 2:11 PM as authentication time and Chrome as input web browser, then all data fields are successful. Upon determining the risk level as low, the entire authentication process is repeated.

Scenario 2: Medium risk

Suppose the threshold range is set as 1 - 2 and all the selected data fields (authentication method, authentication time and web browser) are available in the authentication request. If one or two the authentication attributes fail, then the risk level is determined as medium level. For example, if alphanumeric password, “2:00PM - 4:00PM” (authentication time) and “Chrome” (web browser) are selected as data fields, and if the authentication request includes an alphanumeric password as authentication method, 1 :01 PM as authentication time and Firefox as input web browser, then two data fields fail even though the selected data fields are available in the authentication request.

Upon determining the risk level as medium level, the list of selected data fields is updated and the authentication process is repeated. Updating the list includes adding, replacing and/or removing one or more selected data fields. The updated list is used for the subsequent authentication process.

Scenario 3: High risk

Suppose the threshold range is set as 1 - 2 and all the selected data fields (authentication method, authentication time and web browser) are available in the authentication request. If more than two authentication attributes fail, then the risk level is determined as high level. For example, if alphanumeric password, “2:00PM - 4:00PM” (authentication time) and “Chrome” (web browser) are selected as data fields, and if the authentication request includes a biometric feature as authentication method, 4:01 PM as authentication time and Edge as input web browser, then all authentication attributes fail even though the selected data fields are available in the authentication request. In this scenario, the risk level is determined as high level.

Upon determining the risk level as high level, a list of suspicious IDs is updated with the device ID included in the current authentication request and the authentication process is ended. Further, any subsequent authentication request including any of the suspicious IDs in the updated list is discarded without processing.

Even though the above embodiment is described using web platform based authentication, it is to be understood that the present invention may also be used for authentication in other platforms such as door access, airport immigration/emigration check counters and the like.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" may be intended to include the plural forms as well, unless the context clearly indicates otherwise.

The terms "comprises," "comprising," “including,” and “having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof.

The use of the expression “at least” or “at least one” suggests the use of one or more elements, as the use may be in one of the embodiments to achieve one or more of the desired objects or results.

While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

Claims

CLAIMS:

1 . A system (10) for adaptive authentication of a user, comprising: i. at least one user device (11 ) for inputting one or more login attributes by said user and generating at least one authentication request using said login attributes, wherein said user is registered for accessing at least one resource; ii. at least one authentication unit (12) for receiving said authentication request and authenticating said user by comparing said inputted login attributes with a corresponding login template stored in at least one storage unit (13), wherein said authentication request includes a device identification, ID, of said user device (11 ), and said login attributes; iii. said storage unit (13) including at least one template module for storing one or more login templates generated during each user registration, at least one success module for storing said device ID if said user is authenticated to access said resource from said user device (11 ), and a failure module for storing login attributes extracted from previously failed authentication requests; iv. at least one configuration unit (14) for selecting one or more data fields of login attributes from the failure module for categorizing said device ID; v. at least one anomaly detection unit (15) for classifying said device ID, wherein said device ID is classified as an anomalous device ID, if a. said authentication request fails at said authentication unit (12); b. a number of continuously failed authentication requests preceding said authentication request reaches a predefined threshold; and c. said device ID is not stored in said success module; and vi. at least one data cleansing unit (16) for categorizing said anomalous device ID based on said selected data fields, characterized in that

- said configuration unit (14) selects said data fields based on at least one previously failed authentication request and assigns a weightage to each selected data field; and - said data cleansing unit (16) categorizes said anomalous device ID by comparing said data fields of said login attributes included in said authentication request with said selected data fields, wherein said configuration unit (14) updates said selection of data field and corresponding weightage, when an authentication request fails at said authentication unit (12).

2. The system (10) of claim 1 , wherein said data cleansing unit (16) categorizes said anomalous device ID as non-suspicious ID if at least one of said selected data fields is not available in said authentication request.

3. The system (10) of claim 1 , wherein said data cleansing unit (16) categorizes said anomalous device ID as a risky ID if all said selected data fields are available in said authentication request.

4. The system (10) of claim 3, wherein said data cleansing unit (16) categorizes a risk level of said risky ID based on a number of data fields failed at said authentication unit (12).

5. The system (10) of claim 4, wherein said configuration unit (14) selects at least one additional data field for categorizing said device ID during a subsequent authentication process, if said data cleansing unit (16) categorizes said risky ID as a medium risk ID.

6. The system (10) of claim 4, wherein said data cleansing unit (16) stores said risky ID to a list of suspicious IDs, if all data fields failed at said authentication unit (12).

7. The system (10) of claim 6, wherein said authentication unit (12) blocks a subsequent authentication request if a device ID included in said subsequent authentication request is stored in said list of suspicious IDs.

8. A method (20) for adaptive authentication of a user, comprising the steps of: i. inputting, at at least one user device, one or more login attributes by said user for generating at least one authentication request (21 ), wherein said user is registered for accessing at least one resource; ii. receiving said authentication request at at least one authentication unit

(22), wherein said authentication request includes a device identification, ID, of said user device and said login attributes; iii. comparing said inputted login attributes with a corresponding login template stored in at least one storage unit for authenticating said user

(23), wherein said storage unit includes at least one template module for storing one or more login templates generated during each user registration and at least one success module for storing said device ID if said user is authenticated to access said resource from said user device (11 ); iv. selecting at least one of data fields from at least one failure module of said storage unit for categorizing said device ID (24), wherein said failure module stores login attributes extracted from previously failed authentication requests; v. classifying said device ID (25), wherein said device is classified as an anomalous device ID if: a. said authentication request fails at said authentication unit; b. a number of continuously failed authentication requests preceding said authentication request reaches a predefined threshold; and c. said device ID is not stored in said success module; and vi. if said device ID is classified as said anomalous device ID, categorizing said anomalous device ID based on said selected data fields (26), characterized in that, said step of selecting said data field includes:

- selecting said data field based on previously failed authentication request; and

- assigning a weightage to each data field; and said step of categorizing said anomalous device ID includes comparing said data fields of said login attributes included in said authentication request with said selected data fields, wherein when an authentication request fails at said authentication unit, said selection of data field and corresponding weightage are updated. The method (20) of claim 8, wherein said step of categorizing said anomalous device ID includes categorizing said anomalous device ID as non-suspicious ID if at least one selected data field is not available in said authentication request.

10. The method (20) of claim 8, wherein said step of categorizing said anomalous device ID includes categorizing said anomalous device ID as a risky ID if all selected data fields are available in said authentication request.

11. The method (20) of claim 10, wherein said step of categorizing said anomalous device ID includes categorizing a risk level of said risky ID based on a number of data fields failed at said authentication unit.

12. The method (20) of claim 11 , wherein said selection of data fields is updated by selecting at least one additional data field, if said risky ID is categorized as a medium risk ID.

13. The method (20) of claim 11 , further comprising the step of storing said risky ID to a list of suspicious IDs, if all said data fields included in said authentication request failed at said authentication unit. 14. The method (20) of claim 13, further comprising the step of blocking a subsequent authentication request at said authentication unit if a device ID included in said subsequent authentication request is stored in said list of suspicious IDs.