Why Take Chances? An Approach to Risk Based Authentication


A few years ago, the security industry made (another) brilliant marketing move. When the forces reluctant to multi-factor authentication threw what they thought would be their trump card, “But authentication creates friction!”, some leading vendors, instead of polishing their products to improve the user experience, just embraced the argument: “Ok, so let’s sell MORE multi-factor authentication, modules, and integration, and let’s AVOID using it”. And it worked! The market paid for additional modules (risk scoring) to ensure that the good guys would not have to use their already paid-for authentication equipment.

To be fair, there’s more than that to risk-based authentication when used properly. But there are also inherent limits, so you don’t want to use it without understanding what it’s good for. Let’s take a closer look.

Risk-based authentication, zones of risk

The main idea behind risk-based authentication is to enforce an easier or even implicit user authentication unless there’s a reason to think that it might not be the right user or if she’s doing something unusual. There are conceptually 3 risk ‘zones’: a white zone, where only basic authentication is required; a dark zone, where the transaction or access is simply denied; and a grey zone in-between, where a stronger authentication is enforced (color choices are mine).

Implementing risk-based authentication therefore requires to define and to choose your risk criteria, your scoring method, and most importantly, your thresholds – the boundaries between the risk zones. This can be tricky.

There are 2 sorts of ‘risks’ you really want to avoid with risk-based authentication: that is doesn’t work, and that it works too well. The false positives and the false negatives. Putting the bad guys in the good guys’ category – therefore being hit by fraud or attacks. And putting the good guys in the bad, or at least questionable guys’ category – therefore potentially adding a lot of friction to a transaction. To avoid this equally unpleasant situations, you must be able to find criteria that clearly pull apart the (hopefully few) bad guys from the good guys.

Policies, habits, and devices

What are the usual criteria you can try for your business? Let’s divide them in several categories (category names are mine too).

Policies are criteria such as time and date, origin network (as defined by the IP address that the user is accessing from), location, ‘velocity’ (the speed a user would have traveled between 2 consecutive requests – very few users travel, say, between Brazil and Russia in less than 15 hours), etc. Policies are a large-mesh net: it only catches big fishes – very awkward attackers – but it won’t hurt the good guys. There’s no reason not to implement these criteria, but don’t expect too much from them. You won’t make the authentication process easier for your legitimate users based on these policies.

Habits are more complex to use, and they require (much) more data about your specific business and the users. It could be the average purchase of a user (with 2 or 3 standard deviation), the frequency of a wire transfer… These criteria have more relevance for transactions in a B2C or B2B context, less for authentication to IT systems. Habits are like a reference point for a given user. You want to make things easier as long as this user stays close enough to the reference. With habits, you’re likely to remove a substantial level of friction and therefore to reap the benefits of risk-based authentication. But for that you need to be able to identify relevant patterns – e.g. this user sends 2000$ every month to the same beneficiary, his daughter.  That user shops in your online grocery every other week for an average amount of 150 Euros. Etc. If you can’t find these patterns, you should probably avoid this kind of criteria.

Devices are another larger-mesh net. The way it’s usually used is that some vendors maintain large and constantly updated databases of devices that have been reported to be associated with fraudulent transactions. The device fingerprints (obviously not just cookies) are usually not fine enough to prevent serious fraudsters from bypassing the mechanism, but it might be worth to give it a try if you’re in e-commerce and experience high fraud.

Can a device fingerprint be used as an authentication factor? From a security and risk point of view, the answer is rather no (it would need a longer development than this post). From a regulatory & compliance point of view, the answer is increasingly also no (fingerprint is not considered as “strong authentication” when it is mandated). Besides, especially in an Enterprise context where many users might have exactly the same type of device, device fingerprinting will be of little help. Overall, device fingerprinting has more to do with e-commerce fraud reduction than with risk-based authentication.

The Risk-Based Authentication ecosystem

Whom should you ask what? It’s not about naming vendors but about identifying the kind of technologies and providers you need in order to implement risk-based authentication, depending on your specific situation and goals.

Scoring based on habits requires 1/ analytics, 2/ large enough amounts of data, 3/ that you operate in the right market for the analytics to be ultimately relevant. If you meet conditions 2 & 3, look for vendors providing analytics.

Policies can be enforced by multi-factor authentication vendors such as inWebo. Access requests can be denied, or trigger a step-up, if parameters lie outside predefined boundaries. The second factor (the one involving the user) can dynamically be omitted for a subsequent request in the same context. Etc. You don’t need analytics and scoring engines for this, this is traditional authentication business.

If you operate in e-commerce, you might want to use the device fingerprint databases previously mentioned. In other contexts, especially access management in an Enterprise context, using the devices as an authentication factor won’t help much. This is not where you want to take chances.

Why take chances?

We’ve seen that there are fraud-prevention techniques out there, but they answer a different question. We’ve also seen that with analytics (and faith), you might reduce transaction friction in some B2C contexts. So, overall, and especially in an Enterprise context, it doesn’t seem that risk-based authentication answers the question for which it was originally proposed. It doesn’t hurt either, except your budget, maybe.

Coming back to the initial purpose of risk-based authentication, how do you really reduce authentication friction for your users? Should you take chances, i.e. reduce security and increase risks for that? Notwithstanding the side benefits of risk-based authentication, the way to improve security adoption isn’t by asking organizations to take more risks, but by making the solutions easier to implement and more convenient to use. If security solutions don’t create friction, there’s no reason to bypass them in the first place. There’s no reason either to increase your risks.

You’re not requesting anything from visitors so that they can securely transact on your website.  You purchase a good-enough SSL certificate, and this is not even something you mention – at least no longer. This is exactly the same approach that inWebo has developed for secure multi-factor or second-factor authentication. So that you don’t have to take chances if you want to reduce friction.

Written by inWebo