Lots of new buzzwords appear every day in the identity management and anomaly detection space, one of which is ‘contextual authentication’ – that’s another way to describe what we do here at ThisData.
The need to improve password security
When an organization seeks to improve password security while maintaining usability, there are generally two ways that they tend to go about it:
- Better password policies. They ask users to create stronger passwords. While this sounds easy and it would make a huge difference, it’s unfortunately doomed from the get-go due to a lack of enthusiasm from users to participate in the way that they would need to. Also because the harder the password, the more users tend to write them down so they remember it – oh oh!
- Enforce Two-Factor Authentication. While enforcing 2FA is a great option, the known problems here are poor user adoption (because it’s annoying and interrupts the login process), a high cost of ownership over the company-wide enforcement of 2FA, and the on-going maintenance to make sure it’s still being used.
But what about an option that sits in between these two imperfect solutions, one that runs in the background causing no friction for the user and requiring no change in behaviour either? In fact, the users don’t even know it’s there. Sounds too good to be true, right? Well that’s exactly where contextual authentication fits in.
Contextual Authentication
This is where the context (or factors) around a user’s login are considered and assessed, to then decide whether the person is who they say they are. If there’s a chance they are not, then an appropriate action is taken.
For example, Rich arrives at his San Francisco office every morning and logs in using his desktop computer at about 8am PST. Then Rich takes his first ever business trip to Beijing (China) and he logs in at his hotel via the wifi, from his laptop that he’s never used for work before, and at the equivalent of 5pm PST. A simple system might assess the context of Rich’s login based on:
- Location
- IP address
- Device
- Time
This login would present a high risk score as all factors fall outside of the behavioral profile that has been established for Rich over time. The login would immediately trigger an alert to be sent to Rich to verify his identity and/or the IT administrator at Rich’s company to further investigate this potential security breach. When Rich’s identity is confirmed this new data will become a part of his user profile, so the system gets smarter and smarter.
The above example considers 4 factors within the context of his login, but as you can imagine there are many others such as: velocity checks, IP reputation, whitelist/blacklist countries, suspicious login locations, Tor usage, known behavior amongst co-workers, and more. More advanced systems will use these to reduce the number of false positives.
A friction-less win
The key here is a shift in mentality from businesses. They need to move security responsibilities off their users and protect themselves with real-time, contextual authentication. When you have complex risk detection algorithms working away in the background to build risk scores for user logins, critical events or actions taken within your application, you have put your company squarely in the driver’s seat to assess and understand your exposure to security risk at any given time. While this undoubtedly lowers your chance of a security breach, it also goes a long way toward ensuring the CEO and CTO sleep better at night.