User authentication is an important aspect of providing security for various computer systems, especially services for consumers on a publicly accessible computer system such as the Internet. Such services include, but are not limited to, electronic mail, remote storage, social networking applications and the like,
In addition to conventional user name and password combinations, some services include other authentication measures. For example, a sequence of secret questions and answers can be presented to the user. As another example, a device identifier, such as a serial number for the device itself, or for one or more components of the device, or other identifier such as a media access control (MAC) address, can be used to authenticate the user,
The location of the user also can be used to further verify or question the authenticity of the user. This location can be derived from computer network addresses, such as the internet protocol (IP) address used by the computer, from global position system (GPS) information and the like. For example, a system can maintain, for each user, a list of familiar locations from which the user is known to access the system. If the user attempts to access the system from an unfamiliar location, the user can be prompted for more information before the user is authenticated and access to the system is permitted.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description, This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
An authentication process receives information identifying a user, a device used by the user to access a service and a location in which the device is being used. That authentication process determines whether the location is among a set of familiar locations stored about the user for the service being accessed. If the location is not among a set of familiar locations stored for the user, for example if the user is traveling and is in an unfamiliar location, then the user is not authenticated. For example, the user can be prompted for additional authentication information, or access can be denied, or a security event can be signaled.
However, a desirable user experience can be obtained by using information about any existing relationship between the device and the service which was established at a prior familiar location. An example of such a relationship is a synchronization relationship where the service maintains synchronization with a device, So, instead of challenging or requiring further authentication information from a user whose location is unfamiliar, the authentication process determines whether the device has a relationship established with the service being accessed.
If the device has a relationship established with the service being accessed, then the set of familiar locations is updated to include the location in which the device is being used. Thus, when the device is moved to anew location, the relationship indicates the device is trusted by the service, and the location information can be updated.
On the other hand, if the device does not have a relationship established with the service being accessed, and if the location is not among a set of familiar locations stored for the user, then access to the service can be denied, or the user can be prompted for additional information, or a security event can be signaled,
Additional devices used by the user in the new location can benefit from a first device having a relationship with the service. For example, if the user accesses the service with a second device in the new location after accessing the service with the first device, the set of familiar locations is updated due to the relationship of the first device. Thus, access to the service on the second device will not be denied because of the new location. Additionally, unsuccessful attempts to establish a relationship with new devices and/or new locations can be used to signal security events.
In the following description, reference is made to the accompanying drawings which form a part hereof, and in which are shown, by way of illustration, specific example implementations of this technique. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the disclosure.
The following section provides an example operating environment in which a service using location-based account protection is augmented by using information about trusted devices. A trusted device is a device that has a predetermined relationship with the service, such as a synchronization relationship which synchronizes the device with the service. The example below in
Referring to
Such applications or services also generally allow a user to access the service through a conventional web browser 108 or similar application on another computing device 110, such as a personal computer, whether desktop, laptop or tablet computer, or smart phone.
The service typically has an authentication process 112 that presents a user interface to allow the user to login. When the user logs in, the authentication process receives information 114 about the user, such as a user name and password. The authentication process also can receive information about the device and the user's location.
The information about the device can include, for example, a device identifier, such as a serial number for the device itself, or for one or more components of the device, or other identifier such as a media access control (MAC) address, can be used to authenticate the user
The information about the location can be derived from computer network addresses, such as the internet protocol (IP) address used by the computer, from global position system (GPS) information and the like.
The authentication process 112 uses location information as an additional factor in deciding whether to authorize access to an account. In particular, for each user, the authentication process maintains a database 116 that includes a set of familiar locations of the user from which the user has previously accessed the service 100. If a user attempts to access the service 100 from a location not in the set of familiar locations, then the authentication process 112 can prompt the user for additional authentication data, as indicated at 118.
However, if the user device 102 has a relationship with the service 100, then the set of familiar locations can be updated to include the current location of the user device 102. Thus, instead of prompting the user for additional authentication data, the authentication process 112 accesses the information about relationships between the service and devices, such as synchronization relationships, and updates the set of locations if such a relationship exists.
Updating the familiar location information for a user based on a relationship for one device is particularly useful if the user has two or more devices. For example, a user may be traveling with a smart phone and a laptop computer. The smart phone is set to synchronize electronic mail, calendar and contact information with a user's account. The user checks into a hotel and accesses the internet with a laptop computer and attempts to access the user's account. Because of the synchronization relationship with the smart phone and the account, the user's location at the hotel is added to the list of familiar locations for that user. Thus, when the user accesses the account with the laptop computer which does not have a relationship with the service providing the user's account, access neither involves prompting the user for further information nor is denied due to the new location of the user.
In addition, other security measures can be implemented using the relationship information. For example, if a user attempts to establish a synchronization relationship from a new location, and is unsuccessful, a security event can be signaled. The user or system administrator could be notified of the attempt. If successful, the new location can be added to familiar locations of the user.
Given this context, an example implementation of such a system will be described in more detail in connection with
Referring now to
Referring now to
The authentication process for a service receives 300 into memory information identifying a user, a first device, such as a smart phone, used by the user to access the service, and a location in which the device is being used. The authentication process determines 302 whether the first device has a relationship established with the service being accessed. If the first device has a relationship established with the service being accessed (which is the case in this example that shows how the relationship between the first device and the service benefits the second device), then the authentication process updates 304 the set of familiar locations for the user to include the location in which the first device is being used.
Subsequently, the user attempts to access the service with a second device, such as a laptop or tablet computer, in the same location. The authentication process for the service receives 306 into memory information identifying a user, a device used by the user to access the service, and a location in which the device is being used. The authentication process then determines 308 whether the location is among a set of familiar locations stored about the user for the service being accessed by the user. Assuming that the location update due to the activity of with the first device is successful, the new location is in the database, and access to the service will not be denied 310 due to the new location. It is possible to allow or disallow access at a new location even if the new location is in the database by further considering the type of request being made by the device. If the location update was not successful, access will not be authorized 312 due to the new location, and the user may be prompted for additional information.
In
The authentication process receives 400 information identifying a user, a device and a location in which the device is being used. Next, the authentication process receives 402 a request from the device to establish a synchronization relationship with the service being accessed. If the attempt is unsuccessful as determined at 402, it is next determined 404 whether the location is among a set of familiar locations stored about the user for a service being accessed by the user through the device. If the location is unfamiliar and the synchronization attempt is unsuccessful, then a security event can be signaled 406, such as by notifying the user and/or a system administrator. If the location is familiar, then authorization based on location can be allowed (as noted at 412), however, the system might take other authorization steps before allowing access to the service.
If the synchronization attempt is successful, then it is determined 408 whether the location is among the set of familiar locations. If the second device is successful in establishing anew synchronization relationship from a location that is not among the set of familiar locations, then the set of familiar locations is updated 410 to include the location of the second device. With the device being in a familiar location, the access to the service based on location can be authorized 412.
With this use of a relationship, such as a synchronization relationship, to infer that a device is trusted, the location in which the device is being used can be considered trusted in a system that uses location-based authentication. Such usage provides a desirable user experience by not denying access when a user is in a new location with a trusted device. Additionally, the combination of location information and attempts at establishing a relationship can be used to signal security events to a user or system administrator.
Having now described an example implementation, a computing environment in which such a system is designed to operate will now be described. The following description is intended to provide a brief, general description of a suitable computing environment in which this system can be implemented. The system can be implemented with numerous general purpose or special purpose computing hardware configurations. Examples of well known computing devices that may be suitable include, but are not limited to, personal computers, server computers, hand-held or laptop devices (for example, media players, notebook computers, cellular phones, personal data assistants, voice recorders), multiprocessor systems, microprocessor-based systems, set top boxes, game consoles, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
With reference to
Computing machine 500 may also contain communications connection(s) 512 that allow the device to communicate with other devices. Communications connection(s) 512 is an example of communication media. Communication media typically carries computer program instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal, thereby changing the configuration or state of the receiving device of the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
Computing machine 500 may have various input device(s) 514 such as a keyboard, mouse, pen, camera, touch input device, and so on. Output device(s) 516 such as a display, speakers, a printer, and so on may also be included. All of these devices are well known in the art and need not be discussed at length here.
The input and output devices can be part of a natural user interface (NUI). NUI may be defined as any interface technology that enables a user to interact with a device in a “natural” manner, free from artificial constraints imposed by input devices such as mice, keyboards, remote controls, and the like.
Examples of NUI methods include those relying on speech recognition, touch and stylus recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, and machine intelligence. Example categories of NUI technologies include, but are not limited to, touch sensitive displays, voice and speech recognition, intention and goal understanding, motion gesture detection using depth cameras (such as stereoscopic camera systems, infrared camera systems, RGB camera systems and combinations of these), motion gesture detection using accelerometers, gyroscopes, facial recognition, 3D displays, head, eye, and gaze tracking, immersive augmented reality and virtual reality systems, all of which provide a more natural interface, as well as technologies for sensing brain activity using electric field sensing electrodes (EEG and related methods).
Such a system can be implemented in the general context of software, including computer-executable instructions and/or computer-interpreted instructions, such as program modules, being processed by a computing machine. Generally, program modules include routines, programs, objects, components, data structures, and so on, that, when processed by a processing unit, instruct the processing unit to perform particular tasks or implement particular abstract data types. This system may be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Alternatively, or in addition, the functionally described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc,
The terms “article of manufacture”, “process”, “machine” and “composition of matter” in the preambles of the appended claims are intended to limit the claims to subject matter deemed to fall within the scope of patentable subject matter defined by the use of these terms in 35 U.S.C. §101.
Any or all of the aforementioned alternate embodiments described herein may be used in any combination desired to form additional hybrid embodiments. It should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific implementations described above. The specific implementations described above are disclosed as examples only.
Number | Name | Date | Kind |
---|---|---|---|
6397065 | Huusko et al. | May 2002 | B1 |
7203753 | Yeager et al. | Apr 2007 | B2 |
7480801 | Euchner | Jan 2009 | B2 |
7668123 | Scott et al. | Feb 2010 | B1 |
7836487 | Walker Pina | Nov 2010 | B2 |
8156539 | Nelson | Apr 2012 | B1 |
8176077 | Stevens | May 2012 | B2 |
8402512 | Tam et al. | Mar 2013 | B2 |
8447332 | Weinreich | May 2013 | B2 |
8489071 | Mechaley, Jr. | Jul 2013 | B2 |
8561142 | Sobel | Oct 2013 | B1 |
8578454 | Grim | Nov 2013 | B2 |
8589541 | Raleigh et al. | Nov 2013 | B2 |
8601268 | Judell | Dec 2013 | B2 |
8824372 | Hoggan | Sep 2014 | B2 |
8831563 | Martell et al. | Sep 2014 | B2 |
8831570 | Garskof | Sep 2014 | B2 |
8914302 | Rose | Dec 2014 | B2 |
9329877 | Donaldson | May 2016 | B2 |
20070101438 | Govindarajan | May 2007 | A1 |
20080172715 | Geiger et al. | Jul 2008 | A1 |
20090300168 | Guo et al. | Dec 2009 | A1 |
20100024017 | Ashfield et al. | Jan 2010 | A1 |
20100199086 | Kuang et al. | Aug 2010 | A1 |
20100199338 | Craddock et al. | Aug 2010 | A1 |
20100211997 | McGeehan et al. | Aug 2010 | A1 |
20110247055 | Guo et al. | Oct 2011 | A1 |
20110252132 | Wetzer et al. | Oct 2011 | A1 |
20110296513 | Kasad | Dec 2011 | A1 |
20120030771 | Pierson et al. | Feb 2012 | A1 |
20120042160 | Nakhjiri et al. | Feb 2012 | A1 |
20120167188 | Poornachandran et al. | Jun 2012 | A1 |
20120173869 | Stinson, III | Jul 2012 | A1 |
20120203568 | Francis | Aug 2012 | A1 |
20120216298 | Jaudon et al. | Aug 2012 | A1 |
20130014212 | Cohen | Jan 2013 | A1 |
20130031001 | Frechette | Jan 2013 | A1 |
20130036459 | Liberman | Feb 2013 | A1 |
20130111554 | Sposato et al. | May 2013 | A1 |
20130191887 | Davis | Jul 2013 | A1 |
20130308618 | Panneerselvam | Nov 2013 | A1 |
Entry |
---|
Ron Shacham, Architecture for location-based service mobility using the SIP event Model, Mar. 2004, Psu.Edu, vol. 1, pp. 1-6. |
Sharp, et al., “Enhancing Web Browsing Security on Public Terminals Using Mobile Composition”, Retrieved at <<http://anil.recoil.org/papers/2008-mobisys-splittrust.pdf>>, In Proceeding MobiSys '08 Proceedings of the 6th international conference on Mobile systems, applications, and services, Retrieved Date: May 30, 2012, pp. 12. |
Oprea, et al., “Securing a Remote Terminal Application with a Mobile Trusted Device”, Retrieved at <<http://www.rsa.com/rsalabs/staff/bios/aoprea/publications/acsac.pdf/>>,In Proceeding ACSAC '04 Proceedings of the 20th Annual Computer Security Applications Conference, May 30, 2012, pp. 10. |
“International Search Report & Written Opinion for PCT Patent Application No. PCT/US2013/060405”, Mailed Date: Nov. 21, 2013 , Filed Date: Sep. 18, 2013, 9 Pages. |
Number | Date | Country | |
---|---|---|---|
20140096189 A1 | Apr 2014 | US |