Problem

Credential Harvesting

Billions of the Credentials Your Clients Reuse Have Been Pwned

Credential Harvesting (or Account Harvesting) is the use of MITM attacks, DNS poisoning, phishing, and other vectors to amass large numbers of credentials (username / password combinations) for reuse. Attackers use a variety of these tools to aggregate vast quantitites of credentials and make them available for sale on the dark web and through other clandestine channels.

Organizations are under increasingly sophisticated and constantly evolving attack from attackers that purchase these massive databases of stolen credentials to exploit weaknesses in authentication and API security. The unfortunate tendency that most users have to reuse credentials across multiple online relationship compounds the problem and leaves you vulnerable to attack even if your site and your users’ credentials haven’t been compromised per se. An attacker can replay your customers’ known credentials from other sites against you on the reasonable chance that those credentials will also allow them access to your applications.

The exposure with credential harvesting is multi-faceted giving attackers access to a broad array of methods with which to attack you with harvested credentials from both the mobile channel and the browser channel.

 

credential-harvesting

Renders Existing Credentials Useless

By most reports there are anywhere from 5 billion to 7 billion credentials that have already been compromise that we know of. Coupled with common user behavior of reusing credentials across multiple services, there's an excellent chance that the password some of your customers are using for your site have been compromised elsewhere and are waiting to be tried on you. 

REL-ID's strong and passwordless authentication eliminates the use of those credentials, rendering them completely ineffective against you and your services. You get strong authentication and no vulnerability to credentials that have been pwned elsewhere.

eliminates-api-exposure

Eliminates API Exposure

Attackers can't go after what they can't see. REL-ID completely cloaks your services and APIs so that they are not even visible, much less accessible, to illegitimate users. Specifically, they are only accessible to trusted users that are using your untampered app on a trusted and trustworthy device. Your service will never even see a request from any source that doesn't meet those criteria. This goes beyond helping thwart attacks -- it helps prevent attacks in the first place.

 

 

 

lock-down-mobile-channel

Lock Down the Mobile Channel

REL-ID combats against having your customers' mobile devices being used as an attack vector against your sites and applications using a multi-layered approach. An attacker would have to compromise all three layers to even be able to attempt to connect with you:

  • Device Authentication: Only known and trusted devices are permitted to connect. If REL-ID does not recognize the device fingerprint, the request is dropped immediately. Even with known devices, REL-ID then does a series of security and integrity checks to ensure that the device is trustworth -- that it isn't rooted / jailbroken, compromised by malware, or otherwise vulnerable. Even known devices aren't permitted to connect if they are deemed to be compromised.
  • App Validation: Assuming that the device is both known and trustworthy, REL-ID then validates your app to ensure that it hasn't been tampered with. Only your legitimate and untampered app, containing the REL-ID client, will be allowed to connect. This means that even if an attacker has somehow compromised a legitimate device from one of your actual customers, they will not be allowed to connect without your app. Remember that REL-ID has already "cloaked" your APIs and services, so it's impossible for an attacker to use a browser or anything else on the device to even discover, much less target your services.
  • User Authentication: Even after all these checks, an attacker would have to get to the hardest challenge of all -- REL-ID now validates that the user has its half of the appropriate symmetric key that is unique to the Relationship between that user, app, device, and service. This is an unphishable and unspoofable credential without which REL-ID will not allow the app to connect to your service.

 

protect-web-channel

Protect the Web Channel

All of these security mechanisms will funnel attackers to the browser channel from which to use their library of harvested credentials, and REL-ID protects you there as well. Even assuming that the attacker has a customer's legitimate credential that could be used to compromise their account with you, REL-ID now adds an extra layer of security -- it uses the secure channel to your app on the legitimate customer's mobile device to inform them that a web login is being attempted and asks them to confirm. If the customer doesn't confirm, the attacker is thwarted from replaying the customer's legitimate credential and will never even know that they had a legitimate credential in the first place.

LET'S GET IN TOUCH