Blog Home > Authentication Security > Risk Score Roulette – Contextual Authentication
Risk Score

Risk Score Roulette – Contextual Authentication

Risk Score

Risk Score Roulette

Do you dread applying for a car loan or refinancing your mortgage?  The determination of your “worthiness” made by some disembodied credit agency can add thousands or tens of thousands of dollars over the lifetime of a loan.  The three main credit bureaus in the United States purposely use proprietary credit score algorithms to minimize competition and provide lenders with an advantage over their customers.

The stakes for risk-based or contextual authentication into a web site aren’t quite as high nor does the calculation need to be so secretive or complex.  In contextual authentication, the server to which you are logging in looks at different aspects of your device and your connection to the server to determine the risk associated with the access request.  The resulting score (better thought of as a “credibility” score instead of a “risk” score) is calculated for that specific time and set of circumstances.  A higher risk results in a lower credibility score that requires you to provide more “proof” that you are who you claim to be.  For example, you could be required to enter a username, password, and one-time passcode sent to your cell phone.  A very low credibility score could even result in the server blocking your access completely!


Configurations and specifics typically differ for each organization’s risk policy, but here are some of the standard factors in play:

  • IP Address/Network – The IP address of your client is something that cannot be easily spoofed or falsified.  Rather than use a “black list” approach where certain blocks of addresses are deemed “bad,” a white list is much more manageable and assigns a positive credibility score to IPs controlled by the organization.  The controlled confines of a LAN are a very different environment from an Internet café.  The other caveat with this type of information is that proxy servers could be used to mask the IP of the end-user’s actual device.  Some vendors can utilize client-side apps to determine what “type” of network connection the device is using.  It can actually detect encryption strengths for Wi-Fi connections and treat those using outdated or weak encryption as a higher risk.
  • Geolocation – There are a few ways to get a user’s location.  IP-based geolocation is fairly easy to implement, but does not have a high degree of accuracy.  It may only be reliable to determine which country the user is in!  HTML 5 now has built-in support for Geolocation and is supported by all major browsers.  When used by “honest” users, this is generally more accurate since it could use a mobile phone’s internal GPS or the wireless access points available around a workstation. Due to privacy concerns, this information is only provided if the user allows it.  The specification specifically states that the data may not return the actual location and some browsers even allow you to provide a specific latitude and longitude to requesting servers, so authentication decisions for sensitive applications should *not* rely on this type of data.
  • Device Information – Certain information is available from each HTTP request your web browser makes.  The browser vendor and version (aka “User-Agent”) is typically present as are capabilities or supported file types or fonts.  Some device “fingerprinting” can be done using this information, but all of this data can be completely spoofed.  Some client-side apps can integrate directly into your device or browser, allowing it to get authoritative information and securely deliver it to the web server.
  • Cookies – This can be considered a subset of the “device information” type but one that is a little more controllable.  If the user chooses to “remember” their device, the server can generate an opaque, random identifier and set it as a persistent cookie in the user’s browser.  The lifetime of this cookie is typically configurable.  The presence or absence of this cookie can be used to establish whether the device has previously been used which can boost credibility.  As long as HTTPS is used to communicate with the authentication server, then the cookie should be relatively safe from replay attacks.
  • Time of day – Another factor that cannot be spoofed is the current time.  Maybe a defined time window represents a slight increase in credibility.  Any access outside this Monday through Friday time is deemed more risky.  Historical usage patterns can be established for the user as well to help weight this factor more appropriately.


There is no need to feel bad or self-conscious about a low credibility score!  System administrators have the above factors at their disposal to create their own algorithm, but most tend to utilize more authoritative data like IP address to determine if a user is on or off the LAN.  The policy could be as simple as that in determining whether your login is simple or more complex but their main goal should be to keep it simple for authorized users.  Relax though; even the most stringent login requirements will never approach the experience of applying for a home mortgage!


Can you recall the last time you were required to provide more information during a login?  Perhaps it was the first time you logged into your online banking from a new device?  This is just one example in a field that will be increasingly prevalent in the months and years to come.

Please follow and like us:
Gregg Browinski

Author: Gregg Browinski

Gregg, PistolStar’s Chief Technology Officer, oversees PistolStar’s product development and technical support. Prior to joining the company in 2001, he received extensive experience as a developer at IBM Lotus and Iris Associates. Gregg has served as the lead architect and developer for PistolStar’s Password Power suite of authentication solutions. He is responsible for the product’s technical success and the recognition it has received through award nominations.

Comments are closed.

Main menu