Patent ID: 12218943

DETAILED DESCRIPTION

The present disclosure relates to systems, methods, and apparatuses for enhanced login and account/identity validation. In example embodiments, a principal control point serves as an automated central orchestration engine (“central orchestrator”) of pre-authentication protections to consolidate and respond to different pre-authentication risk evaluations. A login and authorization system may employ several strategies for protecting against fraudulent or unauthorized access to user accounts, but each strategy may have different strengths and weaknesses, and no one strategy is typically able to achieve 100 percent accuracy. For example, a system may utilize multiple automated decision engines, each applying a unique set of criteria in evaluating security risks. Because different criteria may be better suited to detecting fraudulent activity in different situations (e.g., for particular types of attacks), some illegitimate activity may be missed by one automated decision engine but caught by another automated decision engine. The central orchestrator takes into account risk evaluations from two or more different automated decision engines to make a more informed decision regarding whether, for example, a login attempt is legitimate. The central orchestrator is thus able to leverage the risk evaluations of multiple strategies to enhance accuracy, reducing false positives and false negatives in account validation.

Referring toFIG.1, a block diagram of a computing system100is shown according to one or more example embodiments. As described herein, the computing system100enables enhanced login and account validation. The computing system100includes a plurality of computing devices102,104able to access a central system106via a network110. The central system106provides a networked access portal to allow users to log into and access accounts. The computing device102may be, for example, a mobile computing device (such as a smartphone, tablet, laptop, etc.), and computing device104may be, for example, a personal computing device (such as a desktop computer or workstation). The components of the computing system100are communicably and operatively coupled to each other over the network110. The network110may be any type of type of network. For example, the network110may include a wireless network interface (e.g., 802.11X, ZigBee, Bluetooth, Internet, etc.), a wired network interface (e.g., Ethernet, USB, Thunderbolt, etc.), or any combination thereof. The network110is structured to permit the exchange of data, values, instructions, messages, and the like between computing devices102,104and the central system106.

Each mobile computing device102includes a processor112, a memory114, and a network interface116. The processor112may be implemented as a general-purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a group of processing components, or other suitable electronic processing components structured to control the operation of the mobile computing device102. The memory114(e.g., RAM, ROM, NVRAM, Flash Memory, hard disk storage, etc.) may store data and/or computer code for facilitating at least some of the various processes described herein. In this regard, the memory114may store programming logic that, when executed by the processor112, controls the operation of the mobile computing device102. The network interface116may be structured to allow the mobile computing device102to communicate data to and from other devices (such as central system106) either directly or via the network110. The mobile computing device102includes a native application118(such as an application provided or authorized by the institution implementing central system106) to allow users to communicate with central system106during a user account login sequence.

Still referring toFIG.1, each personal computing device104includes a processor120, a memory122, and a network interface124. The processor120may be implemented as a general-purpose processor, an ASIC, one or more FPGAs, a DSP, a group of processing components, or other suitable electronic processing components structured to control the operation of the personal computing device104. The memory122(e.g., RAM, ROM, NVRAM, Flash Memory, hard disk storage, etc.) may store data and/or computer code for facilitating at least some of the various processes described herein. In this regard, the memory122may store programming logic that, when executed by the processor120, controls the operation of the personal computing device104. The network interface124is structured to allow the personal computing device104to communicate data to and from other devices (such as central system106) either directly or via the network110. The personal computing device104includes a browser126(such as Google Chrome, Microsoft Edge, Internet Explorer, etc.) to allow users to communicate with central system106during a user account login sequence.

The central system106includes a processor128, memory130, and a network interface132. The processor128may be implemented as a general-purpose processor, an ASIC, one or more FPGAs, a DSP, a group of processing components, or other suitable electronic processing components structured to control the operation of the central system106. The memory130(e.g., RAM, ROM, NVRAM, Flash Memory, hard disk storage, etc.) may store data and/or computer code for facilitating at least some of the various processes described herein. In this regard, the memory130may store programming logic that, when executed by the processor128, controls the operation of the central system106. The network interface132is structured to allow the central system106to communicate data to and from other devices (e.g., mobile device102, personal computing device104, etc.) either directly or via the network110. The computing system100may be arranged such that the central system106operates as a server, and computing devices102,104operate as clients.

The central system may include a security and login client134which, as further discussed below, may provide fraud prevention measures and security protections (such as a digital perimeter, pre-authentication security measures, identify verification protocols, etc.). In some arrangements, a central system106includes an account database134for storing information on users and user accounts (such as bank accounts) to be accessed via computing devices102,104. In certain versions, some or all of the account information may be stored on separate local or remote computing devices that are accessible to, or via, the central system106. For example, if the central system106is administered by (or on behalf of) a financial institution, the accounts database136may include customer account information. As another example, if the central system106is administered by (or on behalf of) a government entity (e.g., a department of motor vehicles, a state department, a tax department, etc.), the accounts database136may include information on government-issued documents (e.g., driver's licenses, passports, tax form filings, permits, etc.).

It is noted that the central system106may be employed to provide users with convenient access to sensitive or otherwise private information. Because of the nature of the information, such systems can be attractive targets for fraudulent activity, and security measures are normally employed to help prevent unauthorized account access. One the one hand, if security measures are not adequately stringent, user information may be at risk of being breached. On the other hand, if security measures are too stringent (or otherwise not adequately discerning), legitimate users may be denied access to their accounts, defeating the purpose of a computing system arranged to allow for convenient remote account access. A set of security measures may be adapted, for example, to assessing the risk that a login attempt was instigated by a bot, and if the risk is too high, denying access to the suspected bot. False positives—that is, determining that an attempt is illegitimate (e.g., a bot) when it is legitimate (e.g., a human user)—are undesirable because a user is (at the very least) inconvenienced if denied access to his or her account. False negatives—that is, determining that an attempt is legitimate (e.g., a human user) when it is illegitimate (e.g., a bot)—are also undesirable because sensitive data may fall into the wrong hands. Because of the number of users that may seek to access their accounts through such a portal on a daily basis, even a small fraction of one percent improvement (i.e., even a seemingly miniscule reduction in false positives and false negatives) can impact many thousands of users (and their families) each day, and each failed legitimate access attempt and successful illegitimate access attempt can be very costly to users monetarily and in terms of time and energy.

Referring toFIG.2, a flow diagram of an example method200for enhanced login and authentication for access to user accounts is described according to various embodiments. The method200may be performed by a central system106. Generally, at202, the central system106provides an access portal through which users are able to request access to user accounts. At204, the central system106may accept login credentials (such as a username and password) as part of the process of verifying a login attempt. A login request may include the credentials and, optionally, additional data (which may be collected by central system106) related to the login attempt, such as the hardware and software environment of the device (e.g., mobile and personal computing devices102,104) as well as network-related information, such as the device's Internet Protocol (IP) address. The login request may also include data related to the behavior of the user and the user's device (and deviations from normal behavior), which may suggest or indicate that a login attempt is illegitimate. Example types of behavior that may be considered may include time taken during the login process (e.g., time taken to enter in credentials or responses to such queries as challenge questions), deviations in applications or computing devices used to login, time of day, number of incorrect responses entered, etc.

In addition to an enterprise perimeter (such as institution-wide firewalls), at206, the central system106may apply a digital perimeter to evaluate the legitimacy of a login attempt, followed by a pre-authentication protocol at208. As will be further discussed below, the digital perimeter and/or other security strategies employed as part of pre-authentication protocols may be considered decision engines that evaluate the legitimacy of login attempts. If pre-authentication is successfully passed, at210, the login process may proceed with user authorization and validation. If the login attempt is successful, at212a user may be provided access to an account.

Referring to the example data flowchart300inFIG.3, in one or more embodiments, an application305(such as a native application running on, e.g., mobile computing device102) or browser310(running on, e.g., either mobile computing device102or personal computing device104) may provide data (such as login credentials and responses to initial challenge questions) to first decision engine315and second decision engine320. First and second decision engines315,320, which may evaluate risks using the data in a login request, may be part of the digital perimeter and/or part of pre-authentication, as further discussed below. The first and second decision engines315,320may apply different rules and policies to the login request in generating risk assessments, which may be shared with each other and/or with a central orchestrator325, which is adapted to applying its own ruleset (examples of which are further discussed below) to determine whether a login attempt should be blocked, allowed, or challenged. If a login attempt passes protection measures, the central orchestrator325may allow the login request to proceed (to be promoted) to an authorization platform330that is adapted to validating a user's identify.

Alternatively, as further discussed below, the central orchestrator325may determine that a query (e.g., a challenge question) should be returned to the user (which may be a human user or a software bot impersonating a user) via native application305or browser310. The query may be specific, such as a challenge question related to the user's identity, preferences, history, etc.) or the query may be generic (i.e., not specific to the user), such as a question accompanying an image, requiring the user to identify or otherwise answer a question describing or otherwise related to the image. Such challenge questions are generally easier for a human, and especially for a human account owner or authorized user of an account, and are intended to help verify that a login attempt is legitimate. In certain configurations, responses to challenge questions may be provided to first and second decision engines315,320for evaluation. Alternatively or additionally, response questions may be routed directly back to the challenge platform335in certain configurations. If a user “passes” the challenge question (i.e., provides an acceptable response), the login attempt may proceed to the authorization platform330for validation. If the login attempt is validated by authorization platform330, account information stored in account database340may be exchanged with the user, allowing users to access account information and to update information in the account database340.

Referring to the example embodiments represented inFIG.4, in system400, native application402or Internet browser403may be used to initiate a login request that is first received by the digital perimeter404, followed by a pre-authentication protocol406, and subsequently an authentication protocol408(which are conceptually demarcated by lines410and412inFIG.4). In the digital perimeter404(which may be a digital appliance that provides an additional layer of security beyond, e.g., an enterprise firewall), a first decision engine414may apply a first ruleset416(with various rules and security policies) to a login request. If the login request is received via Internet browser403, the ruleset may additionally or alternatively apply certain browser-specific policies to the login request. The first decision engine, based on application of the first ruleset416to the login request (which may include user credentials and data related to the login attempt, as discussed above), may block418the login attempt if security protocols are not satisfied. If a login attempt is blocked, a standardized message may be returned to the native application402or Internet browser403, to limit awareness of an attacker as to why the login request was denied (so as to reduce the likelihood the attacker may learn about what went wrong and retry login attempts with modified behavior intended to increase the odds of successful login). An example message is “we do not recognize your username and/or password. Please try again or visit the help page.”

If security protocols of the digital perimeter404are satisfied, the login attempt may be allowed to proceed to a login application420, which spans pre-authentication406and authentication408. As part of pre-authentication406, a second decision engine422and a third decision engine424may be employed to further evaluate the login attempt (such as the risk that the login attempt was initiated by a bot). The second and third decision engines422,424apply second and third rulesets, respectively (not shown inFIG.4). The first, second, and third decision engines414,422,424may output first, second, and third determinations426,428,430, respectively (based on application of rulesets to available login data). It is noted that the decision engines414,422,424can be internal products, or they can be tools/strategies/products/services provided by outside vendors.

The first, second, and third determinations426,428,430may be fed to a central orchestrator450, which may apply its own ruleset (further discussed below) to reach a “principal” determination regarding the login request. In certain embodiments, the principal determination may be to allow (pass/promote)452, block (fail)454, or challenge456a login request. A login request that is “allowed” may pass to authentication408, which may include a process of verifying user identity460(such as validating a user's password), and if verified, the system may authorize access or otherwise allow the login process to continue462. If a challenge456is to be issued, the system may provide a challenge question458to the user via native application402or Internet browser403. The challenge question458may be, for example, a CAPTCHA challenge or any other inquiry requiring a response before login may proceed. The response (not shown) to challenge question458may, in various configurations, be provided to first, second, and/or third decision engines414,422,424for evaluation. It is noted that multiple challenge questions458can be issued, and the challenge question458need not be the first challenge presented to the user or the only one issued by the central orchestrator450. For example, one of the decision engines (such as the first decision engine414in digital perimeter404) may be allowed to issue a challenge question when login is first requested, and the first determination426may be based in part on the response (or lack thereof) to that challenge question. The central orchestrator450(and/or one or more other decision engines) may subsequently require follow-up challenge questions to authorize the login request.

It is also noted that the rulesets, such as the second and third rulesets, may be different from each other. Advantageously, having different rulesets allows the system to evaluate security risks using different criteria (by, for example, giving greater weight to certain characteristics and or indicators of legitimacy, or less weight to other characteristics or indicators). Certain criteria/rulesets may be better suited to detecting certain fraudulent activity than other criteria/rulesets, as each set of criteria/ruleset may have its strengths and its weaknesses. As different criteria may yield different error rates, taking multiple, different risk evaluations into account can reduce overall error rates (i.e., enhance accuracy by decreasing false positives and/or false negatives). In various configurations, one, a subset, or all of the decision engines make determinations independently (i.e., without input from another decision engine). In other configurations, one or more decision engines make determinations based at least in part on input (such as a determination) from one or more other decision engines. It is noted that in certain configurations, the rulesets may be the same, but the data fed to the decision engines may differ, allowing for potentially different (diversified) results that are consolidated by the central orchestrator450in reaching the principal result.

Two or all three of the determinations426,428,430may be fed to the central orchestrator450. The first determination426of the first decision engine414, in a non-block mode, may determine that a login request should be allowed to “pass” but is deemed “suspect” or “high-risk.” That is, a login request may be not so risky that it should outright be blocked, but it may have certain characteristics that in certain situations are consistent with illegitimate login attempts or that otherwise make it somewhat less likely to be legitimate. The second decision engine422may issue a second determination428that indicates the login request is deemed to pass or fail security protocols. Similarly, the third decision engine424may issue a third determination430that indicates the login request is deemed to pass, fail, or warrant one or more challenge questions (which may be the first challenge question(s) issued to the user, or may be subsequent, follow-up challenge question(s)). The third determination430(as with the other determinations426,428) may also include various advisories regarding risky characteristics or behaviors, and/or may also include other data, such as device identification codes. As further discussed below, the central orchestrator450receives two or more of the determinations426,428,430and applies its rulesets to make a more informed determination.

Although not explicitly shown inFIG.4, it is noted that in addition to being provided to the central orchestrator450, the second determination428may also, in certain configurations, be provided to third decision engine424, which may apply the third ruleset to the login request and/or to the second determination428. Similarly, the first determination426may be provided to the second decision engine422and/or the second decision engine424in various implementations. It is also noted that different combinations of decision engines may be applied depending on the source or nature of the login request. For example, a login request received via native application402may have first and third decision engines416,424or second and third decision engines416,422applied thereto, while a login request received via Internet browser403may have first and second decision engines416,422or first and third decision engines414,424applied thereto.

Additionally, although three decision engines are shown, with one engine being associated with the digital perimeter404and two others being associated with pre-authentication406, any number (of two or more) decision engines in any combination or arrangement may be utilized. For example, more than one decision engine may be incorporated in the digital perimeter404, one or three or more decision engines in pre-authentication406. Further, not all decision engines in a system need to provide a result to central orchestrator450in all situations. For example, one or more of the decision engines may be skipped if the determinations of multiple other decision engines are positive, negative, or requiring a subsequent challenge.

It is noted that the activities of the system may be logged by the system, or sent to outside vendors to help the vendors to improve their product. For example, the first decision engine414may log its activities in internal logs470. The third decision engine424may similarly log its activities in logs472, which may be an external server of a vendor that provided the third decision engine424. The central orchestrator450may record its activities in logs474, and activities surrounding authorization of access and login may be recorded in logs476. In different configurations, the logs470,472,474,476may be maintained separately or together in any arrangement deemed suitable.

Referring toFIG.5, flowchart500provides one example of a potential set of rules that may, in one or more embodiments, be applied by a central orchestrator (or one or more decision engines). At505, multiple decision engines are implemented to obtain multiple determinations. At510, if none of the decision engines provides a response, the rules may, at520, commence an authorization process. If one or more responses have been received from one or more decision engines, it may be determined, at515, whether all of the determinations “pass” (i.e., promote) the login request. If so, the authorization process may be commenced at520. If not all of the decision engines determine that the login request should promote the login request, it can be determined whether any of the decision engines fail the login request at525. If yes, the system may block login attempt at530. If no, then at535it is determined whether any of the decision engines determine that the login request should be challenged. If yes, at540a challenge question may be posed.

At545, if the challenge question results in a “correct” or otherwise acceptable response, the system may proceed to the authorization process at520. If the challenge question is incorrect or otherwise unacceptable, either another challenge question may be issued at540, or the login attempt blocked at530. In various configurations, if at535any of the decision engines determine that a challenge should be issued, the system may determine whether a challenge was previously imposed and passed at550. If yes, the system may proceed to the authorization process at520. If no, the system may issue a challenge question at540. If the challenge question of540is passed, then the system may either block the login attempt530, or issue another challenge question at540. If the challenge question is passed, the system may proceed to the authorization process at520. In alternative configurations, although not shown explicitly, multiple challenge questions may be issued, such that the system proceeds from545back to540rather than to520unless and until two or more challenge questions have passed. It is noted that this is but one possible set of rules, and other criteria and policies may be applied by the central orchestrator. For example, it may first be determined whether the IP address of a computing device being used to request login is on a list (such as a “whitelist”), in which case the login process may be allowed to proceed to authorization.

The above-described systems and methods provide for enhanced login and authentication systems that enhance security measures. For example, the risk assessments of multiple different decision engines may be consolidated to better evaluate whether a login request is submitted by a human user or a bot, better than can be accomplished with the risk assessment of a single decision engine. The disclosed login and fraud prevention approaches help reduce fraud and data breaches resulting from false negatives. The disclosed approaches also improve reliability of a system by reducing the number of legitimate login attempts that are rejected as a result of false positives.

The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings.

It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for.”

An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Each memory device may include non-transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3D NAND, NOR, 3D NOR, etc.), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc. Combinations of the above are also included within the scope of machine-readable media. In this regard, machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Each respective memory device may be operable to maintain or otherwise store information relating to the operations performed by one or more associated circuits, including processor instructions and related data (e.g., database components, object code components, script components, etc.), in accordance with the example embodiments described herein.

It should also be noted that the term “input devices,” as described herein, may include any type of input device including, but not limited to, a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. Comparatively, the term “output device,” as described herein, may include any type of output device including, but not limited to, a computer monitor, printer, facsimile machine, or other output devices performing a similar function.

It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the machine-readable media and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.

The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.