Patent Application
20190306155
This disclosure relates generally to user authentication, and more particularly to generating cryptographic keys using supplemental authentication data for use in user authentication.
Server systems, such as web server systems, application server systems, etc., may provide various computing resources to an end user. For example, an application server may provide access to software applications to various end users. The server system may limit access to its resources to only authorized end users. One method of limiting access is to require end users to provide credentials, such as a username and password, to the server system, which the server system may use to authenticate the requesting end user prior to providing access to the resource. In some instances, however, the use of such credentials may be susceptible to various vulnerabilities (e.g., phishing attacks), presenting security concerns. Thus, in various instances, it may be desirable to utilize secondary user authentication techniques.
Techniques are disclosed relating to generating cryptographic keys using supplemental authentication data for use in user authentication. In one embodiment, an authentication application executing on a computing device may access an initial cryptographic key that is shared with an authentication server configured to authenticate a user of the computing device to a service provided by a server system. The authentication application may execute a routine to obtain a supplemental authentication data value that is not stored by the computing device prior to executing the routine. For example, in one embodiment, executing the routine to obtain the supplemental authentication data value may include determining one or more device attributes associated with the computing device and performing a cryptographic function on a string that specifies the one or more device attributes to obtain the supplemental authentication data value. In another embodiment, for example, executing the routine to obtain the supplemental authentication data value may include receiving user input indicative of a user-provided password, and performing a cryptographic function on the user-provided password to generate the supplemental authentication data value. Further, the authentication application may generate an updated cryptographic key based on the initial cryptographic key and the supplemental authentication data value. In some embodiments, the authentication application may use the updated cryptographic key to generate a one-time passcode that, when communicated to an authentication server, may be usable to authenticate the user to the service.
Referring to
In various embodiments, server system 106 may be configured to provide services (e.g., software applications, email services, etc.) to various users, such as a user of client device 102. In various instances, server system 106 may limit access to the services it provides only to authorized users (e.g., to protect sensitive data, etc.). A server system may limit access to its services according to various techniques. For example, a server system may require that a user provide valid user credentials (e.g., username, password, PIN code, etc.) to access its services. Such a single, “knowledge-based” authentication factor, however, may present various shortcomings. For example, in the event that a user's credentials are compromised (e.g., through a phishing attack), an unauthorized user may then be able to access the service to the same extent as the authorized user, thus exposing potentially sensitive information and functionality to the unauthorized user.
In some instances, a server system may implement a multi-factor authentication scheme to protect access to the computing resources it provides. For example, in addition to a knowledge-based authentication factor, a server computer system may require a second, “possession-based” authentication factor also be satisfied, e.g., by the user demonstrating that they are in possession of something that they (and only they) have, before authorizing a user to access its services. One such possession-based authentication factor includes having the user provide, to the authenticating entity, authentication information generated by an authentication application installed on a verified client device (e.g., a smartphone, laptop, etc.). In such instances, the authentication application and authentication system may utilize corresponding cryptographic keys (or simply “keys”) as part of a cryptographic scheme used to authenticate the user of the client device to the service provided by the server system. For example, in some embodiments, an authentication application and authentication system may implement a symmetric-key encryption scheme in which both entities maintain a shared, secret cryptographic key. During authentication, the authentication application may use that shared cryptographic key to generate authentication information, such as a one-time passcode (“OTP”), which may be sent to the server system (or a third-party system) for authentication. The authentication system may then generate a corresponding OTP and compare. If the OTP received from the authentication application matches the OTP generated by the authentication system, the authentication system may determine that the requesting user is in possession of the verified client device, satisfying the possession-based authentication factor. If both the knowledge-based and possession-based authentication factors are satisfied, the authentication system may authenticate the user to the service.
Such an approach, however, also suffers from various shortcomings. For example, in the event that the shared, secret cryptographic key is compromised by an unauthorized user (e.g., through malware present on the client device), the unauthorized user may use the cryptographic key to generate OTPs. If an unauthorized user is able to obtain both user credentials and such a cryptographic key used to generate OTPs, the unauthorized user may use this information to pose as the authorized user and access the service provided by the server system.
In at least some embodiments, the disclosed systems and methods may mitigate these or other shortcomings by using an updated cryptographic key (which is not retained by the client device for future usage) to generate the OTPs. Stated differently, disclosed embodiments include generating, at the time of authentication, an updated cryptographic key based on a shared cryptographic key and supplemental authentication data. That updated cryptographic key may then be used to generate one or more OTPs to authenticate the user to the service. As will be discussed in more detail below, such embodiments may present various advantages. For example, in such embodiments, it is the shared cryptographic key that is retained by the client device—not the updated cryptographic key used to generate the OTPs. Accordingly, even if an unauthorized user were to acquire the shared cryptographic key, that unauthorized user would still be unable to successfully pose as the authorized user because the shared cryptographic key, alone, cannot generate valid OTPs.
Referring again to the embodiment depicted in
System 100 includes authentication application 104. In various embodiments, authentication application 104 may be operable to generate OTPs using an updated cryptographic key that is generated at the time of authentication. For example, as shown in
Authentication application 104 further includes updated key generator 110. As will be explained in more detail below with reference to
Once generated by authentication application 104, OTP 126 may be output such that client device 102 may send it, along with user credentials 128, to server system 106 for authentication. In various embodiments, server system 106 may delegate the process of authenticating the access requests that it receives (e.g., from client device 102) to authentication server system 108. In various embodiments, authentication server system 108 is a computer system that is operable to perform authentication operations for various services provided by various server systems. For example, in the embodiment depicted in
The present disclosure concerns technical problems in the field of user authentication. More specifically, the disclosed systems and methods, in at least some embodiments, address security concerns associated with storing cryptographic keys, used to generate OTPs for use in user authentication, on a client device. For example, consider an instance in which a client device is, unbeknownst to the user, compromised with malware capable of identifying sensitive authentication information (e.g., user credentials, stored cryptographic keys, etc.) and transmitting that information to an unauthorized user at a remote computer system. In an alternative system that does not utilize the disclosed systems or methods, the unauthorized user may be able to use this sensitive authentication information to generate valid OTPs and successfully pose as the authorized end user, accessing the service provided by server system 106. In various embodiments of the present disclosure, however, the unauthorized user would be unable to generate valid OTPs using this compromised information because, in at least some embodiments, the disclosed systems and methods use an updated cryptographic key 124, which is not retained in any permanent storage of the client device after authentication, to generate the valid OTPs 126. Further, in at least some embodiments, this updated cryptographic key 124 is not transmitted over the communication network. Accordingly, in various embodiments, the disclosed systems and methods prevent the unauthorized user from gaining unauthorized access to the service provided by server system 106 while posing as the user of client device 102. Thus, the disclosed systems and methods, in at least some embodiments, improve user authentication by securing the cryptographic keys used to generate OTPs, improving the user authentication process and the functioning of system 100 as a whole.
As noted above, supplemental authentication data value 122 may be obtained from various sources, according to various embodiments. The following discussion, with reference to
Turning now to
In
As noted above, authentication application 104, in various embodiments, is configured to generate an updated cryptographic key 124 based on an initial cryptographic key 120 and a supplemental authentication data value 122. In the embodiment of
Authentication application 200 further includes device-specific key generator 208, which, in various embodiments, is operable to generate a device-specific cryptographic key 222 based on string 220. Device-specific key generator 208 may use any suitable key-derivation function in generating device-specific cryptographic key 222. For example, in various embodiments, device-specific key generator 208 may use Password-Based Key Derivation Function 2 (PBKDF2), Argon2, or any other suitable key-derivation function, including various hash-based algorithms, to generate device-specific cryptographic key 222.
Authentication application 200 further includes updated key generator 110. In various embodiments, updated key generator 110 may generate updated cryptographic key 124 based on an initial cryptographic key 120 and supplemental authentication data, which, in the embodiment of
Thus, in the embodiment depicted in
Additionally, in some embodiments, authentication application 200 may perform various authentication operations shown in
For example, such continued authentication operations may include generating, by authentication application 200, an updated OTP 126 after a particular time interval (e.g., 60 seconds since the last OTP 126 was sent) and providing that updated OTP 126 in an updated request to server system 106. In some embodiments, the frequency with which the updated OTPs 126 are sent to the server system 106 may vary based on a security preference of the user, the service, server system 106, or authentication server system 108. For example, for particularly sensitive services (e.g., banking software applications), updated OTPs 126 may be generated at a higher frequency (e.g., every 30 seconds). For less sensitive services (e.g., a social media website), OTPs 126 may be generated at a lower frequency (e.g., every 5 minutes). In various embodiments, such continued authentication operations may help ensure to authentication server system 108 and server system 106 the continued authentication of the user of client device 102 during the course of a user session, rather than simply once at the initiation of a user session.
Referring now to
In
For example, in one embodiment, when a user attempts to access the service provided by server system 106, the user may be prompted (e.g., via a web page) to provide user credentials and an OTP. The user may launch authentication application 250 and request that an OTP be generated. Authentication application 250 may then prompt the user to provide (e.g., via a touchscreen, keyboard, etc.) user input indicative of a password 260, such as an alphanumeric string or PIN code. As shown in
Thus, in the embodiment depicted in
As will be appreciated by of ordinary skill in the art with the benefit of this disclosure, aspects of authentication applications 200 and 250 may be combined in any suitable manner, in various embodiments. For example, in one embodiment, the supplemental authentication data value 122 may be based both on one or more device attributes and a user-provided password. In such an embodiment, authentication application 104 may, as described with reference to
Turning now to
As shown in
In some embodiments, authentication server system 108 may use user credentials 128 to retrieve a cryptographic key 310 associated with the user for the particular service provided by server system 106. Authentication server system 108 further includes OTP generator 304, which, in various embodiments, is configured to generate server OTPs 312 based on cryptographic key 310. Note that, in various instances, authentication server system 108 may be less susceptible to compromise by an unauthorized user than client device 102. For example, client device 102 may be exposed to numerous sources of potential threat to which authentication server system 108 is not. In some instances, for example, a client device 102 may have various user applications installed thereon that would not be installed on authentication server system 108, presenting additional opportunities for malware to be introduced to the client device 102. Further, in instances in which client device 102 is a portable computing device, such as a smartphone or laptop, more people may have access to client device 102 than would have access to authentication server system 108. Accordingly, in various embodiments, rather than generating an updated cryptographic key at the time of authentication, the authentication server system 108 may simply store the cryptographic key 310 that corresponds to the updated cryptographic key 124 generated by authentication application 104. Note, however, that in some other embodiments, authentication server system 108 may instead store a key that corresponds to the initial cryptographic key 120 and a data value that corresponds to the supplemental authentication data value 122 of
Authentication server system 108 further includes comparator 306. In various embodiments, comparator 306 is operable to compare server OTP 312 with OTP 126 received from server system 106 and generate authentication indication 314. In various embodiments, authentication indication 314 may be expressed as a Boolean value, numeric value, or in any other suitable format that specifies the outcome of the comparison performed by comparator 306. Authentication indication 314 may, in various embodiments, be provided to server system 106 and may indicate whether the user is authenticated to the service. For example, in response to server OTP 312 matching OTP 126, authentication indication 314 may indicate that the user of client device 102 is authenticated to the service. If, however, server OTP 312 does not match OTP 126, authentication indication 314 may indicate that the user is not authenticated to the service, and server system 106 or authentication server system 108 may take one or more corrective actions, such as denying the user access to the service, prompting the user to provide an additional OTP 126, providing the user with a challenge question, etc.
Further note that, although server system 106 and authentication server system 108 are shown separately in
Referring now to
In
Method 400 then proceeds to element 404, which includes executing, by the authentication application, a routine to obtain a supplemental authentication data value that is not stored by the computing device prior to executing the routine. For example, as discussed in more detail below with reference to
Method 400 then proceeds to element 406, which includes generating, by the authentication application, an updated cryptographic key based on the initial cryptographic key and the supplemental authentication data value. For example, as discussed above with reference to
Method 400 then proceeds to element 408, which includes generating, by the authentication application using the updated cryptographic key, a one-time passcode. As discussed above, OTP generator 112 may utilize any suitable OTP generation algorithm in generating OTP 126. For example, in one embodiment, generating OTP 126 may include implementing a time-based OTP algorithm using the updated cryptographic key 124, a time-based value, and a particular hash function.
Method 400 then proceeds to element 410, which includes outputting, by the authentication application, the one-time passcode. For example, authentication application 104 (whether executing on a separate computing device or on client device 102) may output OTP 126 such that client device 102 may send OTP 126 to server system 106 for authentication. In some embodiments, server system 106 may utilize authentication server system 108 to authenticate various end users to the services provided by server system 106. In such embodiments, the OTP may be usable by authentication server system 108 to authenticate the user of client device 102 to that service.
As discussed above, supplemental authentication data may be obtained from various sources, according to some embodiments. For example, element 404 of method 400 includes executing a routine to obtain supplemental authentication data that is not stored by the computing device prior to executing the routine. This supplemental authentication data may, in various embodiments, be used in generating a cryptographic key for use in user authentication. The following discussion, with reference to
Turning to
Element 502 includes determining one or more device attributes associated with the computing device on which the authentication application is executing. For example, with reference to
Method 500 then proceeds to element 504, which includes performing a cryptographic function on a string that specifies the one or more device attributes to obtain a device-specific cryptographic key. For example, as noted above, device-specific key generator 208 of
Referring now to
Element 552 includes receiving user input indicative of a user-provided password. For example, with reference to
Referring now to
Processor subsystem 620 may include one or more processors or processing units. In various embodiments of computer system 600, multiple instances of processor subsystem 620 may be coupled to interconnect 680. In various embodiments, processor subsystem 620 (or each processor unit within 620) may contain a cache or other form of on-board memory.
System memory 640 is usable to store program instructions executable by processor subsystem 620 to cause system 600 perform various operations described herein. System memory 640 may be implemented using different physical, non-transitory memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system 600 is not limited to primary storage such as system memory 640. Rather, computer system 600 may also include other forms of storage such as cache memory in processor subsystem 620 and secondary storage on I/O devices 670 (e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem 620.
I/O interfaces 660 may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface 660 is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces 660 may be coupled to one or more I/O devices 670 via one or more corresponding buses or other interfaces. Examples of I/O devices 670 include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, I/O devices 670 includes a network interface device (e.g., configured to communicate over WiFi, Bluetooth, Ethernet, etc.), and computer system 600 is coupled to a network via the network interface device.
Although the embodiments disclosed herein are susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the figures and are described herein in detail. It should be understood, however, that figures and detailed description thereto are not intended to limit the scope of the claims to the particular forms disclosed. Instead, this application is intended to cover all modifications, equivalents and alternatives falling within the spirit and scope of the disclosure of the present application as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description.
This disclosure includes references to “one embodiment,” “a particular embodiment,” “some embodiments,” “various embodiments,” “an embodiment,” etc. The appearances of these or similar phrases do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.
As used herein, the term “based on” is used to describe one or more factors that affect a determination. This term does not foreclose the possibility that additional factors may affect the determination. That is, a determination may be solely based on specified factors or based on the specified factors as well as other, unspecified factors. Consider the phrase “determine A based on B.” This phrase specifies that B is a factor that is used to determine A or that affects the determination of A. This phrase does not foreclose that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover an embodiment in which A is determined based solely on B. As used herein, the phrase “based on” is synonymous with the phrase “based at least in part on.”
As used herein, the phrase “in response to” describes one or more factors that trigger an effect. This phrase does not foreclose the possibility that additional factors may affect or otherwise trigger the effect. That is, an effect may be solely in response to those factors, or may be in response to the specified factors as well as other, unspecified factors. Consider the phrase “perform A in response to B.” This phrase specifies that B is a factor that triggers the performance of A. This phrase does not foreclose that performing A may also be in response to some other factor, such as C. This phrase is also intended to cover an embodiment in which A is performed solely in response to B.
As used herein, the terms “first,” “second,” etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.), unless stated otherwise. When used in the claims, the term “or” is used as an inclusive or and not as an exclusive or. For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, as well as any combination thereof (e.g., x and y, but not z).
It is to be understood that the present disclosure is not limited to particular devices or methods, which may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” include singular and plural referents unless the context clearly dictates otherwise. Furthermore, the word “may” is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not in a mandatory sense (i.e., must). The term “include,” and derivations thereof, mean “including, but not limited to.” The term “coupled” means directly or indirectly connected.
Within this disclosure, different entities (which may variously be referred to as “units,” “circuits,” other components, etc.) may be described or claimed as “configured” to perform one or more tasks or operations. This formulation—[entity] configured to [perform one or more tasks]—is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform the one or more tasks during operation. A structure can be said to be “configured to” perform some task even if the structure is not currently being operated. A “memory device configured to store data” is intended to cover, for example, an integrated circuit that has circuitry that performs this function during operation, even if the integrated circuit in question is not currently being used (e.g., a power supply is not connected to it). Thus, an entity described or recited as “configured to” perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible.
The term “configured to” is not intended to mean “configurable to.” An unprogrammed FPGA, for example, would not be considered to be “configured to” perform some specific function, although it may be “configurable to” perform that function after programming.
Reciting in the appended claims that a structure is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) for that claim element. Accordingly, none of the claims in this application as filed are intended to be interpreted as having means-plus-function elements. Should Applicant wish to invoke Section 112(f) during prosecution, it will recite claim elements using the “means for” [performing a function] construct.
In this disclosure, various “modules” configured to perform designated functions are shown in the figures and described in detail above (e.g., updated key generator 110, OTP generator 112, device attribute determination module 206, comparator 306, etc.). As used herein, the term “module” refers to circuitry configured to perform specified operations or to physical, non-transitory computer-readable media that stores information (e.g., program instructions) that instructs other circuitry (e.g., a processor) to perform specified operations. Such circuitry may be implemented in multiple ways, including as a hardwired circuit or as a memory having program instructions stored therein that are executable by one or more processors to perform the operations. The hardware circuit may include, for example, custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. A module may also be any suitable form of non-transitory computer readable media storing program instructions executable to perform specified operations.
Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.
The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.
