Patent ID: 12238088

DETAILED DESCRIPTION

In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown, by way of illustration, various embodiments in which aspects of the disclosure may be practiced. In some instances, other embodiments may be utilized, and structural and functional modifications may be made, without departing from the scope of the present disclosure.

It is noted that various connections between elements are discussed in the following description. It is noted that these connections are general and, unless specified otherwise, may be direct or indirect, wired or wireless, and that the specification is not intended to be limiting in this respect.

As a brief introduction of the concepts described in further detail below, systems and methods for improved application security and authentication are described herein. For example, many enterprise organizations operate, at least in part, online. Accordingly, people may be inclined to use digital services for banking, transportation booking, hotel reservations, managing funds, and/or otherwise. In these instances, however, customers may have to remember passwords associated with each of these applications. In some instances, if a user has a banking relationship with multiple financial institutions, they may use the same password for each to avoid having to remember different passwords. For example, if the wrong password is used too many times, the customer may experience an account lockout. In these instances, however, if one application password is exposed to an attacker, the attacker may gain access to all the remaining applications (e.g., as the password is the same for all applications). This may be referred to as a password stuffing attack. Described herein is a method for adding uniqueness to passwords without additional friction.

For example, upon successful multifactor authentication, a server may generate a one time use authentication token and an N×N data vector, and may send both to a user device (such as a wearable device). The server may store both the values for future reference. The user device may store the authentication token and the N×N data vector that are received from server.

During authentication, the server may request the authentication token from the user device. Upon successful validation, the server may send a random reference array of the N×N vector to the user device. The user device may use the reference array and extract corresponding vector values that may act as a cryptographic hash salt to create a unique hash at every login.

This may result in a rotatable one-time-use hash salt at the user end rather than the server. Additionally, a unique password hash may be generated for every app despite using the same password by the customer. Furthermore, no additional friction may be experienced by the customer, and the customer may be able to use a common password for multiple applications.

FIGS.1A-1Bdepict an illustrative computing environment for using a local hash salt to prevent credential stuffing attacks in accordance with one or more example embodiments. Referring toFIG.1A, computing environment100may include one or more computer systems. For example, computing environment100may include a wearable device102, a user device103, and a key generation and authentication platform104.

Wearable device102may be and/or otherwise include a smart watch, fitness tracker, biometric monitor, smart ring, and/or other wearable and/or internet of things (IoT) device that may be used by an individual to access an application (which may, e.g., also be accessed by a primary user device such as the user device103). In some instances, the wearable device102may be configured to display one or more user interfaces (e.g., application interfaces, or the like). Although a single wearable device102is shown, any number of wearable devices may be deployed in the systems and methods described below without departing from the scope of the disclosure. Furthermore, although a wearable device is described, in some instances, any other device may be deployed without departing from the scope of the disclosure (e.g., smartphone, tablet, and/or other device).

User device103may be and/or otherwise include a laptop computer, desktop computer, mobile device, tablet, smartphone, and/or other device that may be used by an individual to access an application (that may e.g., similarly be accessed by one or more wearable devices such as wearable device102). In some instances, the user device103may be configured to synchronize with the wearable device102. In some instances, user device103may be configured to display one or more user interfaces (e.g., application interfaces, or the like). Although a single user device103is shown, any number of user devices may be deployed in the systems/methods described below without departing from the scope of the disclosure.

As described further below, key generation and authentication platform104may be a computer system that includes one or more computing devices (e.g., servers, server blades, or the like) and/or other computer components (e.g., processors, memories, communication interfaces) that may be used to provide vector key generation and/or password hash verification services as described further below.

Computing environment100also may include one or more networks, which may interconnect wearable device102, user device103, and/or key generation and authentication platform104. For example, computing environment100may include a network101(which may interconnect, e.g., wearable device102, user device103, and/or key generation and authentication platform104).

In one or more arrangements, wearable device102, user device103, and key generation and authentication platform104may be any type of computing device capable of sending and/or receiving requests and processing the requests accordingly. For example, wearable device102, user device103, key generation and authentication platform104and/or the other systems included in computing environment100may, in some instances, be and/or include server computers, desktop computers, laptop computers, tablet computers, smart phones, or the like that may include one or more processors, memories, communication interfaces, storage devices, and/or other components. As noted above, and as illustrated in greater detail below, any and/or all of user device wearable device102, user device103, and/or key generation and authentication platform104may, in some instances, be special-purpose computing devices configured to perform specific functions.

Referring toFIG.1B, key generation and authentication platform104may include one or more processors111, memory112, and communication interface113. A data bus may interconnect processor111, memory112, and communication interface113. Communication interface113may be a network interface configured to support communication between key generation and authentication platform104and one or more networks (e.g., network101, or the like). Memory112may include one or more program modules having instructions that when executed by processor111cause key generation and authentication platform104to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor111. In some instances, the one or more program modules and/or databases may be stored by and/or maintained in different memory units of key generation and authentication platform104and/or by different computing devices that may form and/or otherwise make up key generation and authentication platform104. For example, memory112may have, host, store, and/or include key generation and authentication module112aand key generation and authentication database112b.

Key generation and authentication module112amay have instructions that direct and/or cause key generation and authentication platform104to provide improved application security and authentication mechanisms, as discussed in greater detail below. Key generation and authentication database112bmay store information used by key generation and authentication module112aand/or key generation and authentication platform120in application of advanced techniques to provide improved application security and authentication mechanisms, and/or in performing other functions.

FIGS.2A-2Gdepict an illustrative event sequence for use of a local hash salt to prevent credential stuffing attacks in accordance with one or more example embodiments. Referring toFIG.2A, at step201, the wearable device102may establish a connection with the user device103. For example, the wearable device102may establish a first wireless data connection with the user device103to link the wearable device102to the user device103(e.g., in preparation for authenticating with the user device103). In some instances, the wearable device102may identify whether or not a connection is already established with the user device103. If a connection is already established with the If a connection is not yet established with the user device103, the wearable device102may establish the first wireless data connection as described herein.

At step202, the wearable device102may authenticate to the user device103. For example, the wearable device102may authenticate to the user device103while the first wireless data connection is established. For example, the wearable device102may provide an authentication token and/or other credentials to the user device103to register the wearable device102with the user device103. By authenticating the wearable device102, the user device103may configure the wearable device102for communication with the user device103.

At step203, the user device103may establish a connection with the key generation and authentication platform104. For example, the user device103may establish a second wireless data connection with the key generation and authentication platform104to link the user device103with the key generation and authentication platform104(e.g., in preparation for authenticating to the key generation and authentication platform104). In some instances, the user device103may identify whether or not a connection is already established with the key generation and authentication platform104. If a connection is already established with the key generation and authentication platform104, the user device103might not re-establish the connection. If the connection is not yet established with the key generation and authentication platform104, the user device103may establish the second wireless data connection as described herein.

At step204, the user device103may authenticate to the key generation and authentication platform104. For example, the user device103may authenticate to the key generation and authentication platform104while the second wireless data connection is established. In some instances, the user device103may authenticate to the key generation and authentication platform104by providing an authentication token (which may be the same as the token received from the wearable device102, or may be a different token), and/or other credentials. In these instances, the key generation and authentication platform104may validate the user device103by comparing the authentication token to a stored authentication token. If the key generation and authentication platform104successfully validates the user device103, the key generation and authentication platform104may proceed to step205. Otherwise, the key generation and authentication platform104may continue to wait until a valid authentication token has been received. In validating the user device103, the key generation and authentication platform104may configure the user device103for communication with the key generation and authentication platform104.

Referring toFIG.2B, at step205, the key generation and authentication platform104may generate an IoT vector key for the user device103. For example, the key generation and authentication platform104may generate a matrix similar to the IoT vector key505, which is shown inFIG.5, which may be an N×N vector matrix that includes a plurality of hash salt values, each defined by a row/column intersection within the N×N vector matrix. For example, as shown in the IoT vector key505, the intersection of row 4 and column B may have a corresponding hash salt value of 8.

At step206, the key generation and authentication platform104may store the IoT vector key, generated at step206. For example, the key generation and authentication platform104may store the IoT vector key in an application database, which may, e.g., include a stored correlation between the IoT vector key and the user device103. By storing the IoT vector key, the key generation and authentication platform104may enable future password verification as described further below.

At step207, the key generation and authentication platform104may send the IoT vector key to the user device103. For example, the key generation and authentication platform104may send the IoT vector key to the user device103via the communication interface113and while the second wireless data connection is established.

At step208, the user device103may receive the IoT vector key send at step207. For example, the user device103may receive the IoT vector key while the second wireless data connection is established.

At step209, the user device103may route the IoT vector key to the wearable device102. For example, the user device103may route the IoT vector key to the wearable device102while the first wireless data connection is established.

At step210, wearable device102may receive the IoT vector key sent at step209. For example, the wearable device102may receive the IoT vector key while the second wireless data connection is established.

Referring toFIG.2C, at step211, the wearable device102may send an application access request to the user device103. For example, the wearable device102may send, after receiving the IoT vector key, a request to access one or more applications hosted by the wearable device102and/or user device103. In some instances, the wearable device102may send the application access request to the user device103while the first wireless data connection is established. In some instances, the wearable device102may send, along with the application access request, the authentication token and/or other authentication credentials (e.g., a numeric passcode, alphanumeric passcode, biometric input, retina scan, facial scan, and/or other credentials). In some instances, the authentication credentials may be shared among one or more different applications accessible by the wearable device102and/or the user device103. For example, the user may have a single password, which may, e.g., be used to access a plurality of different applications. In this example, however, as is described further below, the ultimate password hash derived for each application may be different regardless of the use of a common seed password.

At step212, the user device103may receive the application access request sent at step211. For example, the user device103may receive the application access request while the first wireless data connection is established.

At step213, the user device103may validate the application access request. For example, the user device103may validate that the wearable device102is configured for communication with the user device103, that a valid authentication token was presented, prompt a user for multifactor authentication credentials (e.g., password, biometric input, and/or otherwise), and/or otherwise validate the application access request. If the application access request is validated, the user device103may proceed to step214. Otherwise, the user device103may wait until a valid application access request is received.

At step214, based on successfully validating the application access request, the user device103may request a reference array from the key generation and authentication platform104. For example, the user device103may request the reference array while the second wireless data connection is established.

At step215, the key generation and authentication platform104may generate the requested reference array, and send the reference array to the user device103. For example, the key generation and authentication platform104may generate a reference array similar to the sample 12 digit reference key illustrated in table605ofFIG.6. More specifically, the key generation and authentication platform104may generate a sequence of row/column combinations corresponding to the IoT vector key (e.g., A5, D8, C3, or the like). In some instances, the key generation and authentication platform104may send the reference array to the user device103while the second wireless data connection is established. In some instances, the reference array may be specific to the application requested at step211. For example, the key generation and authentication platform104may generate application specific reference arrays for each application accessible by the wearable device102and/or the user device103. In doing so, the key generation and authentication platform104may enable the use of a common password to be used across multiple applications by creating, through the use of the application specific reference arrays, different salt values for each application. When combined with the common password, these different salt values may enable the generation of unique password hashes for each application that may be used for authentication.

By providing the IoT vector key to a plurality of wearable devices (including the wearable device102), and subsequently producing a reference array specific to a requested application, any number of different wearable devices may be used to support the authentication measures described herein (e.g., because any wearable device may provide the reference array salt values corresponding to the reference array by accessing a stored IoT vector key).

In some instances, the reference array may be specific to the application access request. For example, if subsequent access to the application is requested, a different reference array, specific to the subsequent access request, may be generated and provided to the wearable device102(and/or other wearable devices).

With reference toFIG.2D, at step216, the user device103may request, from the wearable device102, the reference array hash salt values. For example, the user device103may send a request to the wearable device102to identify the hash salt values, included in the IoT vector key, corresponding to the reference array (e.g., as shown in the derived hash salt of table605ofFIG.6). For example, the user device103may request the reference array hash salt values while the first wireless data connection is established.

At step217, the wearable device102may identify the reference array hash salt values corresponding to the reference array. For example, the wearable device102may use the stored IoT vector key to identify values corresponding to the row/column combinations provided in the reference array. In doing so, the wearable device102may produce reference array hash salt values corresponding to the derived hash salt of table605inFIG.6. Then the wearable device102may send the reference array hash salt values to the user device103(e.g., while the first wireless data connection is established).

At step218, the user device103may generate a modified password corresponding to the application access request. For example, the user device103may concatenate and/or otherwise combine the reference array hash salt values with the user authentication credentials previously received (e.g., a password, biometric identifier, and/or other information). For example, the user device103may produce a modified password that comprises “password.derivedhashsalt.”

At step219, the user device103may hash the modified password, produced at step218, to produce a password hash. For example, the user device103may hash the modified password of “password.derivedhashsalt” to produce “passwordhash.”

Although obtaining reference array hash salt values from a single wearable device102is described, any number of salt values may be obtained from any number of single wearable devices without departing from the scope of this disclosure. For example, a modified password of “password.derivedhashsalt1.derivedhashsalt2” may be produced by obtaining hash salt values from a pair of wearable devices.

Referring toFIG.2E, at step220, the user device103may send the password hash to the key generation and authentication platform104. For example, the user device103may send the password hash to the key generation and authentication platform104while the second wireless data connection is established.

At step221, the key generation and authentication platform104may generate a server side password hash. For example, the key generation and authentication platform104may perform actions similar to those described above with regard to steps217to derive the reference array hash salt values, password, and password hash.

At step222, the key generation and authentication platform104may compare the password hash received from the user device103to the server side hash produced at step221. Based on identifying that the password hashes match, the key generation and authentication platform104may proceed to step223. Otherwise, if the password hashes do not match, the key generation and authentication platform104may proceed to step230. At step223, the key generation and authentication platform104may grant access to the requested application to the wearable device102and/or the user device103.

Referring toFIG.2F, at step224, after granting access to the requested application, the key generation and authentication platform104may update the IoT vector key. For example, the key generation and authentication platform104may generate an updated version of the N×N vector matrix generated at step205.

At step225, the key generation and authentication platform104may store and send the updated IoT vector key. For example, the key generation and authentication platform104may overwrite the existing stored IoT vector key with the updated IoT vector key, and may send the updated IoT vector key to the user device103. For example, the key generation and authentication platform104may send the updated IoT vector key to the user device103while the second wireless data connection is established.

At step226, the user device103may receive the updated IoT vector key sent at step226. For example, the user device103may receive the updated IoT vector key while the second wireless data connection is established.

At step227, the user device103may route the updated IoT vector key to the wearable device102. For example, the user device103may send the updated IoT vector key to the wearable device102while the first wireless data connection is established.

At step228, the wearable device102may receive the updated IoT vector key sent at step227. For example, the wearable device102may receive the updated IoT vector key while the first wireless data connection is established.

At step229, the wearable device102may store the updated IoT vector key. For example, the wearable device102may overwrite the previously stored IoT vector key with the updated IoT vector key. In doing so, the hash salt values provided by the wearable device102for subsequent application access requests may be continuously changed for increased security.

Returning to step222, if the password hashes do not match, the key generation and authentication platform104may proceed to step230inFIG.2G. At step230, the key generation and authentication platform104may send a notification to the wearable device102and/or the user device103indicating that access is denied. In some instances, the key generation and authentication platform104may also send one or more commands directing the wearable device102and/or the user device103to display the notification.

At step231, based on or in response to the one or more commands directing the wearable device102and/or the user device103to display the notification, the wearable device102and/or the user device103may display the notification. For example, the wearable device102and/or the user device103may display a graphical user interface similar to graphical user interface405, which is illustrated inFIG.4.

By operating in this way, users may be able to securely use a single password across a plurality of applications, which may, for example, improve user experience by reducing the number of passwords to be memorized and reducing a number of failed login attempts (and thus corresponding account lockouts). Similarly, these systems and methods may protect against password stuffing attacks by creating different password hashes, based on a user password and unique application hash salt, for each application. Accordingly, even if a user has a common password for multiple applications, and the password is exposed to an attacker, the user's remaining accounts may remain secure against attacks. Additionally, even if a password for a particular application is exposed, the user's account may remain secure against attacks as the attackers might not have access to the unique hash salt, provided by the user's wearable device, needed to authorize access to the application and/or other accounts. This may allow a single password to be used across various applications and/or devices without sacrificing security.

FIG.3depicts an illustrative method for using a local hash salt to prevent credential stuffing attacks in accordance with one or more example embodiments. At step305, a computing platform may authenticate a wearable device and/or user device. At step310, the computing platform may provide an IoT vector key to the wearable and user device. At step315, the computing platform may receive an application access request. At step320, the computing platform may request reference array vector values. At step325, the computing platform may receive the reference array vector values. At step330, the computing platform may generate a hash salt using the reference array vector values. At step335, the computing platform may generate a password hash based on the hash salt.

At step340, the computing platform may identify whether or not the password hash is validated. If the password is validated the computing platform may proceed to step345. At step345, the computing platform may grant application access. At step350, the computing platform may provide an updated IoT vector key to the wearable device and/or user device.

Returning to step340, if the password hash is not validated, the computing platform may proceed to step355. At step355, the computing platform may send a notification that access to the application has been denied.

One or more aspects of the disclosure may be embodied in computer-usable data or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices to perform the operations described herein. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types when executed by one or more processors in a computer or other data processing device. The computer-executable instructions may be stored as computer-readable instructions on a computer-readable medium such as a hard disk, optical disk, removable storage media, solid-state memory, RAM, and the like. The functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGA), and the like. Particular data structures may be used to more effectively implement one or more aspects of the disclosure, and such data structures are contemplated to be within the scope of computer executable instructions and computer-usable data described herein.

Various aspects described herein may be embodied as a method, an apparatus, or as one or more computer-readable media storing computer-executable instructions. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment, an entirely firmware embodiment, or an embodiment combining software, hardware, and firmware aspects in any combination. In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of light or electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, or wireless transmission media (e.g., air or space). In general, the one or more computer-readable media may be and/or include one or more non-transitory computer-readable media.

As described herein, the various methods and acts may be operative across one or more computing servers and one or more networks. The functionality may be distributed in any manner, or may be located in a single computing device (e.g., a server, a client computer, and the like). For example, in alternative embodiments, one or more of the computing platforms discussed above may be combined into a single computing platform, and the various functions of each computing platform may be performed by the single computing platform. In such arrangements, any and/or all of the above-discussed communications between computing platforms may correspond to data being accessed, moved, modified, updated, and/or otherwise used by the single computing platform. Additionally or alternatively, one or more of the computing platforms discussed above may be implemented in one or more virtual machines that are provided by one or more physical computing devices. In such arrangements, the various functions of each computing platform may be performed by the one or more virtual machines, and any and/or all of the above-discussed communications between computing platforms may correspond to data being accessed, moved, modified, updated, and/or otherwise used by the one or more virtual machines.

Aspects of the disclosure have been described in terms of illustrative embodiments thereof. Numerous other embodiments, modifications, and variations within the scope and spirit of the appended claims will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one or more of the steps depicted in the illustrative figures may be performed in other than the recited order, and one or more depicted steps may be optional in accordance with aspects of the disclosure.