As we have called-out several times that Passwords, Traditional Oath and RSA OTPs, SMS OTPs, all are bearer (-agnostic) instruments in the user authentication space. What this translates in to, is that anyone who intercepts and spoofs these credentials, can perform an account take-over (holder of the credentials), which is the heart of the several attacks so far leading to 81% of data breaches and online fraud.
These attacks on the user authentication now have reached a new level of maturity that tools like Modlishka, Evilngnx and Muraen that can defeat all the traditional 2FA schemes either through bypass or interception.
As a shift from shared secrets’ risk, a new buzz phrase of so-called “decentralized secrets” has evolved with several market players in the authentication space. Essentially and eventually tied to the pair-wise, the private key at the user’s end device and the public key registered with authentication server (aka relying party).
One of the early analysis by the team at Univ of Oslo aptly points to a mere distribution of the “centralized database exposure risk” that is traditionally associated with shared secrets.
The premise is that with user’s end devices holding private keys, while the relying party holds the corresponding public keys, there is no risk at the relying party of the database exposure, as it merely exposes public keys.
Let us closely look at the distribution of the risk associated with the databases containing public keys that play vital role in signature verification in the challenge-response authentication.
1. They are no private secrets to expose at authentication (relying party) server:
At a first glance, it seems that when data(bases) at the authentication system is compromised, there is no risk, as all the private keys are in the end-users’s devices.
The premise is that the attackers would now have to go after individual users for private keys that is not incentivized.
However, If there are sufficient incentives for the attacker that eventually leads to monetization, the central database whether it does or not contain private keys remains the point of interest, as along as the keys in the database play a role in authentication. In this case, the public keys that are used to verify the signatures of the challenge response at the user’s end with private keys.
The following figure depicts the risk associated with databases holding the public keys.
When the public keys are selectively replaced by the attacker’s public keys associated with an account, attacker can use his private keys to move ahead with unauthorized access.
As such, the same risk exists at the centralized database as with shared secrets database risk, that was set out initially to mitigate.
Summary: As long as the data/secrets/public keys in the centralized database, at the relying party, are tied to the eventual authentication verification, the same risk exists.
This leads to the second question that authentication based on shared secrets cannot protect from man-in-middle interception (proxy and spoof)
2. Only public and private key cryptography can address man-in-middle interception attacks
In order to look at the efficacy of shared secrets-based authentication vs public-private keys cryptography-based authentication, the reader is brought to the attention of “bearer agnostic” nature of the shared secrets.
Simply put, all the current passwords, One-time passcodes based on either SMS or Oath/RSA algorithms generate authentication credentials that are virtually bearer tokens. Any one who holds the tokens are granted the access. Hence, the fundamental problem is the “bearer-agnostic” nature of the shared secrets, but not the shared secrets themselves. The disclosure of the shared secrets would translate to “no-secrets” as they are divulged to the man-in-the-middle.
If the authentication credentials are made “bearer-sensitive”, their ownership is tied back to the end user. In this scenario, even if the Man-in-the-Middle (MitM) intercepts and spoofs, bearer-sensitive authentication credentials, the MitM cannot spoof them as a legitimate user due to the ownership that traces back to the end-user and not the MitM’s.
iLogSafe® brings in an innovative technology with its anti-phish codes addressing man-in-middle that all current passwords, regular OTPs/SMS are vulnerable to.
