Location determination for user authentication

Abstract
User authentication techniques based on geographical locations associated with a client device are provided. An example method for authentication of the client device includes receiving an authentication request from the client device. The method may include establishing current geographical location of the client device based on metadata received from the client device. The method may further include establishing a trusted tolerance geographical area based on historical location area associated with the client device. After establishing the trusted tolerance geographical area, the method may proceed with determining whether the current geographical location of the client device is within the trusted tolerance geographical area. The method may further include authenticating the client device based on the determination that the current geographical location of the client device is within the trusted tolerance geographical area.
Description
TECHNICAL FIELD

This disclosure relates generally to computer and network security and, more particularly, user authentication based on geographical location of client devices accessing network services or data resources.


DESCRIPTION OF RELATED ART

The approaches described in this section could be pursued but are not necessarily approaches that have previously been conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.


Today, wireless communication network technologies allow portable computing devices, such as mobile phones or tablet computers, to access network resources and various services from any location wherever a suitable communications network can be found. It is very common nowadays for users to travel with their portable computing devices within a city of their residence, other cities, states, or even other countries.


The security of data stored on the portable computing devices is important to many users. Many users may store credentials (i.e., logins and passwords) for access to various sensitive network resources and online services on their portable computing devices, for example, in the form of auto-login scripts or auto-fill scripts. Additionally, Internet browsers may store user credentials to make it easy for the users to visit certain websites. However, user credentials may be stolen by someone who seeks and exploits weaknesses in a computer system or computer network. Alternatively, a portable computing device can be stolen to get access to certain network resources and services using the stolen portable computing device. In either case, unlawful use of the user accounts or data can result, which is a common form of identity theft. Accordingly, there is always need for improved user authentication.


SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.


The present disclosure approaches provide for user authentication based on determination of a current geographical location of client device. More specifically, according to one approach of the present disclosure, there are provided two or more host machines, which geographical locations are known or predetermined. A client device, such as a mobile phone or portable computing device may establish a network connection using any connection-oriented network protocol, for example, a Transmission Control Protocol (TCP), with these two or more host machines. Upon a request received from the client device by one of these host machines, test messages can be exchanged between the client device and each of the host machines so that round trip times (RTTs) of these test messages can be measured. Furthermore, based at least in part on the measured RTTs, distances between the client device and each of the host machines can be calculated. Additionally, angles of a triangle with corners corresponding to geographical locations of the client device and two host machines can be calculated. Based on the distances and, optionally, the angles, a geographical location of the client device may be determined along with associated metadata. The associated metadata may include, for example, a geographical name (e.g., a state and city), a zip or postal code, and geographical coordinates (e.g., a latitude and longitude values). The current geographical location can be then evaluated against a tolerance geographical area which may relate to device historical locations. If it is determined that the client device is located within the tolerance geographical area, the client device may be authenticated. Additionally, the authentication process may involve additional steps of verifying user credentials or requiring user to provide personal information to confirm the identity. Alternatively, when it is determined that the client device is not located with the tolerance geographical area, the client device cannot be authenticated, and access is denied.


According to various embodiments, the tolerance geographical area may be based on historical location data, which may include geo-identifiers of places where the client device may have been previously located. In this regard, if it is known that a user commonly uses his device from home and typically does not travel outside his city of residence, an attempt to access network resources associated with the user or the client device itself from other than mentioned location, would be considered a potential security issue. In this case, the user may need to provide user credentials or additional layers of security such as sending a one-time (OTP) password, asking additional security questions, and so forth, can be implemented. In certain embodiments, the tolerance geographical area may be dynamically updated every time the client device is authenticated. It should be understood that tolerance geographical areas are not limited to triangles, and, in various embodiments, may have any suitable topology or shape. Furthermore, the tolerance geographical area may have a margin of error extended to account for false or erroneous location determination.


According to another embodiment, a time-based mechanism to perform user authentication can be utilized. More specifically, a current geographical location of the client device can be determined and in response to a user authentication request, compared to a previous geographical location of the client device in association with a corresponding a timestamp. Furthermore, a trip time from the previous geographical location to the current geographical location based on a current time and the timestamp retrieved can be estimated. If it is determined that the trip time is reasonable, the client device may be authenticated. Otherwise, e.g., when the estimated trip time is too short for the device to possibly travel between the two locations, the client device may not be authenticated.


In further example embodiments of the present disclosure, the method steps are stored on a machine-readable medium comprising instructions, which when implemented by one or more processors perform the recited steps. In yet further example embodiments, hardware systems, or devices can be adapted to perform the recited steps. Other features, examples, and embodiments are described below.





BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are illustrated by way of example, and not by limitation, in the figures of the accompanying drawings, in which like references indicate similar elements and in which:



FIG. 1 shows a high level block diagram of a system environment suitable for implementing various embodiments of the present disclosure.



FIG. 2 shows a high level block diagram of another system environment suitable for implementing various embodiments of the present disclosure.



FIG. 3A shows a high level block diagram of an exemplary client device.



FIG. 3B shows a high level block diagram of an exemplary host machine.



FIG. 4 is a process flow diagram showing a method for user authentication according to an example embodiment.



FIG. 5 is a process flow diagram showing a method for user authentication according to another example embodiment.



FIG. 6 shows a diagrammatic representation of a computing device for a machine in the example electronic form of a computer system, within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein can be executed.





DETAILED DESCRIPTION

The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These example embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the present subject matter. The embodiments can be combined, other embodiments can be utilized, or structural, logical, and electrical changes can be made without departing from the scope of what is claimed. The following detailed description is therefore not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents. In this document, the terms “a” and “an” are used, as is common in patent documents, to include one or more than one. In this document, the term “or” is used to refer to a nonexclusive “or,” such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated.


The techniques of the embodiments disclosed herein may be implemented using a variety of technologies. For example, the methods described herein may be implemented in software executing on a computer system or in hardware utilizing either a combination of microprocessors or other specially designed application-specific integrated circuits (ASICs), programmable logic devices, or various combinations thereof. In particular, the methods described herein may be implemented by a series of computer-executable instructions residing on a storage medium such as a disk drive, or computer-readable medium. It should be noted that methods disclosed herein can be implemented by a computer (e.g., a desktop computer, tablet computer, laptop computer), game console, handheld gaming device, cellular phone, smart phone, smart television system, and so forth.


As outlined in the summary, the embodiments of the present disclosure refer to user authentication in any connection-oriented networks based on a current geographical location of a client device. The client device in possession of a user may relate to a wide range of electronic devices having ability to establish a network connection. Some examples of client devices may include a computer (desktop computer, laptop computer, tablet computer, portable computing device such as a personal digital assistant), a cellular phone (e.g., a smart phone), game console, in-vehicle computer system, and so forth. The geographical location of the client device may be determined based on measurements performed by host machines as described in greater detail below. The term “host machine,” as used herein, may refer to any suitable network node or a computing device coupled to a computer network. The host machine may perform a number of various functions such as store data or provide access to multiple information resources, services, and applications.



FIG. 1 shows a high level block diagram of a system environment 100 suitable for implementing various embodiments of the present disclosure. As shown in the figure, there are a client device 110 and two host machines: a first host machine 120 and a second host machine 130. The client device 110 may establish an IP network connection with each of the host machines 120, 130.


Each of the devices 110-130 is associated with specific geographical locations denoted in the figure as A, B, and C, accordingly. The geographical locations A and B pertaining to the host machines 120, 130 may be predetermined or known. Accordingly, a distance L1 between the first host machine 120 and the second host machine 130 may be also known or predetermined. The location C of the client device 110 is unknown prior to an authentication process as described herein.


When a user of client device 110 wants to access specific network resources or services provided by one of the host machines 120, 130 or any other host machine (not shown), the client device 110 generates an authentication request and sends it, for example, to the first host machine 120. In response, the first host machine 120 or any other networked device initiates the authentication process. In particular, there may be generated test messages and exchanged between the first host machine 120 and the client device 110. Similarly, another test message may be exchanged between the second host machine 130 and the client device 110. The test messages can be used to measure a first round trip time (RTT) with respect the client device 110 and the first host machine 120, and a second RTT with respect the client device 110 and the second host machine 130. Based on the measured first and second RTTs, a distance L2 between the client device 110 and the first host machine 120 and a distance L3 between the client device 110 and the second host machine 130 can be calculated. Furthermore, based on at least the known distances L1, L2 and L3, the location C of the client device 110 may be determined.


In certain embodiments, there may be also calculated angles of a triangle with corners correlating to the location A, B and C. These angles are shown in the FIG. 1 as α, β and γ. The calculation of these angles may be performed by utilizing, for example, a low of cosines. In general, the angles of the triangle may facilitate determining the geographical location C of the client device 110. It should be also clear that although only the operations involving two host machines 120, 130 are shown and described, the number of host machines performing RTT measurements may be more than two. In certain circumstances, a greater number of the host machines may increase accuracy of determination of the location C. For example, knowing distances from three host machines to the client device 110 may unambiguously determine an absolute location C of the client device 110.


In certain embodiments, “RTT smoothing” technique can be implemented. Specifically, the RTTs may be measured multiple times between each of mentioned directions. Furthermore, average values of the RTTs in each direction can be calculated. As will be appreciated by those skilled in the art, this process may enhance the quality of the distance calculation.


It should be also noted that the geographical location C of the client device 110 may include merely a geo-identifier. In an example, the geo-identifier may relate to a geographical name (e.g., a state and city, or state, city and district title, or state, city and street address). In another example, the geo-identifier may relate to a zip or postal code. In yet another example, the geo-identifier may relate absolute coordinates including latitude and longitude. Geo information can be obtained from third party databases which provide such information based on various network characteristics.


According to various embodiments, when the geographical location C is determined, it may be evaluated to see if it is within a “trusted area”—a tolerance geographical area 140. The tolerance geographical area 140 may be, for example, predetermined or fixed to certain place(s). In another example, the tolerance geographical area 140 may be based on locations where the client device 110 has been successfully authenticated in the past. Accordingly, in certain embodiments, the tolerance geographical area 140 may be dynamically updated each time the client device 110 is successfully authenticated. Furthermore, the tolerance geographical area 140 may have any suitable topology or shape such as, for example, a circle, triangle, square, an outline of a city or district, and so forth. In certain embodiments, the tolerance geographical area 140 may be artificially extended, especially in case when initial square of the tolerance geographical area 140, is relatively small so as to reduce a number of false or erroneous location determination or the user authentication. In either case, it should be understood that if the client device 110 is within the tolerance geographical area 140, the client device 110 may be authenticated. Otherwise, the client device 110 either is not authenticated or additional security challenges can be introduced.



FIG. 2 shows a high level block diagram of a system environment 200 suitable for implementing various embodiments of the present disclosure. In particular, the system environment 200 illustrates another approach to perform user authentication. The geographical location of the client device 110 may be determined multiple times by two or more host machines 120, 130 over a period of time. For example, at a first time, the location C1 of the client device 110A can be determined. At a second time, a request to access network resources associated with the user of the client device 110A can be received from a client device 110B. The client device 110B may be the same as the client device 110A or a different client device. In either case, the plurality of host machines 120, 130 may implement the above described process to determine a geographical location C2 of the client device 110B at the second time. Furthermore, a distance L4 between the previously determined location C1 (when the client device 110 has been successfully authenticated) and the new location C2 may be calculated. Then, a trip time for the client device 110A to travel from the location C1 to the location C2 can be evaluated. If the estimated time travel is about the same or less than a difference between the first and second times, it may be assumed that the client device 110B is the same device as the client device 110A, and, therefore, successfully authenticated. Otherwise, when the estimated time travel is longer than the difference between the first and second time instances, it is assumed that the user credentials are not authentic as a result of a malicious attempt to access user's network resources or services. In the latter case, authentication of the client device 110B fails or additional security challenges may be introduced.


According to an example, a user is located in Atlanta, Ga. He is the valid owner of the credentials that have been provided to one of the host machines 120, 130 for authentication. These credentials and geo-location identifier related to C1 along with a corresponding timestamp can be stored. Two hours later the same user credentials are presented from Moscow, Russia. The current time is evaluated against the last time the user has been authenticated with the credentials. This attempted authentication would be met with an adaptive authentication challenge or the authentication attempt would be rejected. The escalation or rejection of the authentication would occur because an average direct flight time between Atlanta and Moscow is about 10 hours which is much greater than the two hours since the last time the user has been authenticated. It would not be possible for someone to travel from Atlanta to Moscow within 2 hours.


In yet another approach, every time the client device 110 attempts authentication, HTTP (Hypertext Transfer Protocol) cookies may be acquired from a browser associated with the client device 110. The HTTP cookies may include metadata associated with one or more previous geographical locations (i.e., trusted historical data) where the client device 110 has already been successfully authenticated.


In some example embodiments, the metadata can also include a geo-location based on a network and/or mobile addresses such as Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) addresses.


The HTTP cookies may be analyzed, and in case they indicate that the client device 110 is within a predetermined distance from the previous geographical location, the client device 110 may be authenticated at this time. Otherwise, when the HTTP cookies are absent or contain misleading metadata, additional security challenges can be provided.


It should be clear that even when the client device 110 is successfully authenticated, the user may still be required to provide credentials for verification. Some examples of user credentials may include a login name, a password, a personal identification code, an email address, an answer to a security question, a one-time password (OTP), and so forth. Accordingly, in an example, if the client device 110 is authenticated based on principles disclosed herein, user login and password can be verified. Otherwise, if the client device 110 is not successfully authenticated, in addition to verifying the user login and password, an answer to a security question may be requested.



FIG. 3A shows a high level block diagram of an exemplary client device 110. The client device 110 may comprise a processor 305 and associated memory 310 which may store instructions and code implementable by the processor 305. Furthermore, the client device 110 may include one or more I/O units 315 (e.g., a touchscreen, keypad, display, etc.) and a communication unit 320 for sending and receiving data (e.g., via a wireless network).



FIG. 3B shows a high level block diagram of an exemplary host machine 120, 130. The host machine 120, 130 may include a processor 325 in association with a memory 330. The host machine 120, 130 may further include a database 335 storing network resources, user credentials, and so forth. The host machine 120, 130 may further include a communication unit 340 for sending and receiving data (e.g., via a wireless network).


The memory 330 may store instructions which can be implemented by the processor 325. Some instructions may be used in various dedicated modules (e.g., virtual software modules, modules combining software and hardware units, or modules combining firmware and dedicated logic units). In particular, there may be provided a distance measuring module 345 for measuring RTTs and distances between the host machine 120, 130 and the client device 110. There may also be provided an authentication module 350 configured to run authentication process as described herein and make authentication decisions in response to user authentication requests received from the client device 110.


As mentioned, the communication between the client device 110 and the host machine 120, 130 may be performed via a communications network (not shown). The communications network, generally speaking, can be a wireless or wire network, or a combination thereof. For example, the network may include one or more of the following: the Internet, local intranet, PAN (Personal Area Network), LAN (Local Area Network), WAN (Wide Area Network), MAN (Metropolitan Area Network), virtual private network (VPN), storage area network (SAN), frame relay connection, Advanced Intelligent Network (AIN) connection, synchronous optical network (SONET) connection, digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, Ethernet connection, ISDN (Integrated Services Digital Network) line, cable modem, ATM (Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. Furthermore, communications may also include links to any of a variety of wireless networks including, GPRS (General Packet Radio Service), GSM (Global System for Mobile Communication), CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access), cellular phone networks, GPS, CDPD (cellular digital packet data), RIM (Research in Motion, Limited) duplex paging network, Bluetooth radio, or an IEEE 802.11-based radio frequency network.



FIG. 4 is a process flow diagram showing a method 400 for user authentication according to an example embodiment. The method 400 may be performed by processing logic that may comprise hardware (e.g., decision making logic, dedicated logic, programmable logic, and microcode), software (such as software run on a general-purpose computer system or a dedicated machine), or a combination of both. In one example embodiment, the processing logic resides at the host machine 120, 130. In other words, the method 400 can be performed by various components discussed above with reference to FIGS. 3A and 3B.


The method 400 may commence at operation 410 with the client device 110 establishing network connections between the client device 110 and the first host machine 120 and between the client device 110 and a second host machine 130. At operation 420, one of the host machines 120, 130 may receive, from the client device 110, an authentication request (which may include user credentials and/or request to access network resources or online services).


At operation 430, the distance measuring module of the first host machine 120 may measure a first RTT between the first host machine 120 and the client device 110. At operation 440, the distance measuring module of the second host machine 130 may measure a second RTT between the second host machine 130 and the client device 110.


At operation 450, one of the host machines 120, 130 (or optionally a third party device) determines a current geographical location of the client device 110 based at least in part on the first RTT and the second RTT.


At operation 460, it may be determined whether the geographical location of the client device 110 is within the tolerance geographical area 140. If it is determined that the geographical location of the client device 110 is within the tolerance geographical area 140, at operation 470, the client device 110 is successfully authenticated. Otherwise, at operation 480, the client device 110 is not authenticated and, optionally, additional security challenges are provided to the user.



FIG. 5 is a process flow diagram showing a method 500 for user authentication according to another example embodiment. The method 500 may be performed by processing logic that may comprise hardware (e.g., decision making logic, dedicated logic, programmable logic, and microcode), software (such as software run on a general-purpose computer system or a dedicated machine), or a combination of both. In one example embodiment, the processing logic resides at the host machine 120, 130. In other words, the method 500 can be performed by various components discussed above with reference to FIGS. 3A and 3B.


The method 500 may commence at operation 510 with the client device 110 establishing network connections between the client device 110 and at least two host machines 120, 130. At operation 520, one of the host machines 120, 130 receives an authentication request from the client device 110.


At operation 530, at least one of the host machines 120, 130 acquires a first geo-identifier of the client device 110, which first geo-identifier is associated with a past geographical location C1 and a past timestamp, where the client device 110 has been successfully authenticated.


At operation 540, at least one of the host machines 120, 130 acquires a second geo-identifier of the client device 110. The second geo-identifier is associated with a current geographical location C2 of the client device 110 and a current timestamp.


At operation 550, at least one of the host machines 120, 130 estimates a trip time between the past geographical location C1 and the current geographical location C2 based at least in part on the past timestamp and the current timestamp and, optionally, based on the distance between locations C1 and C2.


At operation 560, at least one of the host machines 120, 130 makes an authenticating decision with respect to the client device 110 based at least in part on the estimation and in response to the authentication request. Specifically, when it is determined that the estimated trip time is less than a difference between the timestamps, the client device 110 may be authenticated. Otherwise, when it is determined that the estimated trip time is more than the difference between the timestamps, the client device 110 may not be authenticated.



FIG. 6 shows a diagrammatic representation of a computing device for a machine in the example electronic form of a computer system 600, within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein can be executed. In various example embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a PDA, a cellular telephone, a portable music player (e.g., a portable hard drive audio device, such as an Moving Picture Experts Group Audio Layer 3 (MP3) player), gaming pad, portable gaming console, in-vehicle computer, infotainment system, smart-home computer, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.


The example computer system 600 includes a processor or multiple processors 605 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), and a main memory 610 and a static memory 615, which communicate with each other via a bus 620. The computer system 600 can further include a video display unit 625 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 600 also includes at least one input device 630, such as an alphanumeric input device (e.g., a keyboard), a cursor control device (e.g., a mouse), a microphone, a digital camera, a video camera, and so forth. The computer system 600 also includes a disk drive unit 635, a signal generation device 640 (e.g., a speaker), and a network interface device 645.


The disk drive unit 635 includes a computer-readable medium 650, which stores one or more sets of instructions and data structures (e.g., instructions 655) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 655 can also reside, completely or at least partially, within the main memory 610 and/or within the processors 605 during execution thereof by the computer system 600. The main memory 610 and the processors 605 also constitute machine-readable media.


The instructions 655 can further be transmitted or received over the network 660 via the network interface device 645 utilizing any one of a number of well-known transfer protocols (e.g., Hyper Text Transfer Protocol (HTTP), CAN, Serial, and Modbus).


While the computer-readable medium 650 is shown in an example embodiment to be a single medium, the term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of the present application, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such a set of instructions. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media. Such media can also include, without limitation, hard disks, floppy disks, flash memory cards, digital video disks (DVDs), random access memory (RAM), read only memory (ROM), and the like.


The example embodiments described herein can be implemented in an operating environment comprising computer-executable instructions (e.g., software) installed on a computer, in hardware, or in a combination of software and hardware. The computer-executable instructions can be written in a computer programming language or can be embodied in firmware logic. If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and for interfaces to a variety of operating systems. Although not limited thereto, computer software programs for implementing the present method can be written in any number of suitable programming languages such as, for example, Hypertext Markup Language (HTML), Dynamic HTML, Extensible Markup Language (XML), Extensible Stylesheet Language (XSL), Document Style Semantics and Specification Language (DSSSL), Cascading Style Sheets (CSS), Synchronized Multimedia Integration Language (SMIL), Wireless Markup Language (WML), Java™, Jini™, C, C++, Perl, UNIX Shell, Visual Basic or Visual Basic Script, Virtual Reality Markup Language (VRML), ColdFusion™ or other compilers, assemblers, interpreters or other computer languages or platforms.


Thus, methods and systems for user authentication involving determining current geographical location of client device are disclosed. Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes can be made to these example embodiments without departing from the broader spirit and scope of the present application. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims
  • 1. A method for authentication of a client device, the method comprising: receiving, by at least one processor of a host machine, an authentication request from the client device to access a resource provided by the host machine, the host machine being located remotely with respect to the client device;determining, by the at least one processor of the host machine, a first distance between the host machine and the client device;based on the authentication request, instructing, by the at least one processor of the host machine, a further host machine of two or more host machines to determine a second distance between the further host machine and the client device, the further host machine providing data associated with the second distance to the host machine;establishing, by the at least one processor of the host machine, a current geographical location of the client device by a triangulation of the client device, the host machine, and the further host machine based on the first distance, the second distance, and a known distance between the host machine and the further host machine;establishing, by the at least one processor, a trusted tolerance geographical area based on at least a historical location area associated with the client device, the trusted tolerance geographical area being circumscribed by a plurality of points, the plurality of points being at varying respective distances from each of the first host machine and the second host machine;determining, by the at least one processor, whether the current geographical location of the client device is within the trusted tolerance geographical area; andauthenticating the client device, by the at least one processor, based on the determination that the current geographical location of the client device is within the trusted tolerance geographical area.
  • 2. The method of claim 1, wherein a location of the host machine and a location of the further host machine are known.
  • 3. The method of claim 2, wherein the triangulation includes: calculating trip times (RTTs) of test messages exchanged between the client device and the host machine and between the client device and the further host machine;determining the location of the client device by forming triangles between the client device, the host machine, and the further host machine.
  • 4. The method of claim 1, wherein the trusted tolerance geographical area is based on historical locations of the client device.
  • 5. The method of claim 4, wherein the authenticating the client device is further based on time stamps associated with the current geographical location and the historical locations of the client device.
  • 6. The method of claim 5, wherein the time stamps are used to establish a likelihood of moving the client device between a historical location and the current geographical location within a period of time.
  • 7. The method of claim 1, further comprising updating the trusted tolerance geographical area in response to the authentication of the client device.
  • 8. The method of claim 1, wherein the trusted tolerance geographical area is defined based on the historical locations.
  • 9. The method of claim 1, further comprising receiving metadata from the client device, wherein the metadata include an Internet Protocol version 4 (IPv4) address or an Internet Protocol version 6 (IPv6) address associated with the client device.
  • 10. The method of claim 1, further comprising receiving user credentials, the user credentials including a user login and a password.
  • 11. A system for authentication of a client device, the system comprising: a processor of a host machine, wherein the processor is a hardware processor configured to: receive an authentication request from the client device to access a resource provided by the host machine, the host machine being located remotely with respect to the client device;determine a first distance between the host machine and the client device;based on the authentication request, instruct a further host machine of two or more host machines to determine a second distance between the further host machine and the client device, the further host machine providing data associated with the second distance to the host machine;establish a current geographical location of the client device by a triangulation of the client device, the host machine, and the further host machine based on the first distance, the second distance, and a known distance between the host machine and the further host machine;establish a trusted tolerance geographical area based on at least a historical location area associated with the client device, the trusted tolerance geographical area being circumscribed by a plurality of points, the plurality of points being at varying respective distances from each of the first host machine and the second host machine;determine whether the current geographical location of the client device is within the trusted tolerance geographical area; andauthenticate the client device based on the determination that the current geographical location of the client device is within the trusted tolerance geographical area; anda database configured to store at least data associated with the client device.
  • 12. The system of claim 11, wherein a location of the host machine and a location of the further host machine are known.
  • 13. The system of claim 12, wherein the triangulation includes: calculating trip times (RTTs) of test messages exchanged between the client device and the host machine and between the client device and the further host machine;determining the location of the client device by forming triangles between the client device, the host machine and the further host machine.
  • 14. The system of claim 11, wherein the trusted tolerance geographical area is based on historical locations of the client device.
  • 15. The system of claim 14, wherein the authenticating the client device is further based on time stamps associated with the current geographical location and the historical locations of the client device.
  • 16. The system of claim 15, wherein the time stamps are used to establish a likelihood of moving the client device between a historical location and the current geographical location within a period of time.
  • 17. The system of claim 11, wherein the processor is further configured to update the trusted tolerance geographical area in response to the authentication of the client device.
  • 18. The system of claim 11, wherein the trusted tolerance geographical area is defined based on the historical locations.
  • 19. The system of claim 11, wherein the processor is further configured to receive metadata from the client device and wherein the metadata include an Internet Protocol version 4 (IPv4) address or Internet Protocol version 6 (IPv6) address associated with the client device.
  • 20. A system for authentication of a client device, the system comprising: a processor of a host machine of two or more host machines, wherein the processor is a hardware processor configured to: receive an authentication request from the client device to access a resource provided by the host machine, the host machine being located remotely with respect to the client device;determine a first distance between the host machine and the client device;based on the authentication request, instruct a further host machine of two or more host machines to determine a second distance between the further host machine and the client device, the further host machine providing data associated with the second distance to the host machine;establish a current geographical location of the client device by a triangulation of the client device, the host machine, and the further host machine based on the first distance, the second distance, and a known distance between the host machine and the further host machine, wherein the triangulation includes: calculating trip times (RTTs) of test messages exchanged between the client device and the host machine and the further host machine; anddetermining the location of the client device by forming triangles between the client device, the host machine, and the further host machine;establish a trusted tolerance geographical area based on at least a historical location area associated with the client device, the trusted tolerance geographical area being circumscribed by a plurality of points, the plurality of points being at varying respective distances from each of the first host machine and the second host machine;determine whether the current geographical location of the client device is within the trusted tolerance geographical area;authenticate the client device based on the determination that the current geographical location of the client device is within the trusted tolerance geographical area; andupdate the trusted tolerance geographical area in response to the authentication of the client device; anda database configured to store at least data associated with the client device.
CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation and claims the priority benefit of U.S. patent application Ser. No. 15/207,190 filed Jul. 11, 2016 and entitled “Location Determination for User Authentication”, which in turn is a continuation and claims the priority benefit of U.S. patent application Ser. No. 14/834,278 filed on Aug. 24, 2015 and entitled “Location Determination for User Authentication”, now U.S. Pat. No. 9,398,011 issued on Jul. 19, 2016, which in turn is a continuation and claims the priority benefit of U.S. patent application Ser. No. 13/925,745 filed on Jun. 24, 2013 and entitled “Location Determination for User Authentication”, now U.S. Pat. No. 9,122,853 issued on Sep. 1, 2015. The disclosures of the above-referenced patent applications are incorporated herein by reference in their entirety for all purposes.

US Referenced Citations (129)
Number Name Date Kind
5541994 Tomko et al. Jul 1996 A
5712912 Tomko et al. Jan 1998 A
5737420 Tomko et al. Apr 1998 A
5757916 MacDoran May 1998 A
5832091 Tomko et al. Nov 1998 A
5991408 Pearson et al. Nov 1999 A
6035398 Bjorn Mar 2000 A
6167517 Gilchrist et al. Dec 2000 A
6182146 Graham-Cumming Jan 2001 B1
6182221 Hsu et al. Jan 2001 B1
6219793 Li et al. Apr 2001 B1
6219794 Soutar et al. Apr 2001 B1
6310966 Dulude et al. Oct 2001 B1
6317834 Gennaro et al. Nov 2001 B1
6490624 Sampson et al. Dec 2002 B1
6507912 Matyas, Jr. et al. Jan 2003 B1
6714931 Papierniak et al. Mar 2004 B1
6748084 Gau et al. Jun 2004 B1
6901145 Bohannon et al. May 2005 B1
6950651 Seligmann Sep 2005 B2
7095852 Wack et al. Aug 2006 B2
7133916 Schunemann Nov 2006 B2
7155514 Milford Dec 2006 B1
7237267 Rayes et al. Jun 2007 B2
7360237 Engle et al. Apr 2008 B2
7376969 Njemanze et al. May 2008 B1
7480934 Chan et al. Jan 2009 B2
7484089 Kogen et al. Jan 2009 B1
7551574 Peden, II Jun 2009 B1
7552126 Chen et al. Jun 2009 B2
7613829 Alve Nov 2009 B2
7647635 Chen et al. Jan 2010 B2
7653633 Villella et al. Jan 2010 B2
7716378 Chen et al. May 2010 B2
7804956 Chang et al. Sep 2010 B2
7979585 Chen et al. Jul 2011 B2
8104091 Qin Jan 2012 B2
8122152 Chittenden et al. Feb 2012 B2
8151322 Chen et al. Apr 2012 B2
8341236 Ganesan Dec 2012 B1
8423676 Wang et al. Apr 2013 B2
8595383 Wang et al. Nov 2013 B2
8782751 Chen et al. Jul 2014 B2
8813180 Chen et al. Aug 2014 B1
8868765 Chen et al. Oct 2014 B1
8903986 Newstadt et al. Dec 2014 B1
9060003 Wang et al. Jun 2015 B2
9076027 Miura Jul 2015 B2
9122853 Thompson Sep 2015 B2
9202105 Wang et al. Dec 2015 B1
9294467 Wang et al. Mar 2016 B2
9344421 Chen et al. May 2016 B1
9398011 Thompson Jul 2016 B2
9825943 Thompson Nov 2017 B2
20010022558 Karr et al. Sep 2001 A1
20020095587 Doyle et al. Jul 2002 A1
20030023874 Prokupets et al. Jan 2003 A1
20030101349 Wang May 2003 A1
20030105859 Gamett et al. Jun 2003 A1
20030140232 De Lanauze Jul 2003 A1
20030140235 Immega et al. Jul 2003 A1
20030142122 Straut et al. Jul 2003 A1
20030191989 O'Sullivan Oct 2003 A1
20030219121 van Someren Nov 2003 A1
20040015243 Mercredi Jan 2004 A1
20040034784 Fedronic et al. Feb 2004 A1
20040049687 Orsini et al. Mar 2004 A1
20040059924 Soto et al. Mar 2004 A1
20040081173 Feather Apr 2004 A1
20040153553 Chotkowski et al. Aug 2004 A1
20040167912 Tsui et al. Aug 2004 A1
20040194114 Spiegel Sep 2004 A1
20040224664 Guo Nov 2004 A1
20040242200 Maeoka et al. Dec 2004 A1
20040254919 Giuseppini Dec 2004 A1
20040260651 Chan et al. Dec 2004 A1
20050009520 Herrero et al. Jan 2005 A1
20050010930 Vaught Jan 2005 A1
20050018618 Mualem et al. Jan 2005 A1
20050086502 Rayes et al. Apr 2005 A1
20050108518 Pandya May 2005 A1
20050114186 Heinrich May 2005 A1
20050114321 DeStefano et al. May 2005 A1
20050137981 Maes Jun 2005 A1
20050144480 Kim et al. Jun 2005 A1
20050182969 Ginter et al. Aug 2005 A1
20050204162 Rayes et al. Sep 2005 A1
20050283609 Langford Dec 2005 A1
20060069687 Cui et al. Mar 2006 A1
20060077926 Rune Apr 2006 A1
20060140452 Raynor et al. Jun 2006 A1
20060165226 Ernst et al. Jul 2006 A1
20060173977 Ho et al. Aug 2006 A1
20070011300 Hollebeek et al. Jan 2007 A1
20070032247 Shaffer et al. Feb 2007 A1
20070067441 Pomerantz Mar 2007 A1
20070067838 Bajko Mar 2007 A1
20070121560 Edge May 2007 A1
20070179986 Adam Aug 2007 A1
20070180101 Chen et al. Aug 2007 A1
20070195791 Bosch Aug 2007 A1
20070206746 Andreasson et al. Sep 2007 A1
20070283141 Pollutro et al. Dec 2007 A1
20070294209 Strub et al. Dec 2007 A1
20080002684 Kumazawa et al. Jan 2008 A1
20080080398 Yasuie et al. Apr 2008 A1
20080104276 Lahoti et al. May 2008 A1
20080130898 Holtmanns et al. Jun 2008 A1
20080229418 Chen et al. Sep 2008 A1
20080263626 Bainter et al. Oct 2008 A1
20090047952 Giaretta et al. Feb 2009 A1
20090213763 Dunsmore et al. Aug 2009 A1
20090292924 Johnson et al. Nov 2009 A1
20090299862 Fan et al. Dec 2009 A1
20100153544 Krassner et al. Jun 2010 A1
20100159955 Aerrabotu Jun 2010 A1
20110055913 Wong Mar 2011 A1
20110276685 de Waal Nov 2011 A1
20120084133 Ross et al. Apr 2012 A1
20120144203 Albisu Jun 2012 A1
20120246737 Paxton et al. Sep 2012 A1
20130036342 Deo et al. Feb 2013 A1
20140057596 Brill Feb 2014 A1
20140143149 Aissi May 2014 A1
20140229268 Clapp et al. Aug 2014 A1
20140347479 Givon Nov 2014 A1
20150012746 Kulkarni et al. Jan 2015 A1
20150141076 Libin May 2015 A1
20160182456 Wang et al. Jun 2016 A1
Foreign Referenced Citations (15)
Number Date Country
1449618 Oct 2003 CN
101361037 Feb 2009 CN
101375253 Feb 2009 CN
102098316 Jun 2011 CN
101361037 Jul 2011 CN
102123156 Jul 2011 CN
101375253 Sep 2011 CN
102123156 Nov 2014 CN
102098316 Sep 2015 CN
526643 Apr 2003 TW
I249314 Feb 2006 TW
WO2002021788 Mar 2002 WO
WO2008067013 Jun 2008 WO
WO2008070248 Jun 2008 WO
WO2014209660 Dec 2014 WO
Non-Patent Literature Citations (15)
Entry
Chang, et al., “Biometrics-Based Cryptographic Key Generation,” IEEE, International Conference on Multimedia and Expo, 2004, vol. 3, pp. 2203-2206.
Duda, et al., “Pattern Classification,” Second Edition, 2001, pp. 117-121.
How to Create a Rule in Outlook 2003, CreateRule-Outlook2003.doc Mar. 14, 2005 mad, pp. 3.
Jermyn, et al., “The Design and Analysis of Graphical Passwords,” USENIX Security Symposium, 1999, vol. 8, pp. 15.
Marandon, “How to Build a Web Widget (usingjQuery),” http://web.archive.org/web/20100623004301/http://alexmarandon.com/articles/web_widget_jquery/, 2010, pp. 7.
Monrose, et al., “Cryptographic Key Generation from Voice,” IEEE, Symposium on Security and Privacy, 2001, pp. 202-213.
Microsoft Windows XP—Filter Events in an Event Log, Jul. 2, 2004, http://web.archive.org/web/20040702070538/http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_filteringevents_how_ev.mspx.
Okada, et al., “An Optimal Orthonormal System for Discriminant Analysis,” Pattern Recognition, 1985, vol. 18 (2), pp. 139-144.
Shamir, “How to Share a Secret,” Communications of the ACM, 1979, vol. 22 (11), pp. 612-613.
Soutar, et al., “Biometric Encryption,” Department of Electrical and Computer Engineering, www.bioscrypt.com, 1999, pp. 1-28.
Search Report and Written Opinion dated Nov. 12, 2014 for PCT Application No. PCT/US2014/042588.
The Cable Guy: Windows 2000 Routing and Remote Access Service—Jun. 2001, Jul. 22, 2004, http://web.archive.org/web/20040722111534/http://microsoft.com/technet/community/columns/cableguy/cg0601.mspx.
WFLOGS, Dec. 15, 2002, http://web.archive.org/web/20021205151706/http://www.wallfire.org/wflogs/wflogs.8.html.
Zhang, et al., “Optimal Thresholding for Key Generation Based on Biometrics,” IEEE, International Conference on Image Processing, 2004, vol. 5, pp. 3451-3454.
Zhang, et al., Personal Authentication Based on Generalized Symmetric Max Minimal Distance in Subspace, IEEE, International Conference on Multimedia and Expo, 2003, 245-248.
Related Publications (1)
Number Date Country
20180097796 A1 Apr 2018 US
Continuations (3)
Number Date Country
Parent 15207190 Jul 2016 US
Child 15814653 US
Parent 14834278 Aug 2015 US
Child 15207190 US
Parent 13925745 Jun 2013 US
Child 14834278 US