US20180097806A1 - Multi factor user authentication on multiple devices - Google Patents
Multi factor user authentication on multiple devices Download PDFInfo
- Publication number
- US20180097806A1 US20180097806A1 US15/833,426 US201715833426A US2018097806A1 US 20180097806 A1 US20180097806 A1 US 20180097806A1 US 201715833426 A US201715833426 A US 201715833426A US 2018097806 A1 US2018097806 A1 US 2018097806A1
- Authority
- US
- United States
- Prior art keywords
- authentication
- user
- computing device
- client computing
- authentication credential
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
- H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
Definitions
- the present invention generally relates to the field of user authentication and specifically to the field of a multi-factor authentication via multiple client devices.
- the present invention provides systems and methods comprising: a first client computer communicatively coupled to a network and configured to receive and transmit an authentication credential selected from a plurality of authentication credentials comprising: a first authentication credential known only to a user; a second authentication credential identifying a client computer; and a third authentication credential identifying a characteristic unique to the user.
- the present invention may further comprise a second client computer communicatively coupled to the network and configured to receive and transmit at least one additional authentication credential selected from the plurality of authentication credentials.
- the present invention may also comprise a server computer communicatively coupled to the network and configured to: receive, from the first client computer, the authentication credential; receive, from the second client computer, the at least one additional authentication credential; and verify the identity of the user via a match, within a database communicatively coupled to the network, to the first authentication credential, the second authentication credential and the third authentication credential.
- a server computer communicatively coupled to the network and configured to: receive, from the first client computer, the authentication credential; receive, from the second client computer, the at least one additional authentication credential; and verify the identity of the user via a match, within a database communicatively coupled to the network, to the first authentication credential, the second authentication credential and the third authentication credential.
- FIG. 1 illustrates a possible system for authenticating a user via multi-factor authentication on multiple devices.
- FIG. 2 illustrates a more detailed possible system for authenticating a user via multi-factor authentication on multiple devices.
- FIG. 3 is a flow diagram illustrating a possible embodiment of a method for authenticating a user via multi-factor authentication on multiple devices.
- a network is a collection of links and nodes (e.g., multiple computers and/or other devices connected together) arranged so that information may be passed from one part of the network to another over multiple links and through various nodes.
- networks include the Internet, the public switched telephone network, the global Telex network, computer networks (e.g., an intranet, an extranet, a local-area network, or a wide-area network), wired networks, and wireless networks.
- the Internet is a worldwide network of computers and computer networks arranged to allow the easy and robust exchange of information between computer users.
- ISPs Internet Service Providers
- Content providers place multimedia information (e.g., text, graphics, audio, video, animation, and other forms of data) at specific locations on the Internet referred to as websites.
- the combination of all the websites and their corresponding web pages on the Internet is generally known as the World Wide Web (WWW) or simply the Web.
- WWW World Wide Web
- Websites Prevalent on the Web are multimedia websites, some of which may offer and sell goods and services to individuals and organizations.
- Websites may consist of a single web page, but typically consist of multiple interconnected and related web pages.
- Websites unless extremely large and complex or have unusual traffic demands, typically reside on a single server and are prepared and maintained by a single individual or entity.
- Website browsers are able to locate specific websites because each website, resource, and computer on the Internet has a unique Internet Protocol (IP) address.
- IP Internet Protocol
- IP addresses are difficult for people to remember and use.
- a Uniform Resource Locator (URL) is much easier to remember and may be used to point to any computer, directory, or file on the Internet.
- a browser is able to access a website on the Internet through the use of a URL.
- the URL may include a Hypertext Transfer Protocol (HTTP) request combined with the website's Internet address, also known as the website's domain name.
- HTTP Hypertext Transfer Protocol
- Two-factor authentication where two types of authentication are entered into a single interface on a single client machine in order to verify the identity of a user.
- the two types of authentication required to verify the user's identify may include something the user knows, as well as something the user has.
- a user may log into a website and be prompted for a user name and password.
- a message in Short Message Service (SMS) format such as a verification code
- SMS Short Message Service
- the user after receiving this message, may then be prompted to enter the verification code into the original website via the original client machine to confirm what the user knows (the user name and password) combined with what the user has (the cell phone).
- Applicant has identified multiple weaknesses in such presently existing systems and methods, which do not effectively authenticate the user and may leave the user vulnerable to hackers or other unscrupulous individuals as described above.
- two-factor authentication systems entered into a single website on a single client machine, there is no protection against some types of cyber attacks.
- These types of attacks may include, as non-limiting examples, a key sniffer attack or a man in the middle attack, where an unscrupulous individual operates a website between the user and a valid website host.
- This unknown interim website may be configured to intercept the input login information (e.g., user name/password), then may relay that information to the valid website host, effectively spoofing the login process by logging the user in as a legitimate website hosted by the website hosting provider.
- spoofing may refer to creating a web page, email or other interface which makes the user and/or web host believe that the login page interface is, in fact, from the original and legitimate source.
- This login page interface may then be presented to the user, and the user, trusting what appears to be the original and legitimate login page, may enter their login credentials (i.e., user name and password).
- This critical user information may then be forwarded to the interim website as described above.
- Another weakness with current two-factor authentication systems and methods is that, as noted above, they rely on only two factors: something the user knows (e.g., user name/password) and something the user has (e.g., a cell phone, where the user gets an SMS message). Additional weaknesses with current two-factor authentication approaches include both the first and second authentication being entered into the same source, such as a single website interface and/or the same machine.
- a user may enter, via their client machine, their user name and password on a login page of a website. This information may be sent to a server operated by the hosting provider of the website. This server may then generate a second authentication code for the user and send it via SMS to the user's phone, as described above, while concurrently or subsequently generating a second web page from the website for the second authentication code, which may be transmitted and displayed on the user's original client machine. The user may then enter the second authentication code from their phone into this second web page (or in some cases, the original web page) and transmit it from the same machine for authentication.
- the two authentication factors are both entered into and sent from the same machine to the same authority (i.e., the first factor and second factor are both entered into and sent on the same device)
- a successful phishing attack would allow the man in the middle to access both authentication factors simultaneously, since the user would send the information to the same source through the same channel via the same device.
- both the user name/password entry and the SMS entry would be more easily accessible, to the man in the middle and therefore easier to intercept.
- the current state of the art for two-factor authentication therefore, protects the user against hackers compromising some credentials, but does not protect the user against someone spoofing the infrastructure of the web hosting provider.
- the hosting provider has no way of ensuring that the factors have, in fact, originated from the actual user.
- a man in the middle or other dishonest individual could steal a password or a PIN to get access to one or more means of authenticating the individual, and could impersonate them without alerting the hosting provider that the information is not coming from a valid user.
- Applicant has therefore determined that optimal systems and methods will provide for entry of a second or subsequent authentication credential into a second or subsequent device through a second or subsequent channel.
- a thumb print or other biometric may be used to authenticate a user.
- the biometric such as a thumb print signature
- the biometric is static. This means that once an unscrupulous individual gains access to the biometric, they could store and replay it for their own purposes.
- Applicant has therefore further determined that, in addition to two factors entered into two separate client devices, optimal systems and methods will incorporate at least three and possibly multiple additional authentication factors, possibly including a thumb print or other biometric, thereby introducing three or more factor authentication comprising any combinations of something the user knows (e.g., password), something the user has (e.g., a mobile phone) and something the user is (e.g., a thumb print).
- the additional verification of a biometric within such systems or methods confirms that the user is in control of the scanned biometric (e.g., by combining the biometric with a password or other credential), or that the user is not a hacker who has simply obtained a copy of the scanned biometric and is replaying it to gain access to sensitive information (e.g., by requiring verification that the thumb print actually came from the user's phone).
- the hosting provider may also benefit from such optimal systems and methods, since there is a greater assurance that the information is coming from a valid user.
- FIG. 1 demonstrates a streamlined example
- FIG. 2 demonstrates a more detailed example of an environment including a system and/or structure that may be used to accomplish the methods and embodiments disclosed and described herein.
- Such methods may be performed by any central processing unit (CPU) in any computing system, such as a microprocessor running on at least one server 110 and/or client 120 , and executing instructions stored (perhaps as scripts and/or software, possibly as software modules/components) in computer-readable media accessible to the CPU, such as a hard disk drive on a server 110 and/or client 120 .
- CPU central processing unit
- Such a network 100 may comprise, as non-limiting examples, any combination of the Internet, the public switched telephone network, the global Telex network, computer networks (e.g., an intranet, an extranet, a local-area network, or a wide-area network), a wired network, a wireless network, a telephone network, a corporate network backbone or any other combination of known or later developed networks.
- At least one server 110 and at least one client 120 may be communicatively coupled to the network 100 via any method of network connection known in the art or developed in the future including, but not limited to wired, wireless, modem, dial-up, satellite, cable modem, Digital Subscriber Line (DSL), Asymmetric Digital Subscribers Line (ASDL), Virtual Private Network (VPN), Integrated Services Digital Network (ISDN), X.25, Ethernet, token ring, Fiber Distributed Data Interface (FDDI), IP over Asynchronous Transfer Mode (ATM), Infrared Data Association (IrDA), wireless, WAN technologies (T1, Frame Relay), Point-to-Point Protocol over Ethernet (PPPoE), and/or any combination thereof.
- any method of network connection including, but not limited to wired, wireless, modem, dial-up, satellite, cable modem, Digital Subscriber Line (DSL), Asymmetric Digital Subscribers Line (ASDL), Virtual Private Network (VPN), Integrated Services Digital Network (ISDN), X.25, Ethernet, token ring, Fiber Distributed Data Interface (
- users may comprise any individual, entity, business, corporation, partnership, organization, governmental entity, and/or educational institution that may have occasion to organize/import contacts and/or send marketing campaigns.
- Server(s) 110 may comprise any computer or program that provides services to other computers, programs, or users either in the same computer or over a computer network 100 .
- the server 110 may comprise application, communication, mail, database, proxy, fax, file, media, web, peer-to-peer, standalone, software, or hardware servers (i.e., server computers) and may use any server format known in the art or developed in the future (possibly a shared hosting server, a virtual dedicated hosting server, a dedicated hosting server, a cloud hosting solution, a grid hosting solution, or any combination thereof) and may be used, for example to provide access to the data needed for the software combination requested by a client 120 .
- the server 110 may exist within a server cluster, as illustrated. These clusters may include a group of tightly coupled computers that work together so that in many respects they can be viewed as though they are a single computer. The components may be connected to each other through fast local area networks which may improve performance and/or availability over that provided by a single computer.
- the client 120 may be any computer or program that provides services to other computers, programs, or users either in the same computer or over a computer network 100 .
- the client 120 may be an application, communication, mail, database, proxy, fax, file, media, web, peer-to-peer, or standalone computer, cell phone, personal digital assistant (PDA), etc. which may contain an operating system, a full file system, a plurality of other necessary utilities or applications or any combination thereof on the client 120 .
- Non limiting example programming environments for client applications may include JavaScript/AJAX (client side automation), ASP, JSP, Ruby on Rails, Python's Django, PHP, HTML pages or rich media like Flash, Flex or Silverlight.
- the client(s) 120 that may be used to connect to the network 100 to accomplish the illustrated embodiments may include, but are not limited to, a desktop computer, a laptop computer, a hand held computer, a terminal, a television, a television set top box, a cellular phone, a wireless phone, a wireless hand held device, an Internet access device, a rich client, thin client, or any other client functional with a client/server computing architecture.
- Client software may be used for authenticated remote access to a hosting computer or server. These may be, but are not limited to being accessed by a remote desktop program and/or a web browser, as are known in the art.
- the user interface displayed on the client(s) 120 or the server(s) 110 may be any graphical, textual, scanned and/or auditory information a computer program presents to the user, and the control sequences such as keystrokes, movements of the computer mouse, selections with a touch screen, scanned information etc. used to control the program.
- Examples of such interfaces include any known or later developed combination of Graphical User Interfaces (GUI) or Web-based user interfaces as seen in the accompanying drawings, Touch interfaces, Conversational Interface Agents, Live User Interfaces (LUI), Command line interfaces, Non-command user interfaces, Object-oriented User Interfaces (OOUI) or Voice user interfaces.
- the commands received within the software combination, or any other information may be accepted using any field, widget and/or control used in such interfaces, including but not limited to a text-box, text field, button, hyper-link, list, drop-down list, check-box, radio button, data grid, icon, graphical image, embedded link, etc.
- the server 110 may be communicatively coupled to data storage 130 including any information requested or required by the system and/or described herein.
- the data storage 130 may be any computer components, devices, and/or recording media that may retain digital data used for computing for some interval of time.
- the storage may be capable of retaining stored content for any data required, on a single machine or in a cluster of computers over the network 100 , in separate memory areas of the same machine such as different hard drives, or in separate partitions within the same hard drive, such as a database partition.
- Non-limiting examples of the data storage 130 may include, but are not limited to, a Network Area Storage, (“NAS”), which may be a self-contained file level computer data storage connected to and supplying a computer network with file-based data storage services.
- the storage subsystem may also be a Storage Area Network (“SAN”—an architecture to attach remote computer storage devices to servers in such a way that the devices appear as locally attached), an NAS-SAN hybrid, any other means of central/shared storage now known or later developed or any combination thereof.
- SAN Storage Area Network
- the data storage 130 may comprise any collection of data.
- the data storage 130 may comprise a local database, online database, desktop database, server-side database, relational database, hierarchical database, network database, object database, object-relational database, associative database, concept-oriented database, entity-attribute-value database, multi-dimensional database, semi-structured database, star schema database, XML database, file, collection of files, spreadsheet, and/or other means of data storage such as a magnetic media, hard drive, other disk drive, volatile memory (e.g., RAM), non-volatile memory (e.g., ROM or flash), and/or any combination thereof.
- volatile memory e.g., RAM
- non-volatile memory e.g., ROM or flash
- the server(s) 110 or software modules within the server(s) 110 may use query languages such as MSSQL or MySQL to retrieve the content from the data storage 130 .
- Server-side scripting languages such as ASP, PHP, CGI/Perl, proprietary scripting software/modules/components etc. may be used to process the retrieved data.
- the retrieved data may be analyzed in order to determine the actions to be taken by the scripting language, including executing any method steps disclosed herein.
- the software modules/components of the software combination used in the context of the current invention may be stored in the memory of—and run on—at least one server 110 .
- the paragraphs below describe in detail the software modules/components that make up the software combination.
- These software modules/components may comprise software and/or scripts containing instructions that, when executed by a microprocessor on a server 110 or client 120 , cause the microprocessor to accomplish the purpose of the module/component as described in detail herein.
- the software combination may also share information, including data from data sources and/or variables used in various algorithms executed on the servers 110 and/or clients 120 within the system, between each module/component of the software combination as needed.
- a data center 140 may provide hosting services for the software combination, or any related hosted website including, but not limited to hosting one or more computers or servers in a data center 140 as well as providing the general infrastructure necessary to offer hosting services to Internet users including hardware, software, Internet web sites, hosting servers, and electronic communication means necessary to connect multiple computers and/or servers to the Internet or any other network 100 .
- FIG. 2 shows a more detailed example embodiment of an environment for the systems, and for accomplishing the method steps, disclosed herein.
- all disclosed software modules 200 may run on one or more server(s) 110 and may include one or more user interfaces generated by the server(s) 110 and transmitted to and displayed on the client(s) 120 .
- the user interface(s) may be configured to receive input from the user and transmit this input to the server(s) 110 for the administration and execution of the software 200 , using data in data storage 130 associated with the software modules 200 .
- the disclosed system may be configured to execute any or all of the method steps disclosed herein.
- Server(s) 110 may be hosted by any entity, possibly a hosting provider, a domain name registrar, a website development company, any other software service provider or any combination thereof.
- client(s) 120 mobile devices may run a user administration program 210 such as GoDaddy's My Account control panel for management of hosting websites and managing domain names, as a non-limiting example.
- each user may be assigned a user id.
- This user id may identify transactions performed by each user, or other data, such as authentication information disclosed herein.
- These transactions, user account data 220 , authentication data and/or other data may be stored as data records in data storage 130 , each data record including the user id to associate the user with the relevant user or other data in data storage 130 .
- the admin 210 may include or be associated with a Domain Control Center (DCC) for administration of domain names registered to the user.
- DCC Domain Control Center
- the DCC may include means for listing and managing all domain names registered to the registrant, possibly including auto renewal of the domains, DNS record settings, etc.
- the DCC may be used to display the disclosed notices, reports and/or domain name purchase offers, as described in more detail herein.
- the disclosed multi authentication methods and system described herein may be applied to authentication of users to any application requiring user authentication including, but not limited to, a bank account, a shopping site, private health records, the admin described above and/or the DCC or other applications.
- the use of multi authentication input via multiple client devices 120 may provide additional security to the user's personal accounts and/or the domain names registered and managed by users associated with the user account via the DCC.
- the security features available may be used in any context providing users repeated access to destructive or semi-destructive actions available via multi factor authentication.
- this multi factor authentication may be applied at any point in the domain name registration or administration process.
- the multi authentication techniques described herein may provide better security as the user: registers a domain name; transfers a domain name; locks a domain name; lists a domain name for sale; cancels a domain name; changes name servers for a domain name; changes the DNS settings for a domain name; etc.
- Any of the multi factor authentication means, factors, requests, challenges and/or credentials described below may be used to provide greater security for these user account.
- Multi factor authentication may comprise multiple types of authentication.
- a user may request that server(s) 110 perform a particular action, such as accessing and/or updating secure information, such as the bank account data, shopping session data, medical records, domain name data or other domain name or user data previously mentioned.
- server(s) 110 may require one or more authentication factors to verify the user's identity before proceeding.
- These authentication factors may comprise authentication challenges (i.e., a request for user information to verify their identify) and/or authentication credentials (i.e., the response from the user verifying their identity).
- Authentication factors, challenges and/or credentials may fall into three general categories, possibly including, but not limited to 1) something the user knows; 2) something the user possesses; and 3) something that the user is.
- the disclosed invention comprises means for verifying a user via multi-factor authentication, and may include any combination of authentication means, factors, requests, challenges and/or credentials now known or developed in the future, including any combination of the non-limiting example embodiments disclosed herein.
- authentication factors may include, but are not limited to: any combination of user names and passwords; software generated codes or passwords; Time-based One Time Passwords (TOTP); shared secrets; private/public key pairs (and related hashing or cryptographic algorithms); unique data associated with the user of the disclosed system (e.g., biometrics specific to a user); authentication via facial recognition; authentication via voice authentication; and/or authentication via tap codes.
- TOTP Time-based One Time Passwords
- shared secrets e.g., shared secrets
- private/public key pairs and related hashing or cryptographic algorithms
- unique data associated with the user of the disclosed system e.g., biometrics specific to a user
- authentication via facial recognition e.g., facial recognition
- authentication via voice authentication e.g., voice authentication
- tap codes e.g., tap codes.
- a user interface may comprise an authentication challenge requesting the user name, password and/or shared secret.
- a shared secret may comprise data, known only to the parties involved, in a secure communication.
- a shared secret may comprise a password, a passphrase, a big number or an array of randomly chosen bytes.
- the user may provide the response to the authentication challenge (something the user knows) to confirm and authenticate their identity.
- server(s) 110 may then authenticate the user and proceed with the action requiring the authentication, possibly by confirming a match for the user name, password and/or shared secret via user or other records stored in the user account data 220 in data storage 130 . If not authenticated, an alert may be transmitted and displayed to the user.
- an authentication factor comprises a code generated by software running on server(s) 110 and/or client(s) 120
- a user interface may comprise an authentication challenge requesting the previously disclosed shared secret and/or any other algorithm that computes a one-time password from a key and the current time (e.g., CAPTCHA).
- the user may provide the response (something the user knows) to confirm their identity.
- server(s) 110 may then authenticate the user and proceed with the action requiring the authentication, possibly by confirming a match for the generated code. If not authenticated, an alert may be transmitted and displayed to the user.
- an authentication factor comprises a private/public key pair
- software on server(s) 110 and/or client(s) 120 may generate private/public key pairs comprising two separate and different keys that are mathematically linked. These keys may behave according to any private/public key algorithms known in the art.
- the public key may encrypt a message and/or verify a digital signature and the private (secret) key may decrypt the message and/or create a digital signature.
- one or both of these keys may be generated on, and sent from, a first device (e.g., client 120 —something the user has) to a second device (e.g., sever 110 ) to verify authentication by: processing a message with a private key to produce a digital signature; processing the digital signature value with the public key; and comparing that result with the message.
- a first device e.g., client 120 —something the user has
- a second device e.g., sever 110
- an authentication factor comprises a unique data associated with the user (something the user is)
- a non-limiting example of this unique data may comprise biometric data associated with the user.
- biometric data may comprise any biometric data collected about the user, and may be gathered from, as non-limiting examples, a thumbprint scanner, a capillary distribution scanner, a retinal scanner, a DNA scanner, an implanted microchip, and/or any other means of gathering biometric data identifying a specific individual now known or discovered in the future.
- this biometric data may be acquired and sent from a first device (e.g., client 120 , something the user has) to a second device (e.g., sever 110 ).
- server(s) 110 may then authenticate the user and proceed with the action requiring the authentication, possibly by confirming a match for the biometric data via user or other records stored in data storage 130 . If not authenticated, an alert may be transmitted and displayed to the user.
- an authentication factor comprises facial recognition technology
- software running on users' client(s) 120 may work in conjunction with on-board or attached cameras to verify user identity using any facial recognition techniques, methods or systems known in the art.
- an authentication factor comprises voice recognition technology
- software running on users' client(s) 120 may work in conjunction with on-board or attached microphones to verify user identity using any voice recognition techniques, methods or systems known in the art.
- an authentication factor comprises tap code technology
- software running on users' client(s) 120 may be configured to work in conjunction with sensors on the client(s) 120 to receive a series of Morse-code or other style tapped input to verify user identity using any tap code techniques, methods or systems known in the art.
- server(s) 110 may generate and/or access a first authentication request and/or challenge, possibly to be displayed on a user interface.
- a challenge may comprise an interface displayed on a web page, and configured to receive a user name/password combination from a user.
- Server(s) 110 may then transmit this first authentication challenge to one or more client(s) 120 .
- Client(s) 120 may then display the first authentication challenge on the user interface.
- a user may enter, as non-limiting examples, the user name and/or password into the user interface.
- Client(s) 120 may then transmit the first authentication credential, entered by the user, to server(s) 110 .
- One or more software module(s) 200 running on server(s) 110 may then be configured to receive the first authentication credential entered and submitted by the user, and use the entered credential(s) to authenticate the user, possibly by comparing the entered credential against username, password, temporary password, public/private key and/or biometric data stored as user account data 220 on server(s) 110 and/or in data storage 130 . If the first credential is not authenticated, an alert may be generated, transmitted and displayed on client(s) 120 to the user.
- the server may generate and/or access a second authentication challenge, to be displayed, possibly on the user interface.
- the second authentication challenge may comprise a message/digital signature generated, encrypted and/or decrypted using a private/public key pair and/or a biometric scan.
- Server(s) 110 may then transmit this second authentication challenge to client(s) 120 , possibly to a client 120 different than the client on which the first authentication credential was authenticated.
- the user may submit and/or transmit, to server(s) 110 , a second authentication credential to authenticate the user.
- this second authentication credential may comprise the private/public key pair message and/or the user's biometric.
- the biometric may be signed by the private key on client(s) 120 and sent to server(s) 110 to verify it was collected on a valid device.
- One or more software module(s) 200 on server(s) 110 may be configured to receive the second authentication credential submitted by the client(s) 120 and authenticate the user via the second authentication credential, possibly by comparing the data against a user name, password, temporary password, public/private key and/or biometric data stored as user account data 220 on server(s) 110 and/or in data storage 130 , as disclosed above. If the second credential is not authenticated, an alert may be generated, transmitted and displayed to the user on client(s) 120 . If the second factor is authenticated, the server may proceed with the process for which authentication was required.
- This multi-factor authentication is not limited to two or three factors, and the verification process above may be repeated for each additional factor until all authentication challenges and credentials have been verified and authenticated.
- authentication of a user may be augmented by requiring that a second, third or nth authentication credential be entered or verified via a second, third or nth channel and/or a second, third or nth device.
- a user may not be authenticated until software, possibly running on server(s) 110 , verifies that the authentication for a subsequent authentication credential is received from a different channel than the channel used to submit and/or transmit the initial or previous authentication credential(s).
- Non-limiting examples of such channels may include user interfaces displayed via URLs, websites, web pages, software or other apps running on client(s) 120 , etc., which are different from the initial or previous URLs, website(s), web page(s), software or other app(s), possibly running on and/or received via a different device than the initial or previous device.
- the software may be configured to determine if the second/nth authentication credential is also received via same channel (e.g., the web page, website, URL, browser and/or operating system), possibly via the same client 120 . If so, the user may not be authenticated and the software may require the user to enter one or more subsequent authentication credentials via one or more different channels (web page, website, URL, browser and/or operating system) than the first or previous channel used to enter the initial or previous authentication credential.
- same channel e.g., the web page, website, URL, browser and/or operating system
- a user may not be authenticated until software, possibly running on server(s) 110 , verifies that authentication for a subsequent authentication was received from one or more different devices than the device used to submit and/or transmit the initial or previous authentication credential(s).
- Non-limiting examples of such devices may include any client 120 and/or server 110 device disclosed herein.
- the software may be configured to determine if the second/nth authentication credential is also received via the same device. If so, the user may not be authenticated and may be required to enter one or more subsequent authentication credentials via a different device than that used to enter the initial or previous authentication credential.
- the second or nth device may be authenticated via an exclusive channel available between the client(s) 120 and server(s) 110 via a private/public key pair specifically identifying the client(s) 120 and authenticating the authentication credential via the exclusive channel. Details of such private/public key pairs and exclusive channels are disclosed below.
- the requirements for different channels and/or devices may be combined, so that a first authentication credential may be entered via a first channel into a first device and a second authentication credential may be required to be entered via a second channel into a second device. If additional authentication credentials are involved, the nth security credential may be required to be entered via the nth channel into an nth device, and so on.
- the second and/or nth device may also act as another form of authentication, specifically something the user has.
- an authentication message, authentication code and/or any other authentication challenge may be sent to a first client 120 device, while a second message, code and/or challenge is transmitted to a second client 120 device.
- this message may indicate that the user has attempted to log in on the first or previous device, and is now seeking a second or nth authentication of the user's identity, and may display an alert that action is required on the part of the user to authenticate the user and continue the login.
- the user's response to the second authentication challenge via the second client device may act as further verification of the user's identity by providing something the user knows combined with something the user has.
- the software running on server(s) 110 and/or client(s) 120 may verify the user without additional interaction with the user.
- the authentication message, code and/or challenge transmitted to the user may be communicated by any means known in the art.
- the message, code and/or challenge may be communicated via: a web page; an email; an SMS/text message; software running on a client computer 120 ; an app running on a mobile device; a phone call, a voice message on a phone; etc.
- Communication means such as SMS/text, phone messages, etc. may provide broader means to send the message, code and/or challenge, since the message, code and or challenge would not rely on proprietary hardware and/or software to transmit to the user.
- Server(s) 110 may generate, and transmit an authentication message, code and/or challenge to the user's client 120 , such as a user's laptop computer, as described above.
- the user's client 120 may issue an alert to the user, such as an audio chime indicating receipt of a new message, or a visual alert such as an alert window displayed on a screen, as non-limiting examples.
- a second message, code and/or challenge may be simultaneously or subsequently sent to a user's second client 120 , such as the user's mobile device.
- the mobile device may be configured to display the message, code and/or challenge, and the user may input the message, code and/or challenge into a user interface on software running on the mobile device.
- requesting a second authentication credential on the second device server(s) 110 may be configured to generate and transmit additional information with the challenge indicating the action the user intends to perform with the authentication.
- this action may include authorizing a payment or making an online purchase.
- the message may display an additional message requesting the user to confirm the action the user intends to confirm.
- server(s) 110 may generate and transmit the first message, code and/or challenge, possibly including the alert, to the user's mobile device while simultaneously or subsequently sending the second message, code and/or challenge to the user's desktop or laptop computer.
- any client 120 disclosed herein may act as either the first or second device to which the message, code and/or challenge is communicated, but the response and/or authentication credentials may be required to be entered into separate client devices 120 .
- a code may be displayed on a first client 120 , but then required to be entered via a channel on a second client 120 .
- a code may be displayed on a PC screen with instructions to go to a phone and type the code, then click a button on the phone to encrypt and transmit the code, or conversely, communicate a code to the phone that the user must input (and/or encrypt) on a PC, etc.
- a user may install software on the client(s) 120 , to receive the authentication message, code and/or challenge.
- the software may be, as non-limiting examples, a software application on a desktop or laptop and/or an app on a mobile device.
- the software may be further configured to establish an exclusive channel between the client(s) 120 and server(s) 110 , as described below.
- the software may be automatically configured upon installation, to identify the client(s) 120 as something the user owns in order to authenticate the user's identity. Alternatively, a user may configure the software during installation to accomplish the same purpose.
- the software may include means for the user to log in to a user account, possibly by providing a username and password.
- the software may be configured to receive the incoming message, code and/or challenge. As noted above, the software may be configured to display an alert on the client(s) 120 when the user receives such a message, code and/or challenge. In embodiments requiring user input, the software may then be configured to receive authentication credentials or other acknowledgements from the user.
- the software itself may display the alert and/or code generated by software on server(s) 110 or client(s) 120 .
- the alert and/or code may comprise TOTP, answer to shared secrets, other generated passwords, etc.
- SMS, text and or phone messages would not be necessary.
- the user may simply need to click a button on a user interface to verify receipt of the alert/login attempt and confirm the authentication.
- installation of the software may cause client(s) 120 to automatically generate a private/public key pair, used for private/public key encryption of messages and/or authentication data transmitted between server(s) 110 and client(s) 120 .
- This private/public key pair may act as one of the trusted authentication credentials (i.e., an initial or secondary authentication credential) used to verify the user's identity.
- the private/public key pair may act as a secondary authentication credential (proof of something the user has) when a user attempts to log in via user name/password as a primary authentication credential (something the user knows).
- the software and/or the client(s) 120 may be configured to generate a unique public/private key pair.
- the client and/or software may then be configured to store the private key and transmit the public key to server(s) 110 to be stored in the cloud.
- the public key may generate a digital signature and the private (secret) key may sign any data transmitted to the server.
- the key in the public key may be installed, published and/or stored the hosting servers 110 in association with the user, the user's client device 120 and/or any other user data. In some embodiments, this association may be accomplished via data records that join data, such as a user id identifying the user, to the published/stored key(s).
- Associating the user and client(s) 120 with software and/or data on the server 110 via the private/public key pair may bind each and all of these together, creating authentication as a primary or secondary authentication credential, since code on the client(s) 120 is bound to code on the server(s) 110 via an exclusive encryption channel between client(s) 120 and server(s) 110 .
- server(s) 110 may generate and transmit an authentication message, code and/or challenge to client(s) 120 , seeking either a primary or secondary authentication.
- the software on the client(s) 120 may receive this message, code and/or challenge and generate and/or receive a response to the message, which may then be signed by the private key and transmitted to server(s) 110 .
- the user may need to enter data to respond to the challenge.
- the software running on the client(s) 120 may display a code or other data, which the user must enter before proceeding. In other embodiments, the code or other data may not be necessary.
- the user may simply click a button on the user interface that either a generated authentication credential is OK, or that the user wants to proceed with the public/private key authentication, where the software client(s) 120 would simply confirm the public/private key encryption channel. Because the code on the client(s) 120 and server(s) 110 are bound together as described above, only this credential would be necessary to proceed.
- the installed software may recognize the incoming challenge and may generate the response including and/or encoded with the necessary digital signature or encryption necessary to authenticate the user and/or the client machine.
- the software on client(s) 120 may use the key to generate/ the digital signature the software may then transmit the digital signature to server(s) 110 via the exclusive channel between client(s) 120 and server(s) 110 for authentication.
- the disclosed system and methods may require a third authentication factor.
- authentication of a user may require three separate authentication factors including 1) something a user knows; 2) something the user has; and 3) something the user is. Any of the previously disclosed authentication factors and/or methods may be used to verify these three separate authentication factors.
- a user may enter a login/password entry or other transaction, possibly on a first device (i.e., entering something the user knows).
- a second transaction may comprise a software running on the user's client 120 machine, configured to alert the user to the first transaction and confirm the transaction, possibly via the private/public key on the client 120 (i.e., using the exclusive connection to confirm something the user has).
- the user may enter data to confirm the transaction, click an OK button displayed on the client(s) 120 to confirm the transaction with the private key on that device and/or allow an installed software to generate a second authentication, possibly including a digital signature, and the response before sending to server(s) 110 .
- the disclosed systems/methods may require the user to enter a biometric (i.e., entering something the user is), and may only generate the signature to confirm the transaction based on the presence of the biometric.
- a biometric i.e., entering something the user is
- the server(s) 110 may be configured to verify the biometric Any of the three types of authentication, including this biometric, may be encrypted and/or digitally signed as disclosed herein prior to transmitting the response to server(s) 110 .
- the user's phone were stolen, and a thief was to already know the user's one username/password authentication, the user's authentication may compromised.
- the thief would be able to confirm any transaction if they have both the phone and the username/password.
- the username/password, device possibly including the private/public key pair
- biometric would be required to spoof the authentication, guaranteeing a more secure authentication.
- FIG. 3 represents a flow diagram for one possible embodiment of the previously described improvements on presently existing systems.
- one or more server computers 110 may be communicatively coupled to the network 100 and may be configured to: receive a first transmission, from a first client computer communicatively coupled to the network, comprising an authentication credential selected from a plurality of authentication credentials comprising: a first authentication credential known only to a user; a second authentication credential identifying a client computer; and a third authentication credential identifying a characteristic unique to the user (Step 300 ); receive a second transmission, from a second client computer communicatively coupled to the network, comprising at least one additional authentication credential selected from the plurality of authentication credentials (Step 310 ); and verify the identity of the user via a match, within a database communicatively coupled to the network, to the first authentication credential, the second authentication credential and the third authentication credential (Step 320 ).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
- Databases & Information Systems (AREA)
- Bioethics (AREA)
Abstract
Description
- This application is a continuation of, and claims priority to, U.S. patent application Ser. No. 15/427,464 entitled “MULTI FACTOR USER AUTHENTICATION ON MULTIPLE DEVICES” and filed on Feb. 8, 2017, which is a continuation of U.S. patent application Ser. No. 14/630,363, filed Feb. 24, 2015, and titled MULTI FACTOR USER AUTHENTICATION ON MULTIPLE DEVICES.
- The present invention generally relates to the field of user authentication and specifically to the field of a multi-factor authentication via multiple client devices.
- The present invention provides systems and methods comprising: a first client computer communicatively coupled to a network and configured to receive and transmit an authentication credential selected from a plurality of authentication credentials comprising: a first authentication credential known only to a user; a second authentication credential identifying a client computer; and a third authentication credential identifying a characteristic unique to the user. The present invention may further comprise a second client computer communicatively coupled to the network and configured to receive and transmit at least one additional authentication credential selected from the plurality of authentication credentials. The present invention may also comprise a server computer communicatively coupled to the network and configured to: receive, from the first client computer, the authentication credential; receive, from the second client computer, the at least one additional authentication credential; and verify the identity of the user via a match, within a database communicatively coupled to the network, to the first authentication credential, the second authentication credential and the third authentication credential.
- The above features and advantages of the present invention will be better understood from the following detailed description taken in conjunction with the accompanying drawings.
-
FIG. 1 illustrates a possible system for authenticating a user via multi-factor authentication on multiple devices. -
FIG. 2 illustrates a more detailed possible system for authenticating a user via multi-factor authentication on multiple devices. -
FIG. 3 is a flow diagram illustrating a possible embodiment of a method for authenticating a user via multi-factor authentication on multiple devices. - The present inventions will now be discussed in detail with regard to the attached drawing figures that were briefly described above. In the following description, numerous specific details are set forth illustrating the Applicant's best mode for practicing the invention and enabling one of ordinary skill in the art to make and use the invention. It will be obvious, however, to one skilled in the art that the present invention may be practiced without many of these specific details. In other instances, well-known machines, structures, and method steps have not been described in particular detail in order to avoid unnecessarily obscuring the present invention. Unless otherwise indicated, like parts and method steps are referred to with like reference numerals.
- A network is a collection of links and nodes (e.g., multiple computers and/or other devices connected together) arranged so that information may be passed from one part of the network to another over multiple links and through various nodes. Examples of networks include the Internet, the public switched telephone network, the global Telex network, computer networks (e.g., an intranet, an extranet, a local-area network, or a wide-area network), wired networks, and wireless networks.
- The Internet is a worldwide network of computers and computer networks arranged to allow the easy and robust exchange of information between computer users. Hundreds of millions of people around the world have access to computers connected to the Internet via Internet Service Providers (ISPs). Content providers place multimedia information (e.g., text, graphics, audio, video, animation, and other forms of data) at specific locations on the Internet referred to as websites. The combination of all the websites and their corresponding web pages on the Internet is generally known as the World Wide Web (WWW) or simply the Web.
- Prevalent on the Web are multimedia websites, some of which may offer and sell goods and services to individuals and organizations. Websites may consist of a single web page, but typically consist of multiple interconnected and related web pages. Websites, unless extremely large and complex or have unusual traffic demands, typically reside on a single server and are prepared and maintained by a single individual or entity. Website browsers are able to locate specific websites because each website, resource, and computer on the Internet has a unique Internet Protocol (IP) address.
- IP addresses, however, even in human readable notation, are difficult for people to remember and use. A Uniform Resource Locator (URL) is much easier to remember and may be used to point to any computer, directory, or file on the Internet. A browser is able to access a website on the Internet through the use of a URL. The URL may include a Hypertext Transfer Protocol (HTTP) request combined with the website's Internet address, also known as the website's domain name.
- Due to the security problems inherent in phishing and other means of cyber attacks, users and administrators are seeking new ways to authenticate users when accessing online data, such as by verifying users' identities and other personal data. One means of protecting this information is via two-factor authentication, where two types of authentication are entered into a single interface on a single client machine in order to verify the identity of a user. As a non-limiting example, the two types of authentication required to verify the user's identify may include something the user knows, as well as something the user has.
- As a non-limiting example of two-factor authentication, a user may log into a website and be prompted for a user name and password. Once the user name and password have been entered and verified, a message in Short Message Service (SMS) format, such as a verification code, may be sent to the user, possibly on a mobile device such as a cell phone. The user, after receiving this message, may then be prompted to enter the verification code into the original website via the original client machine to confirm what the user knows (the user name and password) combined with what the user has (the cell phone).
- Applicant has identified multiple weaknesses in such presently existing systems and methods, which do not effectively authenticate the user and may leave the user vulnerable to hackers or other unscrupulous individuals as described above. As a non-limiting example, in two-factor authentication systems entered into a single website on a single client machine, there is no protection against some types of cyber attacks.
- These types of attacks may include, as non-limiting examples, a key sniffer attack or a man in the middle attack, where an unscrupulous individual operates a website between the user and a valid website host. This unknown interim website may be configured to intercept the input login information (e.g., user name/password), then may relay that information to the valid website host, effectively spoofing the login process by logging the user in as a legitimate website hosted by the website hosting provider.
- In this context, spoofing may refer to creating a web page, email or other interface which makes the user and/or web host believe that the login page interface is, in fact, from the original and legitimate source. This login page interface may then be presented to the user, and the user, trusting what appears to be the original and legitimate login page, may enter their login credentials (i.e., user name and password). This critical user information may then be forwarded to the interim website as described above.
- Another weakness with current two-factor authentication systems and methods is that, as noted above, they rely on only two factors: something the user knows (e.g., user name/password) and something the user has (e.g., a cell phone, where the user gets an SMS message). Additional weaknesses with current two-factor authentication approaches include both the first and second authentication being entered into the same source, such as a single website interface and/or the same machine.
- For example, a user may enter, via their client machine, their user name and password on a login page of a website. This information may be sent to a server operated by the hosting provider of the website. This server may then generate a second authentication code for the user and send it via SMS to the user's phone, as described above, while concurrently or subsequently generating a second web page from the website for the second authentication code, which may be transmitted and displayed on the user's original client machine. The user may then enter the second authentication code from their phone into this second web page (or in some cases, the original web page) and transmit it from the same machine for authentication.
- Because the two authentication factors are both entered into and sent from the same machine to the same authority (i.e., the first factor and second factor are both entered into and sent on the same device), a successful phishing attack would allow the man in the middle to access both authentication factors simultaneously, since the user would send the information to the same source through the same channel via the same device.
- By spoofing the valid website, and intercepting the credentials between the user and the website host (i.e. in front of the website host), both the user name/password entry and the SMS entry would be more easily accessible, to the man in the middle and therefore easier to intercept. The current state of the art for two-factor authentication, therefore, protects the user against hackers compromising some credentials, but does not protect the user against someone spoofing the infrastructure of the web hosting provider.
- Thus, regardless of the means of entering any of the factors disclosed above, the hosting provider has no way of ensuring that the factors have, in fact, originated from the actual user. Conceivably, a man in the middle or other dishonest individual could steal a password or a PIN to get access to one or more means of authenticating the individual, and could impersonate them without alerting the hosting provider that the information is not coming from a valid user. Applicant has therefore determined that optimal systems and methods will provide for entry of a second or subsequent authentication credential into a second or subsequent device through a second or subsequent channel.
- In some two-factor authentication systems and methods, a thumb print or other biometric may be used to authenticate a user. However, a similar problem exists in these methods. The biometric, such as a thumb print signature, is static. This means that once an unscrupulous individual gains access to the biometric, they could store and replay it for their own purposes. Applicant has therefore further determined that, in addition to two factors entered into two separate client devices, optimal systems and methods will incorporate at least three and possibly multiple additional authentication factors, possibly including a thumb print or other biometric, thereby introducing three or more factor authentication comprising any combinations of something the user knows (e.g., password), something the user has (e.g., a mobile phone) and something the user is (e.g., a thumb print).
- The additional verification of a biometric within such systems or methods confirms that the user is in control of the scanned biometric (e.g., by combining the biometric with a password or other credential), or that the user is not a hacker who has simply obtained a copy of the scanned biometric and is replaying it to gain access to sensitive information (e.g., by requiring verification that the thumb print actually came from the user's phone). The hosting provider may also benefit from such optimal systems and methods, since there is a greater assurance that the information is coming from a valid user.
- Several different environments may be used to accomplish the method steps of embodiments disclosed herein.
FIG. 1 demonstrates a streamlined example andFIG. 2 demonstrates a more detailed example of an environment including a system and/or structure that may be used to accomplish the methods and embodiments disclosed and described herein. Such methods may be performed by any central processing unit (CPU) in any computing system, such as a microprocessor running on at least oneserver 110 and/orclient 120, and executing instructions stored (perhaps as scripts and/or software, possibly as software modules/components) in computer-readable media accessible to the CPU, such as a hard disk drive on aserver 110 and/orclient 120. - The example embodiments shown and described herein exist within the framework of a
network 100 and should not limit possible network configuration or connectivity. Such anetwork 100 may comprise, as non-limiting examples, any combination of the Internet, the public switched telephone network, the global Telex network, computer networks (e.g., an intranet, an extranet, a local-area network, or a wide-area network), a wired network, a wireless network, a telephone network, a corporate network backbone or any other combination of known or later developed networks. - At least one
server 110 and at least oneclient 120 may be communicatively coupled to thenetwork 100 via any method of network connection known in the art or developed in the future including, but not limited to wired, wireless, modem, dial-up, satellite, cable modem, Digital Subscriber Line (DSL), Asymmetric Digital Subscribers Line (ASDL), Virtual Private Network (VPN), Integrated Services Digital Network (ISDN), X.25, Ethernet, token ring, Fiber Distributed Data Interface (FDDI), IP over Asynchronous Transfer Mode (ATM), Infrared Data Association (IrDA), wireless, WAN technologies (T1, Frame Relay), Point-to-Point Protocol over Ethernet (PPPoE), and/or any combination thereof. - The example embodiments herein place no limitations on whom or what may comprise users. Thus, as non-limiting examples, users may comprise any individual, entity, business, corporation, partnership, organization, governmental entity, and/or educational institution that may have occasion to organize/import contacts and/or send marketing campaigns.
- Server(s) 110 may comprise any computer or program that provides services to other computers, programs, or users either in the same computer or over a
computer network 100. As non-limiting examples, theserver 110 may comprise application, communication, mail, database, proxy, fax, file, media, web, peer-to-peer, standalone, software, or hardware servers (i.e., server computers) and may use any server format known in the art or developed in the future (possibly a shared hosting server, a virtual dedicated hosting server, a dedicated hosting server, a cloud hosting solution, a grid hosting solution, or any combination thereof) and may be used, for example to provide access to the data needed for the software combination requested by aclient 120. - The
server 110 may exist within a server cluster, as illustrated. These clusters may include a group of tightly coupled computers that work together so that in many respects they can be viewed as though they are a single computer. The components may be connected to each other through fast local area networks which may improve performance and/or availability over that provided by a single computer. - The
client 120 may be any computer or program that provides services to other computers, programs, or users either in the same computer or over acomputer network 100. As non-limiting examples, theclient 120 may be an application, communication, mail, database, proxy, fax, file, media, web, peer-to-peer, or standalone computer, cell phone, personal digital assistant (PDA), etc. which may contain an operating system, a full file system, a plurality of other necessary utilities or applications or any combination thereof on theclient 120. Non limiting example programming environments for client applications may include JavaScript/AJAX (client side automation), ASP, JSP, Ruby on Rails, Python's Django, PHP, HTML pages or rich media like Flash, Flex or Silverlight. - The client(s) 120 that may be used to connect to the
network 100 to accomplish the illustrated embodiments may include, but are not limited to, a desktop computer, a laptop computer, a hand held computer, a terminal, a television, a television set top box, a cellular phone, a wireless phone, a wireless hand held device, an Internet access device, a rich client, thin client, or any other client functional with a client/server computing architecture. Client software may be used for authenticated remote access to a hosting computer or server. These may be, but are not limited to being accessed by a remote desktop program and/or a web browser, as are known in the art. - The user interface displayed on the client(s) 120 or the server(s) 110 may be any graphical, textual, scanned and/or auditory information a computer program presents to the user, and the control sequences such as keystrokes, movements of the computer mouse, selections with a touch screen, scanned information etc. used to control the program. Examples of such interfaces include any known or later developed combination of Graphical User Interfaces (GUI) or Web-based user interfaces as seen in the accompanying drawings, Touch interfaces, Conversational Interface Agents, Live User Interfaces (LUI), Command line interfaces, Non-command user interfaces, Object-oriented User Interfaces (OOUI) or Voice user interfaces. The commands received within the software combination, or any other information, may be accepted using any field, widget and/or control used in such interfaces, including but not limited to a text-box, text field, button, hyper-link, list, drop-down list, check-box, radio button, data grid, icon, graphical image, embedded link, etc.
- The
server 110 may be communicatively coupled todata storage 130 including any information requested or required by the system and/or described herein. Thedata storage 130 may be any computer components, devices, and/or recording media that may retain digital data used for computing for some interval of time. The storage may be capable of retaining stored content for any data required, on a single machine or in a cluster of computers over thenetwork 100, in separate memory areas of the same machine such as different hard drives, or in separate partitions within the same hard drive, such as a database partition. - Non-limiting examples of the
data storage 130 may include, but are not limited to, a Network Area Storage, (“NAS”), which may be a self-contained file level computer data storage connected to and supplying a computer network with file-based data storage services. The storage subsystem may also be a Storage Area Network (“SAN”—an architecture to attach remote computer storage devices to servers in such a way that the devices appear as locally attached), an NAS-SAN hybrid, any other means of central/shared storage now known or later developed or any combination thereof. - Structurally, the
data storage 130 may comprise any collection of data. As non-limiting examples, thedata storage 130 may comprise a local database, online database, desktop database, server-side database, relational database, hierarchical database, network database, object database, object-relational database, associative database, concept-oriented database, entity-attribute-value database, multi-dimensional database, semi-structured database, star schema database, XML database, file, collection of files, spreadsheet, and/or other means of data storage such as a magnetic media, hard drive, other disk drive, volatile memory (e.g., RAM), non-volatile memory (e.g., ROM or flash), and/or any combination thereof. - The server(s) 110 or software modules within the server(s) 110 may use query languages such as MSSQL or MySQL to retrieve the content from the
data storage 130. Server-side scripting languages such as ASP, PHP, CGI/Perl, proprietary scripting software/modules/components etc. may be used to process the retrieved data. The retrieved data may be analyzed in order to determine the actions to be taken by the scripting language, including executing any method steps disclosed herein. - The software modules/components of the software combination used in the context of the current invention may be stored in the memory of—and run on—at least one
server 110. As non-limiting examples of such software, the paragraphs below describe in detail the software modules/components that make up the software combination. These software modules/components may comprise software and/or scripts containing instructions that, when executed by a microprocessor on aserver 110 orclient 120, cause the microprocessor to accomplish the purpose of the module/component as described in detail herein. The software combination may also share information, including data from data sources and/or variables used in various algorithms executed on theservers 110 and/orclients 120 within the system, between each module/component of the software combination as needed. - A
data center 140 may provide hosting services for the software combination, or any related hosted website including, but not limited to hosting one or more computers or servers in adata center 140 as well as providing the general infrastructure necessary to offer hosting services to Internet users including hardware, software, Internet web sites, hosting servers, and electronic communication means necessary to connect multiple computers and/or servers to the Internet or anyother network 100. -
FIG. 2 shows a more detailed example embodiment of an environment for the systems, and for accomplishing the method steps, disclosed herein. As non-limiting examples, all disclosedsoftware modules 200 may run on one or more server(s) 110 and may include one or more user interfaces generated by the server(s) 110 and transmitted to and displayed on the client(s) 120. The user interface(s) may be configured to receive input from the user and transmit this input to the server(s) 110 for the administration and execution of thesoftware 200, using data indata storage 130 associated with thesoftware modules 200. Thus, the disclosed system may be configured to execute any or all of the method steps disclosed herein. - Server(s) 110 may be hosted by any entity, possibly a hosting provider, a domain name registrar, a website development company, any other software service provider or any combination thereof. To manage users of such a system, including individuals or organizations, software applications running on server(s) 110, client(s) 120 mobile devices may run a
user administration program 210 such as GoDaddy's My Account control panel for management of hosting websites and managing domain names, as a non-limiting example. - In such an administration control panel program, or
admin 210, each user may be assigned a user id. This user id may identify transactions performed by each user, or other data, such as authentication information disclosed herein. These transactions, user account data 220, authentication data and/or other data may be stored as data records indata storage 130, each data record including the user id to associate the user with the relevant user or other data indata storage 130. - The
admin 210 may include or be associated with a Domain Control Center (DCC) for administration of domain names registered to the user. As non-limiting examples, the DCC may include means for listing and managing all domain names registered to the registrant, possibly including auto renewal of the domains, DNS record settings, etc. In some embodiments, the DCC may be used to display the disclosed notices, reports and/or domain name purchase offers, as described in more detail herein. - The disclosed multi authentication methods and system described herein may be applied to authentication of users to any application requiring user authentication including, but not limited to, a bank account, a shopping site, private health records, the admin described above and/or the DCC or other applications. The use of multi authentication input via
multiple client devices 120 may provide additional security to the user's personal accounts and/or the domain names registered and managed by users associated with the user account via the DCC. - The security features available may be used in any context providing users repeated access to destructive or semi-destructive actions available via multi factor authentication. As non-limiting examples, this multi factor authentication may be applied at any point in the domain name registration or administration process. Thus, the multi authentication techniques described herein may provide better security as the user: registers a domain name; transfers a domain name; locks a domain name; lists a domain name for sale; cancels a domain name; changes name servers for a domain name; changes the DNS settings for a domain name; etc. Any of the multi factor authentication means, factors, requests, challenges and/or credentials described below may be used to provide greater security for these user account.
- Multi factor authentication may comprise multiple types of authentication. As non-limiting examples, a user may request that server(s) 110 perform a particular action, such as accessing and/or updating secure information, such as the bank account data, shopping session data, medical records, domain name data or other domain name or user data previously mentioned. Prior to performing these actions, server(s) 110 may require one or more authentication factors to verify the user's identity before proceeding. These authentication factors may comprise authentication challenges (i.e., a request for user information to verify their identify) and/or authentication credentials (i.e., the response from the user verifying their identity). Authentication factors, challenges and/or credentials may fall into three general categories, possibly including, but not limited to 1) something the user knows; 2) something the user possesses; and 3) something that the user is.
- The disclosed invention comprises means for verifying a user via multi-factor authentication, and may include any combination of authentication means, factors, requests, challenges and/or credentials now known or developed in the future, including any combination of the non-limiting example embodiments disclosed herein.
- As non-limiting examples, authentication factors may include, but are not limited to: any combination of user names and passwords; software generated codes or passwords; Time-based One Time Passwords (TOTP); shared secrets; private/public key pairs (and related hashing or cryptographic algorithms); unique data associated with the user of the disclosed system (e.g., biometrics specific to a user); authentication via facial recognition; authentication via voice authentication; and/or authentication via tap codes.
- In embodiments where authentication factors comprise a combination of user names, passwords and/or a shared secret, a user interface, possibly generated by server(s) 110 and displayed on client(s) 120, may comprise an authentication challenge requesting the user name, password and/or shared secret. A shared secret may comprise data, known only to the parties involved, in a secure communication. As non-limiting examples, a shared secret may comprise a password, a passphrase, a big number or an array of randomly chosen bytes. The user may provide the response to the authentication challenge (something the user knows) to confirm and authenticate their identity.
- After the user submits the user name, password and/or shared secret, server(s) 110 may then authenticate the user and proceed with the action requiring the authentication, possibly by confirming a match for the user name, password and/or shared secret via user or other records stored in the user account data 220 in
data storage 130. If not authenticated, an alert may be transmitted and displayed to the user. - In embodiments where an authentication factor comprises a code generated by software running on server(s) 110 and/or client(s) 120, a user interface, possibly generated by server(s) 110 and displayed on client(s) 120, may comprise an authentication challenge requesting the previously disclosed shared secret and/or any other algorithm that computes a one-time password from a key and the current time (e.g., CAPTCHA). The user may provide the response (something the user knows) to confirm their identity.
- After the user submits their response to the shared secret or generated code (possibly by acknowledging the code, repeating it and sending it back), server(s) 110 may then authenticate the user and proceed with the action requiring the authentication, possibly by confirming a match for the generated code. If not authenticated, an alert may be transmitted and displayed to the user.
- In embodiments where an authentication factor comprises a private/public key pair, software on server(s) 110 and/or client(s) 120 may generate private/public key pairs comprising two separate and different keys that are mathematically linked. These keys may behave according to any private/public key algorithms known in the art. As non-limiting examples, the public key may encrypt a message and/or verify a digital signature and the private (secret) key may decrypt the message and/or create a digital signature.
- In some embodiments, one or both of these keys may be generated on, and sent from, a first device (e.g.,
client 120—something the user has) to a second device (e.g., sever 110) to verify authentication by: processing a message with a private key to produce a digital signature; processing the digital signature value with the public key; and comparing that result with the message. - In embodiments where an authentication factor comprises a unique data associated with the user (something the user is), a non-limiting example of this unique data may comprise biometric data associated with the user. Such biometric data may comprise any biometric data collected about the user, and may be gathered from, as non-limiting examples, a thumbprint scanner, a capillary distribution scanner, a retinal scanner, a DNA scanner, an implanted microchip, and/or any other means of gathering biometric data identifying a specific individual now known or discovered in the future. In some embodiments, this biometric data may be acquired and sent from a first device (e.g.,
client 120, something the user has) to a second device (e.g., sever 110). - After the user or client submits the unique data associated with the user, server(s) 110 may then authenticate the user and proceed with the action requiring the authentication, possibly by confirming a match for the biometric data via user or other records stored in
data storage 130. If not authenticated, an alert may be transmitted and displayed to the user. - In embodiments where an authentication factor comprises facial recognition technology, software running on users' client(s) 120 may work in conjunction with on-board or attached cameras to verify user identity using any facial recognition techniques, methods or systems known in the art.
- In embodiments where an authentication factor comprises voice recognition technology, software running on users' client(s) 120 may work in conjunction with on-board or attached microphones to verify user identity using any voice recognition techniques, methods or systems known in the art.
- In embodiments where an authentication factor comprises tap code technology, software running on users' client(s) 120 may be configured to work in conjunction with sensors on the client(s) 120 to receive a series of Morse-code or other style tapped input to verify user identity using any tap code techniques, methods or systems known in the art.
- The disclosed invention represents a significant advantage over existing multi factor authentication. In this multi-factor authentication, server(s) 110 may generate and/or access a first authentication request and/or challenge, possibly to be displayed on a user interface. As a non-limiting example, such a challenge may comprise an interface displayed on a web page, and configured to receive a user name/password combination from a user.
- Server(s) 110 may then transmit this first authentication challenge to one or more client(s) 120. Client(s) 120 may then display the first authentication challenge on the user interface. In response to the authentication challenge, a user may enter, as non-limiting examples, the user name and/or password into the user interface.
- Client(s) 120 may then transmit the first authentication credential, entered by the user, to server(s) 110. One or more software module(s) 200 running on server(s) 110 may then be configured to receive the first authentication credential entered and submitted by the user, and use the entered credential(s) to authenticate the user, possibly by comparing the entered credential against username, password, temporary password, public/private key and/or biometric data stored as user account data 220 on server(s) 110 and/or in
data storage 130. If the first credential is not authenticated, an alert may be generated, transmitted and displayed on client(s) 120 to the user. - If the first authentication credential is authenticated: the server may generate and/or access a second authentication challenge, to be displayed, possibly on the user interface. As non-limiting examples, the second authentication challenge may comprise a message/digital signature generated, encrypted and/or decrypted using a private/public key pair and/or a biometric scan. Server(s) 110 may then transmit this second authentication challenge to client(s) 120, possibly to a
client 120 different than the client on which the first authentication credential was authenticated. - In response to the second authentication challenge, the user, or software running on the user's client machine, may submit and/or transmit, to server(s) 110, a second authentication credential to authenticate the user. As non-limiting examples, this second authentication credential may comprise the private/public key pair message and/or the user's biometric. As a non-limiting example, the biometric may be signed by the private key on client(s) 120 and sent to server(s) 110 to verify it was collected on a valid device.
- One or more software module(s) 200 on server(s) 110 may be configured to receive the second authentication credential submitted by the client(s) 120 and authenticate the user via the second authentication credential, possibly by comparing the data against a user name, password, temporary password, public/private key and/or biometric data stored as user account data 220 on server(s) 110 and/or in
data storage 130, as disclosed above. If the second credential is not authenticated, an alert may be generated, transmitted and displayed to the user on client(s) 120. If the second factor is authenticated, the server may proceed with the process for which authentication was required. - This multi-factor authentication is not limited to two or three factors, and the verification process above may be repeated for each additional factor until all authentication challenges and credentials have been verified and authenticated.
- In some embodiments, authentication of a user may be augmented by requiring that a second, third or nth authentication credential be entered or verified via a second, third or nth channel and/or a second, third or nth device.
- As a non-limiting example, a user may not be authenticated until software, possibly running on server(s) 110, verifies that the authentication for a subsequent authentication credential is received from a different channel than the channel used to submit and/or transmit the initial or previous authentication credential(s). Non-limiting examples of such channels may include user interfaces displayed via URLs, websites, web pages, software or other apps running on client(s) 120, etc., which are different from the initial or previous URLs, website(s), web page(s), software or other app(s), possibly running on and/or received via a different device than the initial or previous device.
- For example, if a first authentication credential was entered into a user interface displayed via a first web page on a first website found at a first URL running on a first browser and/or operating system on a
first client 120, the software may be configured to determine if the second/nth authentication credential is also received via same channel (e.g., the web page, website, URL, browser and/or operating system), possibly via thesame client 120. If so, the user may not be authenticated and the software may require the user to enter one or more subsequent authentication credentials via one or more different channels (web page, website, URL, browser and/or operating system) than the first or previous channel used to enter the initial or previous authentication credential. - Similarly, a user may not be authenticated until software, possibly running on server(s) 110, verifies that authentication for a subsequent authentication was received from one or more different devices than the device used to submit and/or transmit the initial or previous authentication credential(s). Non-limiting examples of such devices may include any
client 120 and/orserver 110 device disclosed herein. - In a similar example to that above, if a first authentication credential was entered via a
client 120 laptop or desktop computer, the software may be configured to determine if the second/nth authentication credential is also received via the same device. If so, the user may not be authenticated and may be required to enter one or more subsequent authentication credentials via a different device than that used to enter the initial or previous authentication credential. - In some embodiments, the second or nth device may be authenticated via an exclusive channel available between the client(s) 120 and server(s) 110 via a private/public key pair specifically identifying the client(s) 120 and authenticating the authentication credential via the exclusive channel. Details of such private/public key pairs and exclusive channels are disclosed below.
- In some embodiments, the requirements for different channels and/or devices may be combined, so that a first authentication credential may be entered via a first channel into a first device and a second authentication credential may be required to be entered via a second channel into a second device. If additional authentication credentials are involved, the nth security credential may be required to be entered via the nth channel into an nth device, and so on.
- The second and/or nth device may also act as another form of authentication, specifically something the user has. In some embodiments, an authentication message, authentication code and/or any other authentication challenge (possibly including a user alert, as disclosed below) may be sent to a
first client 120 device, while a second message, code and/or challenge is transmitted to asecond client 120 device. In some embodiments, this message may indicate that the user has attempted to log in on the first or previous device, and is now seeking a second or nth authentication of the user's identity, and may display an alert that action is required on the part of the user to authenticate the user and continue the login. The user's response to the second authentication challenge via the second client device (by providing a second authentication credential) may act as further verification of the user's identity by providing something the user knows combined with something the user has. In some embodiments, disclosed below, the software running on server(s) 110 and/or client(s) 120 may verify the user without additional interaction with the user. - The authentication message, code and/or challenge transmitted to the user may be communicated by any means known in the art. As non-limiting examples, the message, code and/or challenge may be communicated via: a web page; an email; an SMS/text message; software running on a
client computer 120; an app running on a mobile device; a phone call, a voice message on a phone; etc. Communication means such as SMS/text, phone messages, etc. may provide broader means to send the message, code and/or challenge, since the message, code and or challenge would not rely on proprietary hardware and/or software to transmit to the user. - Server(s) 110 may generate, and transmit an authentication message, code and/or challenge to the user's
client 120, such as a user's laptop computer, as described above. On receiving this data, the user'sclient 120, possibly using the software disclosed herein, may issue an alert to the user, such as an audio chime indicating receipt of a new message, or a visual alert such as an alert window displayed on a screen, as non-limiting examples. - When the first message, code and/or challenge is transmitted, a second message, code and/or challenge may be simultaneously or subsequently sent to a user's
second client 120, such as the user's mobile device. In this example, the mobile device may be configured to display the message, code and/or challenge, and the user may input the message, code and/or challenge into a user interface on software running on the mobile device. - In some embodiments, when the second challenge is presented, requesting a second authentication credential on the second device server(s) 110 may be configured to generate and transmit additional information with the challenge indicating the action the user intends to perform with the authentication. As a non-limiting example, this action may include authorizing a payment or making an online purchase. Thus, as the alert for the second challenge is received, the message may display an additional message requesting the user to confirm the action the user intends to confirm.
- The converse is an equally valid model. Namely, server(s) 110 may generate and transmit the first message, code and/or challenge, possibly including the alert, to the user's mobile device while simultaneously or subsequently sending the second message, code and/or challenge to the user's desktop or laptop computer. Thus, any
client 120 disclosed herein may act as either the first or second device to which the message, code and/or challenge is communicated, but the response and/or authentication credentials may be required to be entered intoseparate client devices 120. - In some embodiments, a code may be displayed on a
first client 120, but then required to be entered via a channel on asecond client 120. As a non-limiting example, a code may be displayed on a PC screen with instructions to go to a phone and type the code, then click a button on the phone to encrypt and transmit the code, or conversely, communicate a code to the phone that the user must input (and/or encrypt) on a PC, etc. - In some embodiments, a user may install software on the client(s) 120, to receive the authentication message, code and/or challenge. The software may be, as non-limiting examples, a software application on a desktop or laptop and/or an app on a mobile device. The software may be further configured to establish an exclusive channel between the client(s) 120 and server(s) 110, as described below.
- The software may be automatically configured upon installation, to identify the client(s) 120 as something the user owns in order to authenticate the user's identity. Alternatively, a user may configure the software during installation to accomplish the same purpose. In some embodiments, the software may include means for the user to log in to a user account, possibly by providing a username and password.
- The software may be configured to receive the incoming message, code and/or challenge. As noted above, the software may be configured to display an alert on the client(s) 120 when the user receives such a message, code and/or challenge. In embodiments requiring user input, the software may then be configured to receive authentication credentials or other acknowledgements from the user.
- In some embodiments, the software itself may display the alert and/or code generated by software on server(s) 110 or client(s) 120. The alert and/or code may comprise TOTP, answer to shared secrets, other generated passwords, etc. In these embodiments, SMS, text and or phone messages would not be necessary. In embodiments where the alert, generated code, TOTP, answer to shared secrets, etc. is generated by the software and displayed, the user may simply need to click a button on a user interface to verify receipt of the alert/login attempt and confirm the authentication.
- In some embodiments, installation of the software may cause client(s) 120 to automatically generate a private/public key pair, used for private/public key encryption of messages and/or authentication data transmitted between server(s) 110 and client(s) 120. This private/public key pair may act as one of the trusted authentication credentials (i.e., an initial or secondary authentication credential) used to verify the user's identity. As a non-limiting example, the private/public key pair may act as a secondary authentication credential (proof of something the user has) when a user attempts to log in via user name/password as a primary authentication credential (something the user knows).
- On installation of the software in these embodiments, the software and/or the client(s) 120 may be configured to generate a unique public/private key pair. The client and/or software may then be configured to store the private key and transmit the public key to server(s) 110 to be stored in the cloud.
- In these embodiments, the public key may generate a digital signature and the private (secret) key may sign any data transmitted to the server.
- The key in the public key may be installed, published and/or stored the hosting
servers 110 in association with the user, the user'sclient device 120 and/or any other user data. In some embodiments, this association may be accomplished via data records that join data, such as a user id identifying the user, to the published/stored key(s). - Associating the user and client(s) 120 with software and/or data on the
server 110 via the private/public key pair may bind each and all of these together, creating authentication as a primary or secondary authentication credential, since code on the client(s) 120 is bound to code on the server(s) 110 via an exclusive encryption channel between client(s) 120 and server(s) 110. - With this exclusive encryption channel established, server(s) 110 may generate and transmit an authentication message, code and/or challenge to client(s) 120, seeking either a primary or secondary authentication. The software on the client(s) 120 may receive this message, code and/or challenge and generate and/or receive a response to the message, which may then be signed by the private key and transmitted to server(s) 110.
- In some embodiments, the user may need to enter data to respond to the challenge. In these embodiments, the software running on the client(s) 120 may display a code or other data, which the user must enter before proceeding. In other embodiments, the code or other data may not be necessary. The user may simply click a button on the user interface that either a generated authentication credential is OK, or that the user wants to proceed with the public/private key authentication, where the software client(s) 120 would simply confirm the public/private key encryption channel. Because the code on the client(s) 120 and server(s) 110 are bound together as described above, only this credential would be necessary to proceed.
- In entirely automated embodiments, user interaction may not be necessary at all. In these embodiments, the installed software may recognize the incoming challenge and may generate the response including and/or encoded with the necessary digital signature or encryption necessary to authenticate the user and/or the client machine.
- Regardless of the means for generating, entering and/or approving the response, once the user response has been created, the software on client(s) 120 may use the key to generate/ the digital signature the software may then transmit the digital signature to server(s) 110 via the exclusive channel between client(s) 120 and server(s) 110 for authentication.
- In some embodiments, following authentication of a first authentication factor and a second authentication factor, the disclosed system and methods may require a third authentication factor. In these embodiments, authentication of a user may require three separate authentication factors including 1) something a user knows; 2) something the user has; and 3) something the user is. Any of the previously disclosed authentication factors and/or methods may be used to verify these three separate authentication factors.
- Although no authentication system or method is 100% secure, providing a third authentication factor, each factor reflecting a different element in relation to the user greatly enhances the security of the user's authentication. As a non-limiting example, a user may enter a login/password entry or other transaction, possibly on a first device (i.e., entering something the user knows).
- A second transaction may comprise a software running on the user's
client 120 machine, configured to alert the user to the first transaction and confirm the transaction, possibly via the private/public key on the client 120 (i.e., using the exclusive connection to confirm something the user has). The user may enter data to confirm the transaction, click an OK button displayed on the client(s) 120 to confirm the transaction with the private key on that device and/or allow an installed software to generate a second authentication, possibly including a digital signature, and the response before sending to server(s) 110. - Before generating and/or the /signature, however, the disclosed systems/methods may require the user to enter a biometric (i.e., entering something the user is), and may only generate the signature to confirm the transaction based on the presence of the biometric. For example, where a thumb print or other biometric is used as part of the authentication, the server(s) 110 may be configured to verify the biometric Any of the three types of authentication, including this biometric, may be encrypted and/or digitally signed as disclosed herein prior to transmitting the response to server(s) 110.
- Thus, if the user's phone were stolen, and a thief was to already know the user's one username/password authentication, the user's authentication may compromised. The thief would be able to confirm any transaction if they have both the phone and the username/password. However, using three factor authentication, the username/password, device (possibly including the private/public key pair) and biometric would be required to spoof the authentication, guaranteeing a more secure authentication.
- Several different methods may be used to provide and manage the present systems.
FIG. 3 represents a flow diagram for one possible embodiment of the previously described improvements on presently existing systems. In this example embodiment, one ormore server computers 110 may be communicatively coupled to thenetwork 100 and may be configured to: receive a first transmission, from a first client computer communicatively coupled to the network, comprising an authentication credential selected from a plurality of authentication credentials comprising: a first authentication credential known only to a user; a second authentication credential identifying a client computer; and a third authentication credential identifying a characteristic unique to the user (Step 300); receive a second transmission, from a second client computer communicatively coupled to the network, comprising at least one additional authentication credential selected from the plurality of authentication credentials (Step 310); and verify the identity of the user via a match, within a database communicatively coupled to the network, to the first authentication credential, the second authentication credential and the third authentication credential (Step 320). - The steps included in the embodiments illustrated and described in relation to
FIGS. 1-3 are not limited to the embodiment shown and may be combined in several different orders and modified within multiple other embodiments. Although disclosed in specific combinations within these figures, the steps disclosed may be independent, arranged and combined in any order and/or dependent on any other steps or combinations of steps. - Other embodiments and uses of the above inventions will be apparent to those having ordinary skill in the art upon consideration of the specification and practice of the invention disclosed herein. The specification and examples given should be considered exemplary only, and it is contemplated that the appended claims will cover any other such embodiments or modifications as fall within the true scope of the invention.
- The Abstract accompanying this specification is provided to enable the United States Patent and Trademark Office and the public generally to determine quickly from a cursory inspection the nature and gist of the technical disclosure and in no way intended for defining, determining, or limiting the present invention or any of its embodiments.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/833,426 US20180097806A1 (en) | 2015-02-24 | 2017-12-06 | Multi factor user authentication on multiple devices |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/630,363 US9686272B2 (en) | 2015-02-24 | 2015-02-24 | Multi factor user authentication on multiple devices |
US15/427,464 US9871791B2 (en) | 2015-02-24 | 2017-02-08 | Multi factor user authentication on multiple devices |
US15/833,426 US20180097806A1 (en) | 2015-02-24 | 2017-12-06 | Multi factor user authentication on multiple devices |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/427,464 Continuation US9871791B2 (en) | 2015-02-24 | 2017-02-08 | Multi factor user authentication on multiple devices |
Publications (1)
Publication Number | Publication Date |
---|---|
US20180097806A1 true US20180097806A1 (en) | 2018-04-05 |
Family
ID=56693734
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/630,363 Active 2035-04-29 US9686272B2 (en) | 2015-02-24 | 2015-02-24 | Multi factor user authentication on multiple devices |
US15/427,464 Active US9871791B2 (en) | 2015-02-24 | 2017-02-08 | Multi factor user authentication on multiple devices |
US15/833,426 Abandoned US20180097806A1 (en) | 2015-02-24 | 2017-12-06 | Multi factor user authentication on multiple devices |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/630,363 Active 2035-04-29 US9686272B2 (en) | 2015-02-24 | 2015-02-24 | Multi factor user authentication on multiple devices |
US15/427,464 Active US9871791B2 (en) | 2015-02-24 | 2017-02-08 | Multi factor user authentication on multiple devices |
Country Status (1)
Country | Link |
---|---|
US (3) | US9686272B2 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11301586B1 (en) * | 2019-04-05 | 2022-04-12 | T Stamp Inc. | Systems and processes for lossy biometric representations |
WO2022122403A1 (en) * | 2020-12-08 | 2022-06-16 | British Telecommunications Public Limited Company | User authentication |
US20220407851A1 (en) * | 2021-06-18 | 2022-12-22 | Kyndryl, Inc. | Unattended authentication in http using time-based one-time passwords |
US11936790B1 (en) | 2018-05-08 | 2024-03-19 | T Stamp Inc. | Systems and methods for enhanced hash transforms |
US11967173B1 (en) | 2020-05-19 | 2024-04-23 | T Stamp Inc. | Face cover-compatible biometrics and processes for generating and using same |
US11972637B2 (en) | 2018-05-04 | 2024-04-30 | T Stamp Inc. | Systems and methods for liveness-verified, biometric-based encryption |
US12039021B2 (en) | 2019-03-07 | 2024-07-16 | British Telecommunications Public Limited Company | Multi-level classifier based access control |
Families Citing this family (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9202105B1 (en) | 2012-01-13 | 2015-12-01 | Amazon Technologies, Inc. | Image analysis for user authentication |
FR3028980B1 (en) * | 2014-11-20 | 2017-01-13 | Oberthur Technologies | METHOD AND DEVICE FOR AUTHENTICATING A USER |
US10050789B2 (en) * | 2015-04-24 | 2018-08-14 | Red Hat, Inc. | Kerberos preauthentication with J-PAKE |
US10374802B2 (en) * | 2015-04-24 | 2019-08-06 | Red Hat, Inc. | Multi-factor simple password exponential key exchange (SPEKE) authentication |
US11102199B2 (en) * | 2015-08-10 | 2021-08-24 | Laurence Hamid | Methods and systems for blocking malware attacks |
US10560427B2 (en) * | 2015-09-29 | 2020-02-11 | Verisign, Inc. | Domain name operation verification code generation and/or verification |
WO2017087981A2 (en) | 2015-11-20 | 2017-05-26 | Payeazy, Inc. | Systems and methods for authenticating users of a computer system |
US10164973B1 (en) | 2015-12-02 | 2018-12-25 | United Services Automobile Association (Usaa) | Public authentication systems and methods |
JP6507115B2 (en) * | 2016-03-22 | 2019-04-24 | 株式会社日立製作所 | 1: N biometric authentication · encryption · signature system |
US11176231B2 (en) * | 2016-05-19 | 2021-11-16 | Payfone, Inc. | Identifying and authenticating users based on passive factors determined from sensor data |
US20170357799A1 (en) * | 2016-06-12 | 2017-12-14 | Logmein, Inc. | Tracking and managing multiple time-based one-time password (TOTP) accounts |
US10057255B2 (en) * | 2016-07-20 | 2018-08-21 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using multi-device authentication techniques |
US10148646B2 (en) * | 2016-07-20 | 2018-12-04 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using tokenized authentication techniques |
US10057249B2 (en) * | 2016-07-20 | 2018-08-21 | Bank Of America Corporation | Preventing unauthorized access to secured information systems using tokenized authentication techniques |
US10511570B2 (en) | 2016-08-30 | 2019-12-17 | Verisign, Inc. | Systems, devices, and methods for locality-based domain name registry operation verification |
US10263971B2 (en) | 2016-08-31 | 2019-04-16 | Bank Of America Corporation | Preventing unauthorized access to secured information systems by injecting device data collectors |
US10412093B2 (en) | 2016-08-31 | 2019-09-10 | Bank Of America Corporation | Preventing unauthorized access to secured information systems by injecting device data collectors |
US20180145959A1 (en) * | 2016-11-22 | 2018-05-24 | Synergex Group | Method for determining access privilege using username, IP address, App ID, App Key, and biometric signature sample. |
US10911452B2 (en) | 2016-11-22 | 2021-02-02 | Synergex Group (corp.) | Systems, methods, and media for determining access privileges |
US10382413B1 (en) * | 2016-12-23 | 2019-08-13 | Cisco Technology, Inc. | Secure bootstrapping of client device with trusted server provided by untrusted cloud service |
WO2018132844A1 (en) | 2017-01-13 | 2018-07-19 | Payeazy, Inc. | Authentication systems and methods for online services |
DE102017105771A1 (en) * | 2017-03-17 | 2018-09-20 | Deutsche Telekom Ag | Access control procedure |
US10362022B2 (en) * | 2017-04-13 | 2019-07-23 | Ubs Business Solutions Ag | System and method for facilitating multi-connection-based authentication |
US20180367528A1 (en) * | 2017-06-12 | 2018-12-20 | Cyberark Software Ltd. | Seamless Provision of Authentication Credential Data to Cloud-Based Assets on Demand |
US10972458B1 (en) * | 2017-07-14 | 2021-04-06 | United Services Automobile Association (Usaa) | Methods and systems for authentication assistant |
US11558365B1 (en) * | 2017-10-10 | 2023-01-17 | NortonLifeLock Inc. | Multi-second factor authentication |
US10594685B2 (en) * | 2017-10-19 | 2020-03-17 | Salesforce.Com, Inc. | User selected key authentication |
WO2019079815A1 (en) * | 2017-10-20 | 2019-04-25 | Asignio Inc. | Electronic verification systems and methods |
US11429745B2 (en) * | 2017-10-30 | 2022-08-30 | Visa International Service Association | Data security hub |
US10068082B1 (en) * | 2017-11-16 | 2018-09-04 | Fmr Llc | Systems and methods for maintaining split knowledge of web-based accounts |
US11496322B2 (en) * | 2018-05-21 | 2022-11-08 | Entrust, Inc. | Identity management for software components using one-time use credential and dynamically created identity credential |
US11405386B2 (en) | 2018-05-31 | 2022-08-02 | Samsung Electronics Co., Ltd. | Electronic device for authenticating user and operating method thereof |
US11178148B2 (en) * | 2018-08-21 | 2021-11-16 | HYPR Corp. | Out-of-band authentication to access web-service with indication of physical access to client device |
US10795982B2 (en) * | 2018-08-23 | 2020-10-06 | International Business Machines Corporation | CAPTCHA generation based on environment-specific vocabulary |
US11184173B2 (en) | 2018-08-24 | 2021-11-23 | Powch, LLC | Secure distributed information system |
CN110932858B (en) * | 2018-09-19 | 2023-05-02 | 阿里巴巴集团控股有限公司 | Authentication method and system |
US11165581B2 (en) * | 2018-10-05 | 2021-11-02 | Mimecast Services Ltd. | System for improved identification and authentication |
US11032275B2 (en) * | 2018-10-05 | 2021-06-08 | Mimecast Services Ltd. | System for improved identification and authentication |
US10484377B1 (en) | 2018-10-17 | 2019-11-19 | Capital One Services, Llc | Systems and methods for multi-device multi-factor authentication |
WO2020092351A1 (en) * | 2018-10-29 | 2020-05-07 | Login Id Inc. | Decentralized computing systems for strong user authentication and related methods |
US11134077B2 (en) * | 2018-10-30 | 2021-09-28 | EMC IP Holding Company LLC | User-controlled transaction annotation for authentication events across multiple user devices |
US11880842B2 (en) * | 2018-12-17 | 2024-01-23 | Mastercard International Incorporated | United states system and methods for dynamically determined contextual, user-defined, and adaptive authentication |
CN111726320B (en) | 2019-03-19 | 2022-08-30 | 阿里巴巴集团控股有限公司 | Data processing method, device and equipment |
JP7200785B2 (en) * | 2019-03-20 | 2023-01-10 | 富士フイルムビジネスイノベーション株式会社 | Information processing device, information processing system, and program |
CN110445775B (en) * | 2019-07-24 | 2021-08-20 | 创新先进技术有限公司 | Method and apparatus for account management |
US10798094B2 (en) | 2019-07-24 | 2020-10-06 | Alibaba Group Holding Limited | Blockchain-based account management |
US11570169B2 (en) | 2019-09-25 | 2023-01-31 | International Business Machines Corporation | Multi-factor authentication via multiple devices |
US11971980B2 (en) | 2020-05-28 | 2024-04-30 | Red Hat, Inc. | Using trusted execution environments to perform a communal operation for mutually-untrusted devices |
US11947659B2 (en) | 2020-05-28 | 2024-04-02 | Red Hat, Inc. | Data distribution across multiple devices using a trusted execution environment in a mobile device |
US11848924B2 (en) * | 2020-10-12 | 2023-12-19 | Red Hat, Inc. | Multi-factor system-to-system authentication using secure execution environments |
US11777917B2 (en) | 2020-10-15 | 2023-10-03 | Cisco Technology, Inc. | Multi-party cloud authenticator |
US20220141029A1 (en) * | 2020-10-29 | 2022-05-05 | Microsoft Technology Licensing, Llc | Using multi-factor and/or inherence-based authentication to selectively enable performance of an operation prior to or during release of code |
EP4328768A1 (en) * | 2021-08-09 | 2024-02-28 | Samsung Electronics Co., Ltd. | Electronic device for performing different login processes according to authentication type and control method thereof |
US11829498B2 (en) * | 2021-08-18 | 2023-11-28 | Bank Of America Corporation | Real-time dynamic blockchain securitization platform |
US20230196375A1 (en) * | 2021-12-17 | 2023-06-22 | Bank Of America Corporation | Multi-Factor User Authentication |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070136581A1 (en) * | 2005-02-15 | 2007-06-14 | Sig-Tec | Secure authentication facility |
US20080098464A1 (en) * | 2006-10-24 | 2008-04-24 | Authernative, Inc. | Two-channel challenge-response authentication method in random partial shared secret recognition system |
US8181232B2 (en) * | 2005-07-29 | 2012-05-15 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US20120297466A1 (en) * | 2011-05-16 | 2012-11-22 | Qualcomm Innovation Center, Inc. | Method, device, and system to share information between mobile computing devices |
US8522010B2 (en) * | 2008-10-20 | 2013-08-27 | Microsoft Corporation | Providing remote user authentication |
US20130226812A1 (en) * | 2012-02-24 | 2013-08-29 | Mads Landrok | Cloud proxy secured mobile payments |
US20130262873A1 (en) * | 2012-03-30 | 2013-10-03 | Cgi Federal Inc. | Method and system for authenticating remote users |
US20140187189A1 (en) * | 2012-12-27 | 2014-07-03 | Motorola Solutions, Inc. | Method of and system for authenticating and operating personal communication devices over public safety networks |
US20140189808A1 (en) * | 2012-12-28 | 2014-07-03 | Lookout, Inc. | Multi-factor authentication and comprehensive login system for client-server networks |
US20140289833A1 (en) * | 2013-03-22 | 2014-09-25 | Marc Briceno | Advanced authentication techniques and applications |
US20140331282A1 (en) * | 2013-05-01 | 2014-11-06 | Dmitri Tkachev | Methods and Systems for Identifying, Verifying, and Authenticating an Identity |
US20150244706A1 (en) * | 2014-02-26 | 2015-08-27 | Secureauth Corporation | Security object creation, validation, and assertion for single sign on authentication |
US20160057124A1 (en) * | 2014-08-25 | 2016-02-25 | Smart Technologies, Ulc | System and Method for Authentication in Distributed Computing Environments |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020194499A1 (en) * | 2001-06-15 | 2002-12-19 | Audebert Yves Louis Gabriel | Method, system and apparatus for a portable transaction device |
US8819437B2 (en) * | 2010-09-30 | 2014-08-26 | Microsoft Corporation | Cryptographic device that binds an additional authentication factor to multiple identities |
US20160117673A1 (en) * | 2012-02-24 | 2016-04-28 | Cryptomathic Limited | System and method for secured transactions using mobile devices |
DE13771788T1 (en) * | 2012-04-01 | 2015-12-17 | Authentify, Inc. | Secure authentication in a multiparty system |
US20140237256A1 (en) * | 2013-02-17 | 2014-08-21 | Mourad Ben Ayed | Method for securing data using a disposable private key |
US9443073B2 (en) * | 2013-08-08 | 2016-09-13 | Duo Security, Inc. | System and method for verifying status of an authentication device |
EP2979426A1 (en) * | 2013-03-27 | 2016-02-03 | Interdigital Patent Holdings, Inc. | Seamless authentication across multiple entities |
US8905303B1 (en) * | 2013-09-01 | 2014-12-09 | Mourad Ben Ayed | Method for adaptive wireless payment |
US9722984B2 (en) * | 2014-01-30 | 2017-08-01 | Netiq Corporation | Proximity-based authentication |
US20160066184A1 (en) * | 2014-08-29 | 2016-03-03 | Intel Corporation | Pairing Computing Devices According To A Multi-Level Security Protocol |
US9686245B2 (en) * | 2014-09-16 | 2017-06-20 | Entersekt International Limited | System and method for secure authentication |
-
2015
- 2015-02-24 US US14/630,363 patent/US9686272B2/en active Active
-
2017
- 2017-02-08 US US15/427,464 patent/US9871791B2/en active Active
- 2017-12-06 US US15/833,426 patent/US20180097806A1/en not_active Abandoned
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070136581A1 (en) * | 2005-02-15 | 2007-06-14 | Sig-Tec | Secure authentication facility |
US8181232B2 (en) * | 2005-07-29 | 2012-05-15 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US20080098464A1 (en) * | 2006-10-24 | 2008-04-24 | Authernative, Inc. | Two-channel challenge-response authentication method in random partial shared secret recognition system |
US8522010B2 (en) * | 2008-10-20 | 2013-08-27 | Microsoft Corporation | Providing remote user authentication |
US20120297466A1 (en) * | 2011-05-16 | 2012-11-22 | Qualcomm Innovation Center, Inc. | Method, device, and system to share information between mobile computing devices |
US20130226812A1 (en) * | 2012-02-24 | 2013-08-29 | Mads Landrok | Cloud proxy secured mobile payments |
US20130262873A1 (en) * | 2012-03-30 | 2013-10-03 | Cgi Federal Inc. | Method and system for authenticating remote users |
US20140187189A1 (en) * | 2012-12-27 | 2014-07-03 | Motorola Solutions, Inc. | Method of and system for authenticating and operating personal communication devices over public safety networks |
US20140189808A1 (en) * | 2012-12-28 | 2014-07-03 | Lookout, Inc. | Multi-factor authentication and comprehensive login system for client-server networks |
US20140289833A1 (en) * | 2013-03-22 | 2014-09-25 | Marc Briceno | Advanced authentication techniques and applications |
US20140331282A1 (en) * | 2013-05-01 | 2014-11-06 | Dmitri Tkachev | Methods and Systems for Identifying, Verifying, and Authenticating an Identity |
US20150244706A1 (en) * | 2014-02-26 | 2015-08-27 | Secureauth Corporation | Security object creation, validation, and assertion for single sign on authentication |
US20160057124A1 (en) * | 2014-08-25 | 2016-02-25 | Smart Technologies, Ulc | System and Method for Authentication in Distributed Computing Environments |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11972637B2 (en) | 2018-05-04 | 2024-04-30 | T Stamp Inc. | Systems and methods for liveness-verified, biometric-based encryption |
US11936790B1 (en) | 2018-05-08 | 2024-03-19 | T Stamp Inc. | Systems and methods for enhanced hash transforms |
US12039021B2 (en) | 2019-03-07 | 2024-07-16 | British Telecommunications Public Limited Company | Multi-level classifier based access control |
US11301586B1 (en) * | 2019-04-05 | 2022-04-12 | T Stamp Inc. | Systems and processes for lossy biometric representations |
US11741263B1 (en) * | 2019-04-05 | 2023-08-29 | T Stamp Inc. | Systems and processes for lossy biometric representations |
US11861043B1 (en) * | 2019-04-05 | 2024-01-02 | T Stamp Inc. | Systems and processes for lossy biometric representations |
US11886618B1 (en) * | 2019-04-05 | 2024-01-30 | T Stamp Inc. | Systems and processes for lossy biometric representations |
US11967173B1 (en) | 2020-05-19 | 2024-04-23 | T Stamp Inc. | Face cover-compatible biometrics and processes for generating and using same |
WO2022122403A1 (en) * | 2020-12-08 | 2022-06-16 | British Telecommunications Public Limited Company | User authentication |
US20220407851A1 (en) * | 2021-06-18 | 2022-12-22 | Kyndryl, Inc. | Unattended authentication in http using time-based one-time passwords |
US11750597B2 (en) * | 2021-06-18 | 2023-09-05 | Kyndryl, Inc. | Unattended authentication in HTTP using time-based one-time passwords |
Also Published As
Publication number | Publication date |
---|---|
US20170149774A1 (en) | 2017-05-25 |
US20160248752A1 (en) | 2016-08-25 |
US9686272B2 (en) | 2017-06-20 |
US9871791B2 (en) | 2018-01-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9871791B2 (en) | Multi factor user authentication on multiple devices | |
US10333916B2 (en) | Disposable browsers and authentication techniques for a secure online user environment | |
US9838205B2 (en) | Network authentication method for secure electronic transactions | |
US7562222B2 (en) | System and method for authenticating entities to users | |
US9231925B1 (en) | Network authentication method for secure electronic transactions | |
KR100800339B1 (en) | Method and system for user-determined authentication and single-sign-on in a federated environment | |
US9191394B2 (en) | Protecting user credentials from a computing device | |
JP5844001B2 (en) | Secure authentication in multi-party systems | |
CA2689847C (en) | Network transaction verification and authentication | |
US8532620B2 (en) | Trusted mobile device based security | |
US20050021975A1 (en) | Proxy based adaptive two factor authentication having automated enrollment | |
EP2572489B1 (en) | System and method for protecting access to authentication systems | |
US9009800B2 (en) | Systems and methods of authentication in a disconnected environment | |
US20210306334A1 (en) | Conditionally-deferred authentication steps for tiered authentication | |
US11363009B2 (en) | System and method for providing secure cloud-based single sign-on connections using a security service provider having zero-knowledge architecture | |
US9332011B2 (en) | Secure authentication system with automatic cancellation of fraudulent operations | |
US20060122936A1 (en) | System and method for secure publication of online content | |
Binu et al. | A mobile based remote user authentication scheme without verifier table for cloud based services | |
WO2005094264A2 (en) | Method and apparatus for authenticating entities by non-registered users | |
Balaji et al. | Web-Based System—Authentication to Single Log-on to Several Applications | |
McDaniel | AT&T Labs-Research May 31, 2002 | |
AU2015258292A1 (en) | System and method for protecting access to authentication systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GO DADDY OPERATING COMPANY, LLC, ARIZONA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BLINN, ARNOLD NEIL;REEL/FRAME:044337/0362 Effective date: 20150223 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: ROYAL BANK OF CANADA, CANADA Free format text: SECURITY AGREEMENT;ASSIGNORS:GO DADDY OPERATING COMPANY, LLC;GD FINANCE CO, LLC;GODADDY MEDIA TEMPLE INC.;AND OTHERS;REEL/FRAME:062782/0489 Effective date: 20230215 |