Customizable authentication system

An online authentication system allows a user to define their own logic for multistage authentication, which is provided to an online authentication center and stored as encrypted bytecode based on each user's password. Implementation logic can use third party information sources to provide additional authentication options.

BACKGROUND

Generally, in an authentication application or portal, an authentication algorithm is set by the application or by the portal operators. Users typically provide static credentials, such as username and password, to gain access. Portal operators can also enable multi-factor (multiphase) authentication, adding an additional phase to authentication. Typically, in the second phase a secret code is provided to a user who then repeats the code to the system to demonstrate that the user has access to the user's device, email system, or is somehow privy to the user's secret code. While the individual codes are different, generally, the same single or multiphase authentication process is applied to all users, as decided by the operators of the authentication portal. In some cases, user preferences can be applied to enable or disable multiphase authentication, or to bluntly select which of a few means can be used to deliver the code for the second phase, but the user has little or no control beyond these basic preferences.

The lack of extensibility in the authentication process leads to vulnerabilities. In single phase authentication, reliance on static password-based credentials means that if a password is compromised, an attacker can easily gain access to a system. Furthermore, if passwords are stored on a system, a hacker gaining access to the backend of an authentication system can learn the passwords for all users. Multifactor authentication systems can suffer from similar attacks. Because users often reuse passwords or use similar passwords across devices and systems, an attack that would defeat a simple password-based single factor authentication system has a reasonable likelihood of defeating a multifactor authentication system, as well. For example, if a hacker has stolen a user's password, it is likely that she can access other accounts of that user, making multifactor authentication much weaker.

SUMMARY

According to an embodiment of the present invention, a network-based authentication system, includes a server having a processor and a memory coupled to the server, configured to store user-customized logic at the direction of the server. The server is configured to perform steps of receiving user-customized logic for each of a plurality of users from the authentication system over a network, storing the user-customized logic for each user in the memory in an encrypted form based on a password of each user, and receiving the password of a user. The steps further include decrypting the user-customized logic for the user, receiving additional credentials from the user, verifying the additional credentials by executing the user-customized logic, and granting the user access to network resources responsive to the step of verifying.

In some embodiments, the server is further configured to compile the user-customized logic into bytecode prior to storing the logic as bytecode in the memory. In some embodiments, the step of receiving user-customized logic includes receiving the logic as bytecode from each user. In some embodiments, the server is further configured to provide an API to each user that facilitates user-creation of the user-customized logic. In some embodiments, the server is further configured to request information from a third-party service across the network as part of the step of verifying the additional credentials. In some embodiments, the third-party service is an SAP database or a CRM database, such as Salesforce.

According to an embodiment of the present invention, a method for providing authentication services to a plurality of users includes steps of receiving, at a processor, user-customized logic from each of the plurality of users from a network, storing the user-customized logic for each user in a memory in an encrypted form based on a password of each user, and receiving, during an authentication process, the password of a user. The method further includes steps of decrypting the user-customized logic for the user, receiving additional credentials from the user, verifying, by the processor, the additional credentials by executing the user-customized logic, and sending an electronic message that grants the user access to network resources responsive to the step of verifying.

According to an embodiment of the present invention, that method is accomplished by a computer program product for authenticating any of a plurality of users, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, wherein the computer readable storage medium is not a transitory signal per se, the program instructions executable by a computer processor to cause the processor to perform the method.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Authentication services can be provided by a server or cloud-based authentication portal that receives and stores customized implementation logic (bytecode) from each user at the time of registration of the user. The bytecode provided by the user is encrypted by the server using password-based encryption (PBE) that uses the user's password credentials to encrypt and store the logic on the online authentication portal. This customized bytecode then forms the implementation code for a user-defined, customized authentication process. After registration, during each authentication session, the user provides his user ID and password (or any other password-based credentials) and the server uses these credentials to unlock/decrypt the PBE memory containing the implementation logic. The server then executes it, implementing subsequent authentication steps. The user is asked to authenticate by providing custom credentials per the logic provided by the user at registration. The server executes the logic based on the user response and authenticates the user. This provides a flexible authentication framework beyond traditional multi-factor authentication, which typically uses the same implementation logic for each user. Because the implementation logic is customized by each user, a different customized authentication process can be used for each user. This process allows the authentication experience to go beyond mere password-based credentials or existing multi-factor authentication systems (which typically use the same multi-factor phase for each user, such as allowing each user to select the means by which to receive a code, the repetition of which will demonstrate that the user has access to another user account or device).

Implementation logic is stored as bytecode in encrypted form, based on a user's password, making the authentication system is less prone to attack. If an attacker gains access to the backend of the system, they only gain access to memory containing a series of secure memory spaces that require each user's password to unlock. If an attacker gains access to a user's password, they can only access the bytecode for execution that will then solicit responses to additional challenges (if accessing the backend). Because each user's logic is generally different, no single strategy can then be used to defeat the additional authentication step. Because bytecode is difficult to read outside the system that runs it, the information stored in the PBE memory, even if accessed by an attacker is not very useful. Furthermore, a front-end attack, such as using a user's password to mimic a user, will merely result in being solicited by a custom second phase of authentication. The strength of this second phase can vary by user based on the custom bytecode they provided at registration, but the specific process used in the second phase will be generally different for each user due to the custom implementation code. What might work to defeat the second phase of one user will generally not work for the next user, mitigating any impact of a system intrusion. Furthermore, because the user customizes the second phase, different users can have varying strengths of the second phase. A user with more privileges on a system can create a stronger second phase, while a user who has lower privileges or only accesses something like email, may choose a simpler second phase.

By utilizing PBE stored, custom logic for each user, the authentication system avoids storing static credentials that render many systems vulnerable. For example, biometric data, such as hashes of iris or fingerprint scans, can seem more secure than passwords, but can be quite vulnerable if an attacker gains access to stored information about biometrics on a server. Stored credentials can be vulnerable to brute force techniques. Even when the stored custom code of some embodiments uses a string or hash to compare to the user's credentials, the context of that stored data will not be clear from the contents of the PBE, making it difficult to use any stolen data. Each user can bring a different perspective to authentication, from personal information, real-time data, biometrics, etc. For example, the additional implementation logic created by a user can store a hash of data without any information about how it is generated. Conversely, the encrypted bytecode can include the logic for creating a hash of the user credentials that will be compared to a stored hash such that the hash is only created in real-time based on the user credentials, requiring that an attacker access, decrypt, and run the bytecode through the appropriate execution engine in order reach any stored user credentials.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

Workloads layer90provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation91; software development and lifecycle management92; virtual classroom education delivery93; data analytics processing94; transaction processing95; and user authentication96. Exemplary embodiments on an authentication system that could utilize this cloud computing environment are described throughout this application. In some embodiments, exemplary authentication systems could operate at management level80or workload level90.

A network-based authentication system for use with some embodiments is shown inFIG. 3. Authentication system100allows user102to customize the authentication experience and to later login using the customized implementation code she creates. To accomplish this, the user can use any suitable user client device110. Client device110can be a PC/Mac-based computing system, phone, tablet, or any other suitable computing device coupled to the Internet. In some embodiments, client device110can be a server that user102accesses remotely or by proxy. User102can use the same or different client devices110to create the custom implementation code and to later authenticate with the system. Client device110is shown with components suitable for a client that can create the authentication implementation logic and later login to the system. Client device110includes a CPU112for controlling the device and coordinating the functions relating to implementation code creation and login, as well as any user interface or other features of the device unrelated to authentication. Client device110is a computer, including all relevant components such as memory, storage, internal buses, and any relevant peripheral components or software. Client device110also includes a network connection114for communicating with other devices on a network or across the Internet. This connection can be any suitable connection, including cellular, Wi-Fi, Ethernet, etc.

In some embodiments, user102creates the implementation code using an API or SDK116provided by the authentication system to facilitate creation of code in compliance with design rules for the system or code including modules provided by the system. In some embodiments, API/SDK116is downloaded or remotely accessed by the client during the implementation code creation process (e.g., it may not be entirely resident in client memory and could be accessed remotely via an online portal through client110). In some embodiments, API/SDK116facilitates creating code using java, JavaScript, or any other suitable programming language as selected by system100. In some embodiments, API/SDK116facilitates turning that code into compiled bytecode. In other embodiments, the bytecode compiling step occurs at the server after the user uploads code created using API/SDK116, allowing the authentication system to target current hardware and plug any security holes found in the logic.

In some embodiments, client device110can include third party software or APIs118that allow the client to access third party applications or databases across the Internet. For example, client device110can include an application configured to access a CRM/Salesforce or SAP database, or similar corporate databases. These applications or databases can be protected through their own authentication process, such that only a qualified user102can access information contained therein. In some embodiments, the third party applications or APIs118can be replaced with a web browser, allowing user102to access web-based information sources, such as web portals for corporate databases, CRM resources, such as Salesforce or SAP, or for accessing social media information, such as Facebook, Twitter, Instagram, etc. Depending on the implementation logic the user wishes to create, third-party applications and APIs118can include any suitable means to access network-based information that will be used during the authentication process. In general, third-party applications and APIs118can include access to any suitable network-based resources that the server can also access in some form that could be useful to the implementation logic.

It should be appreciated that each client device110need not necessarily have all these components. For example, when only used to login (or when the API/SDK is web-based, accessed by client device110via a browser or similar application) or when the implementation code does not utilize thirty party apps as part of the custom authentication process (as defined by the user-created implementation code), the client device used by user102to access authentication system may not include all those components shown in client device110.

Client device110interacts across network130, which can include the Internet, with authentication center120. Authentication center120can include one or more servers, and in some embodiments, can be cloud-based. Like client device110, authentication center120is a computer that includes a CPU124, network connection122, and any other suitable components and software needed to perform as a computing system in accordance with embodiments. In addition to standard components of a server-based computing system, authentication center also includes a password-based encryption (PBE) memory storage device126for securely storing user-specific bytecode for each user of authentication system100. This include a storage device, such as one or more hard drives, SSD, RAID, or any suitable cloud or network-based storage systems. PBE storage126can include one or more levels of encryption to protect the stored authentication implementation code for each user. This can include any device-level encryption that prevents accessing the contents of PBE storage should the entire storage device or authentication system120be breached physically or through network-based intrusion. Additionally, each user has a separate virtual memory space within PBE storage126, each space being encrypted using each user's password-based credentials (e.g., username and password). This allows access to the user-specific bytecode stored within, only if CPU124is authenticated to authentication center120and if the user provides the proper username and password at the time of authentication. Then, CPU124can access the implantation bytecode provided by the user at the time of registration to enforce the user's custom authentication logic. Authentication center120can also include third party APIs128to allow CPU124to access network-based information through third party applications or databases.

Connected to network130, third-party applications132can include CRM systems, social media sources, databases, or any other systems of information that may be useful in providing flexible information sources for the implementation logic of users. This allow many customization options for the logic for each user so that each user will generally have different implementation logic for authentication, increasing security of the implementation system. Exemplary third-party applications132can include any of those sources discussed throughout this application or any other source that is enabled by API/SDK116to be used in authentication implementation code.

FIG. 4is a flow chart of the interactions between user102(via client device110), authentication center120, and network-enabled third-party applications and services132during a user registration process140. Not shown inFIG. 4(or other flow charts) are extraneous acknowledgments, handshakes, connection setups, or other communications that occur commonly in network systems that do not help illustrate the concepts related to the features of embodiments. In some embodiments, the registration process can be performed without third party involvement. At step142, if needed, a user registers with third-party services132obtains any APIs118or other information needed to create the custom authentication logic. For example, if the third-party service is an SAP system, the API/information may include credentials sufficient to allow to authentication center120to register and later access any information needed to execute the custom authentication logic. It should be noted that not all third-party services will require this step. At step144, user102receives SDK/API116from the authentication center or from a website run by the provider of authentication services that facilitates the user-creation of custom authentication logic. This can include any information sufficient to assist the user in customizing her authentication process, including libraries, modules, a development environment, a creation wizard, etc. In some embodiments, this step can include accessing an online SDK and development environment or template hosted on a server, accessed via a web browser by user102and need not necessarily be limited to downloading the SDK to client device

At step146, user102creates a username and password. At step148, the username and password are sent to authentication center120. At step150, authentication center120registers the user. This process can include additional interactions (not shown) with the user to create a new account or to update credentials for an existing user. At step152, using SDK/API116and any third-party APIs or modules118, user102creates the custom logic that will be executed by authentication center120during subsequent login attempts. Exemplary logic can be any logic compatible with SDK/API116as defined by the operator of authentication center120. In some embodiments, this logic is compiled into bytecode by the user using client device110, while in other embodiments the logic is prepared as a script, such as JavaScript, and presented to authentication center120for compiling at the server, allowing the authentication center120to ensure the bytecode is secure and does not contain malicious code. At step154, user102sends the custom implementation logic in an appropriate form to authentication center120to register the logic to the user for later login.

At step156, after receiving the implementation logic from user102, authentication center120inspects, compiles (if needed), and otherwise prepares the implementation logic to be stored as encrypted bytecode in the PBE memory space assigned to that user. Authentication center120then encrypts and stores the bytecode using the user's password and username by any suitable encryption means. In some embodiments, as part of that inspection and storage process, authentication center120can register with third party services132to ensure that the system will be prepared to execute the implementation logic when the user attempts to login. At optional step158, authentication center120executes a portion of the logic that dictates how to register authentication center120with third party services132. This logic can be supplied by user102based on the information downloaded in step142. This allows authentication system120to be viewed as a trusted party by third-party services132, allowing authentication system120to be granted read access to certain (in some embodiments, limited) information for purposes of subsequently executing the user's custom implementation logic to verify the user's credentials using information from the third-party service.

FIG. 5is a flow chart of an exemplary authentication process160for use with some embodiments. This authentication process does not specifically include interaction with third party services132, but can easily be adapted to do so, as illustrated inFIG. 6. At step162, user102requests access to a resource secured by the authentication system. The resource could be any network-based service or resource, such as access to a corporate database, network, application, or system. The authentication system could be a single sign-on system that grants credentials to a user for accessing multiple other services. This request can be through a website, an API, or a script presented by the authentication system via the service the user seeks access to. At step164, the user presents her identity, such as a username or email address, to authentication center120.FIG. 5illustrates the interaction with PBE storage126, which contains bytecode for each user's custom implementation logic. At step166, authentication center120uses the username to request the user-specific bytecode from PBE storage126. In some embodiments, this step includes presenting the user's password such that the decryption is performed by PBE storage device126itself (e.g., the decryption portion of step174is performed by PBE storage126). In some embodiments, as part of step166, authentication center120presents its own credentials to verify that the center itself is authorized to decrypt and access secured data. At step168, PBE storage126returns the bytecode for the user (in encrypted form in this example). At step170, authentication center120solicits the password from user102, which will be used to decrypted the encrypted bytecode received from PBE storage126. The user provides this password at step172.

At step174, authentication center120uses the password from the user to decrypt the bytecode for the user. The authentication center then executes the bytecode, allowing the user-defined logic to determine the specific steps that should be used for the next phase of authentication. In some embodiments, such as shown inFIG. 6, this step can include accessing other information sources (such as an SAP database) to retrieve the information used to verify the credentials solicited and received from the user in subsequent steps. At step176, as defined by the user's custom implementation logic, authentication system120requests credentials or an action from user102. For example, the logic may instruct the user to retrieve certain information in response to a challenge question or ask the user for an additional changing password defined by the logic.

At step178, user102performs any tasks necessary to respond to the request, such as accessing third party resources (FIG. 6), performing calculations using information that only an authentic user would know, or by providing answers to user-defined challenge questions, created such that only the user would know the answer. These challenge questions are limited primarily by the user's creativity when defining the implementation logic. Once the user performs any needed tasks to formulate a response to the request, at step180, the user provides the responsive credentials, such as an answer to the challenge question or a file created or obtained in response to the request in step176.

At step182, authentication center120executes the implementation logic/bytecode to determine if the user response is authentic. This can include any suitable logic, as chosen by the user, such as a direct comparison or (where security needs to be higher) by comparing a hash of the user response to a stored value that is a hash of the correct response, making it difficult to determine a proper user response even if the bytecode is compromised. At step184, if the user response is satisfactory per the user's custom logic, authentication center120grants the user access. This can be done in any suitable manner, such as providing a token for the user to use at other online portals, sending a message to the online resources to grant access, etc.

FIG. 6shows another embodiment of a method200for authenticating a user120that utilizes any of third-party services132to provide authentication information for use in the implementation logic. Generally, this process operates similarly to the process inFIG. 5, but the details of the interaction with PBE storage126are not shown.

At step202, user102requests access to a resource secured by the authentication system, similar to step162. At step204, the user presents her identity, such as a username of email address, to authentication center120. At step206, authentication center120solicits the password from user102, which will be used to decrypt the encrypted bytecode in PBE storage126. At step208, authentication center120receives the password from user102.

At step210, authentication center120accesses the encrypted bytecode for the user from the PBE storage and uses the password from the user to decrypt the bytecode. The authentication center then executes the bytecode, allowing the user-defined logic to determine the specific steps that should be used for the next phase of authentication. In this embodiment, this step includes accessing other information sources (such as an SAP database), as defined in exemplary the user-provided logic. Third party services can provide a variety of information to verify credentials provided by the user during the second stage of authentication. At step212, as defined by the user's custom implementation logic, authentication system120requests credentials or an action by user102. For example, the logic may instruct the user to retrieve certain information from a CRM or SAP database in response to a challenge question.

At step214, authentication center120requests information (defined in the implementation logic) from third party service132to be used to verify the user's identity. At step216, third party services132provide the responsive information. At step218, user102requests related information from third-party services132in response to the request she received at step212. This can be matching information to that sent in step216or related information that can be checked by the response in step216. At step220, if the user is authorized to access the information requested, third party services132provide responsive information.

At step222, user102performs any tasks necessary to respond to the request, such as performing calculations using information from the third party, manipulating that information in a manner that only the user knows, or by providing answers to user-defined challenge questions created such that only the user would know the answer. The steps performed by the user at this step are limited primarily by the user's imagination at the time of defining the implementation logic. Once the user performs any needed tasks to formulate a response to the request, at step224, the user provides the responsive credentials.

At step226, authentication center120executes the implementation logic/bytecode to determine if the user response is authentic, per the logic defined by the user. This can include any suitable logic chosen by the user at registration, as explained with respect to step182inFIG. 5. At step228, if the user response is satisfactory per the user's custom logic, authentication center120grants the user access.

Because embodiments of an authentication system use user-defined implementation logic to perform custom second-phase authentication of a user, examples of the authentication process can be virtually limitless. While a user could choose to implement logic that includes a second phase similar to that of current two-factor authentication systems, the underlying system differs due to the use of custom PBE-stored logic for each user. Thus, on a single authentication system many different authentication processes will exist for the various users. The following are a few simple illustrative examples of logic that a user can choose to implement.

Example 1: Each day of the week, the user has a different secondary password and after providing username and password, the user will be prompted for “today's secret word.” For additional security, the bytecode can include a hash function and a table of expected outcomes so that the secret words of the day are not stored. Similarly, the hash or the secret word used by the user can be stored in a third-party database and the user can retrieve the word from a third party source.

Example 2: A challenge question is tied to information in an SAP database. A user in an accounting department can be asked customized questions, like “how many invoices were submitted yesterday?” Similarly, financial account information could be used (“when was your last deposit?”) or a CRM database (“what is the zip code of client ABC?”). Logic for evaluating the user's response can even be more complex, such as “what is the sum of open invoices and invoices closed today?”

Example 3: A challenge question could relate to social media or public information, such as “what was the time of your latest tweet on Twitter?” or “how many likes does the company page currently have on Facebook?” Note that in many of these examples the logic can include any combination of available challenge questions and the logic randomly selects one to ensure that different authentication sessions will have different second-stage challenge responses. This can mitigate problems caused by unsecured connections where user responses are intercepted.

Example 4: The server uses a changing portion of information about user credentials, allowing a user to use more conventional credentials in the second phase. For example, “what are the last three digits of your phone number,” “What is the sum of the last three digits of your zip code?” “What is the last digit of your phone number multiplied by the first digit of your social security number?”