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.
Understanding the Dynamics of Social Engineering Threats
Social Engineering is a category of threats where scammers manipulate people to perform actions that grant the scammer access, information or resources they shouldn’t have. There are often two exploited entities in a social engineering attack:
- The person who is fooled into using their identity to perform the actions in question.
- A person or business that is spoofed by the scammer in order to gain trust with the primary victim; e.g. a supplier, manager, bank representative, authority, etc.
The far most common social engineering technique is phishing, where emails or text messages trick persons to open attachments or click on links. But there are many other ways - such as baiting, quid pro quo, scareware, etc.
A highly insidious technique that has caused heavy problems for services protected by secure authentication are pretexting attacks through vishing, where the victims are contacted over phone, and get fooled to authenticate, reveal credentials and not seldom transfer money - all through well directed storytelling.
Safeguarding 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.