Skip to main content
Authentication| Digital Identity| 7 min

How to protect digital identities from Social Engineering

How

Social Engineers will always pose a threat to digital identities on the internet. People and businesses must stay aware of this and try to protect themselves and others. However, available IAM technologies should be expected to take a broader responsibility to fight this - specifically three aspects should be in their center of attention; Elimination of shared secrets, Justifiable parties and Proof of intention.

 

TL;DR

 

  • Understanding Social Engineering Threats: Social Engineering involves manipulating individuals to gain unauthorized access or information. Tactics include phishing, vishing, and pretexting, posing serious risks like data breaches and fraud.
  • Protecting Against Social Engineering: While individuals can mitigate risks with awareness and security measures, effective identity ecosystems should focus on:
    • Justifiable Parties: Ensuring all entities in interactions are trustworthy and accountable.
    • Elimination of Shared Secrets: Using zero-knowledge proof to authenticate without revealing credentials, preventing theft.
    • Proof of Intention: Verifying users' intent during authentication to prevent unauthorized actions.
  • Conclusion: While no authentication process is immune to social engineering, implementing technologies that minimize shared secrets and ensure clear intentions can significantly enhance security and trust in identity ecosystems. Service providers must prioritize these features to protect both users and their reputation.

 

Understanding Social Engineering Threats

 

Social Engineering encompasses tactics where scammers manipulate individuals into actions that grant unauthorized access, information, or resources. It typically involves two exploited entities:

  1. Individuals who are deceived into using their identity to perform actions requested by the scammer.
  2. Individuals or businesses impersonated by the scammer to gain trust with the primary victim, such as suppliers, managers, bank representatives, or authorities.

Phishing, often via email or text messages, is the most common social engineering technique, where recipients are tricked into opening attachments or clicking on links. However, there are numerous other methods, including baiting, quid pro quo, scareware, and more.

One particularly insidious technique is pretexting attacks via vishing, where victims are contacted by phone and manipulated through persuasive storytelling to authenticate, reveal credentials, or even transfer money, posing significant challenges for services relying on secure authentication.

 

Protecting Against Social Engineering in Identity Ecosystems

 

What differentiates social engineering from other attacks is that people are manipulated, rather than technology. The actual damage can be quite serious since these attacks often are door openers to more sophisticated attacks that are set in place as soon as the attacker is inside a perimeter. The end game of an attack could be anything from sabotage, extortion and hacktivism to theft, smearing and fraud.

Higher-privileged people suffer a higher risk of getting hacked, e.g. an administrative user at a business is a hot entry point to get ransomware deployed. Less confident people suffer a higher risk of getting hacked, e.g. older people are seen as easy targets when impersonating authorities and bank representatives.

There are measures that anyone can take to prevent being exposed to social engineering, such as careful device configuration, mindful password policies, general security awareness etc. However, a well-designed identity ecosystem should be able eliminate some of these attack vectors and reduce others. Let’s understand the most significant characteristics of an identity ecosystem that prevent social-engineering attacks.

Justifiable Parties

When discussing digital identities and authentication it is often in a context where services need to verify certain aspects of end users. The need for end users to be able to trust the verifier is often neglected. All parties in an interaction must be justifiable - as clearly spelled out in Kim Cameron’s 7 laws of identity. Justifiable Parties imply that all entities in an interaction must be able to trust each other - hence that a fraudulent entity must either be eliminated from the system or disclosed during interactions.

Elimination of shared secrets

Many social engineering attacks have the purpose of stealing credentials from the victim, so that the real attack can be carried out later, without the victim being present. This is often the case in phishing emails where the victim is lured to enter their credentials for a service on a scam site.

An authentication process based on Zero-knowledge proof will eliminate shared secret credentials, hence removing the opportunity to steal credentials by never revealing them in the first place. A cryptographic software authenticator utilizes unique public and private keypairs and performs a secure asymmetric cryptographic ceremony during authentication - by which the credential holder can prove being in possession of a secret (private key) without revealing it.

Proof of Intention

Whenever a user authenticates, it must be clear for what purpose - and access granted must limit the use by the given purpose. Furthermore, authentication requests must only exist as part of an access request that the user initiated. Proof of Intention is one step further from proof-of-presence - we need an authenticator that doesn’t only prove that the right person is performing the target action, but also that this person wants to perform the action.

As a rule of thumb; the higher trust a service provider needs to establish with their users - the higher risk that the users gets exposed to social engineering. And not only the user is at risk; the service provider may suffer hard both economically and by bad reputation.

There are no such things as 100% social-engineering-resistant authentication processes; psychological techniques will always be able to trick people. But if you are a service provider in strong need of trust - pick an authenticator that (1) prevents your service from being spoofed, (2) doesn’t rely on shared secrets and (3) are fully transparent with your end users.

Recent posts

The NIS2 directive in EU: A country-by-country breakdown

As the updated NIS2 directive takes effect, this article examines how each EU country is progressing...

How to build a European digital student identity

Managing international student identities is complex, involving fragmented systems for university ac...

How to write a process description for domain registration ID checks

The NIS2 Directive, particularly Article 28, imposes new responsibilities on domain name registrars ...