Understanding Various Identity Types

While using the Internet, an individual establishes an online identity that represents certain elements or characteristics of that person. This form of identity can—and often will—differ across multiple sites and leads to a fragmentation that we can group into different areas based on a website’s use case.

In this section, we introduce three types of identity that we will then discuss in detail: social identity, concrete identity, and thin identity. These types of identity often overlap and can share the same attributes, as shown in Figure 3-1.

These three identity types can be considered federated identities and are applied through technologies such as SAML, OpenID, OAuth, and tokenization. Often applied through single sign-on—known as SSO—Federated Identity Management (FIM or FIdM) is the practice of using a set of identity attributes across multiple systems or organizations. While SSO is a way of using the same credentials across multiple sites and applications, FIM shifts the verification of credentials toward the identity provider.

Figure 3-1. Overlapping identities

Enhancing User Experience by Utilizing Identity

User experience studies carried out by the Nielsen Norman Group show that login doesn’t necessarily have to be the first point of contact for users and often harms the conversion process of turning visitors into users by forcing them to register or log in.³ The current sentiment in user-experience research is that a preview of offered functionality is desirable and helps people decide whether they want to commit to an application.

Leveraging existing profiles, such as a user’s social identity, can help ease the way after the user does decide to register by prepopulating profile information and therefore lowering the amount of information the user has to type in manually.

Introducing Trust Zones

The devices we use nowadays come pre-equipped with a variety of sensors that can gather information about the user’s environment. GPS, WiFi, cameras, accelerometers, gyroscopes, light, and many other sensors are used to build up profiles and identify the user accordingly. Combining this concept with the concept of identity, we can not only identify users, but also build up trust zones (Figure 3-2).

Figure 3-2. Trust zones

Trust zones allow us to scale our security based on users’ behavior, environment, and our ability to determine whether they are who they say they are. In essence, we are trying to create a digital fingerprint for the user, from any data that might be available and unique for the given user, such as their browser configuration, hardware, devices, location, etc.

If we can guarantee a user is at home, based on the current GPS coordinates and the WiFi used to connect to the Internet, trust zones can offer the user a way to waive certain steps within authorization and authentication of web and mobile applications. Google introduced this concept for Android as a feature known as Smart Lock.⁴ When a user wears his Android Wear device, the phone can be set up to automatically unlock whenever a Bluetooth connection between the wearable device and the user’s phone is established.⁵ Other supported factors for Smart Lock are the user’s location, face recognition, and on-body detection, which is a feature that relies on the device’s accelerometer. Chapter 5 covers these alternate ways of user authentication more deeply.

Realistically, we’re trying to remove hurdles during the application experience for the users. If we can obtain enough bits of information about them from the system and devices that they are using to determine that they are almost certainly who they say they are, and they are in a trusted location, is it necessary to challenge them when changing account information, or ask them to provide login details during a checkout process instead of providing a one-click checkout experience?

These are the types of things that we can do when we have a strong certainty that users are who they are purporting to be.

Let’s take this conversation into a practical look at this technology, starting with the browser.

Browser Fingerprinting

One of our main goals as application and web developers is to make the experience of our users as secure and as convenient as possible. With the concept of trust zones understood, you can start to see how many of the security measures that we can put in place may occur without burdening the user for more information.

One of the methods that can be employed is browser fingerprinting. This process uses unique characteristics about the browser that the user is using, such as headers, fonts, etc., to determine a second factor of authentication based on the user’s browser.

Back in May of 2010, The Electronic Frontier Foundation (EFF) published a report from an experiment it was running on browser fingerprinting, called Panopticlick. From this study, some interesting results were derived from the browsers that were tested during the first 1 million visits to the Panopticlick site.⁶

• 84% of browsers tested had a unique configuration.

• Among browsers that had Flash or Java installed, 94% were unique.

• Only 1% had fingerprints that were seen more than twice.

These are obviously not definitive numbers to determine to a near certainty the browser uniqueness of each user, but the numbers are significant enough to be able to easily use these types of tests as a second factor of authentication for our users. When we are able to find a unique browser configuration, we have a high likelihood (99%) of determining that the browser is unique and attributable to that individual. When using this, coupled with additional techniques that we will explore in later sections, we can predict with a high degree of certainty that users are who they say they are. When we have that determination, along with the login mechanisms that the user has used (such as a username/password), then we are able to maintain a high level of confidence to create our trust zones.

These tests used the concept of bits of entropy to determine the fingerprint of a browser. From its subset of tests, the EFF noticed that the distribution of entropy observed on a tested browser is typically around 18.1 bits. This means that if a browser was chosen at random, at best we would expect that only 1 in 286,777 other browsers would share the same fingerprint.

In addition to making things easier for the user through these trust zones, there’s another benefit to having this information tracked. If we are processing payments for our users, inevitably there will be some disputes over a payment and who may have made it. Being able to provide information such as these digital fingerprints during dispute resolution can help to provide favorable results during the process.

var agent = navigator.userAgent;

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

var offset = new Date().getTimezoneOffset() / 60;

var offset = (new Date().getTimezoneOffset() / 60) * -1;

var width = window.screen.width;
var height = window.screen.height;

//get plugin information
var plugins = navigator.plugins;
for (var i = 0; i < plugins.length; i++){
   console.log(plugins[i].name);
}

Widevine Content Decryption Module
Chrome PDF Viewer
Shockwave Flash
Native Client

Location-Based Tracking

Other than browser fingerprinting, another method that we can use for building trust zones for users is to use their physical location.

Here’s how this can be valuable. Let’s say that we have an ecommerce store where the user has filled out her shipping address during sign-up or a previous purchase. We have that address stored to make it easier for the user to check out, and that has become a trusted home location. If we could determine the physical location of the person attempting to use the site while purporting to be the user, we could match that against the address on file. If those two addresses match, we can use that as a trusted point, and potentially lift the need to have the user confirm her login information before checkout.

Let’s look at a simple JavaScript-based approach to gathering the latitude and longitude of the user, using the navigator object. First, let’s see what the current support for geolocation is within modern browsers (Figure 3-3).

Figure 3-3. Current geolocation browser support

Looking at the support, we have good overall coverage in most modern browsers. Now let’s see how to set up a simple example of this:

//on success handler
function success(position){
    console.log('lat: ' + position.coords.latitude);
    console.log('lon: ' + position.coords.longitude);
}

//error handler
function failure(err){
    console.log(err);
}

//check geolocation browser availability and capture coordinates
if ('geolocation' in navigator){
    navigator.geolocation.getCurrentPosition(success, failure, {timeout:10000});
} else {
    console.log('geolocation is not available');
}

We start out by defining two handler functions, one for success and the other for handling errors. Within the success function we will be passed position data, from which we can then extract coordinate information. Within the error handler, we are simply logging out the errors that may be produced. One potential error may be caused by the user not allowing the website to capture his geolocation:

PositionError {}
 - code: 1
 - message: "User denied Geolocation"

With those in place, we check at the bottom of the sample to see whether geolocation is available within the navigator object. If it is, we call navigator.geolocation.getCurrentPosition(…), passing in the success function, error function, and the options, which contain a time-out of 10 seconds.

When run in a browser, the user will be asked to confirm his geolocation data (Figure 3-4).

Figure 3-4. Requesting use of geolocation data

Once allowed, we will be able to extract the latitude and longitude, compare those to the address we have stored on file, and see whether the user is in a trusted zone. Creating a geofence of an appropriate range (range from the root address that the coordinates are within) will allow us to handle cases of the user being within close proximity to his home location.

Device Fingerprinting (Phone/Tablet)

As you can see, a multitude of data points can be gathered to help us determine whether users are who they say they are, without impacting their experience. This allows us to continue to make things easier by not having to request additional information from them for security.

Another method is to use the hardware fingerprint of the devices that are being used by the person using our site or service. Users will typically use a range of devices (phones, tablets, etc.) for interacting with your applications. These devices, when used over time, can become trusted sources to help determine whether the user is on a trusted device.

Let’s take a look at a simple method for capturing this type of information from an Android application. Build information is available that enable us to obtain information about the device that the user is using.⁸

Some of that information can be pulled like so:

//Build Info: http://developer.android.com/reference/android/os/Build.html

System.getProperty("os.version"); //os version
android.os.Build.DEVICE           //device
android.os.Build.MODEL            //model
android.os.Build.VERSION.SDK_INT  //sdk version of the framework
android.os.Build.SERIAL           //hardware serial number, if available
.
.
.

We can obtain information such as the OS version, device, and model. This can all go toward building a framework of trusted devices, and allowing a user to bypass the need for additional levels of security, should they be required.

Device Fingerprinting (Bluetooth Paired Devices)

Today our phones are not the only connected devices we have. We may have our phones connected to a smart watch, a car, or other hardware around us. These devices, much like the phone, can be used as a hardware fingerprint to help determine whether users are who they say they are. If we can find devices that are typically connected to the phone, the trust score would increase.

Let’s look at an example of how this would work within an Android application, if we wanted to fetch all of the Bluetooth devices that are connected to a phone:

//fetch all bonded bluetooth devices
Set<BluetoothDevice> pairedDevices = mBluetoothAdapter.getBondedDevices();

//if devices found, fetch name and MAC address for each
if (pairedDevices.size() > 0){
    for (BluetoothDevice device : pairedDevices){
        //Device Name - device.getName()
        //Device MAC address - device.getAddress()
    }
}

We start by calling getBondedDevices() to capture any devices that are currently attached to the phone. We then loop through the devices found, and can fetch some basic information about them:

Device name

Readable name of the device, obtained through device.getName()

MAC address

The physical address of the device, obtained through device.getAddress()

Implementing Identity

Now that you have built up an understanding of identity types and the concepts behind trust zones, in Chapter 4 we will take on a basic implementation of OAuth 2.0 and OpenID—the driving technologies behind identity. Please note that the identity sector is currently evolving, and new standards, such as FIDO, are on the horizon. These new technologies will be part of Chapter 5’s focus.