inWebo Authentication Service Security
Why is MFA security even a question?
An authentication solution is what is supposed to make access to your applications more secure than passwords. It’s therefore were attackers wanting to get access to your applications will most likely concentrate their attacks. Examples abound of authentication solutions – MFA, single sign-on, as well as password managers – that have been compromised in recent years.
What could possibly go wrong with an MFA solution?
A lot of things! Attacks that were theoretical only possibilities just 5 years ago are now routinely and successfully employed. It’s therefore definitely worth checking that the MFA solution that you’re considering does more than just follow some standard. In terms of security, MFA standards and recommendations are just the starting point of the journey. Bad implementation, lack of or incomplete risk analysis, or, simply, inadequacy of a solution’s security target, can literally make a “compliant 2-factor solution” much less secure than password-based authentication. Let’s list some common issues with MFA. Maybe your risk analysis will tell you that some of these risks are actually acceptable to your organization, but better know it and have a solution that mitigates the risks that are not acceptable to your business.
SMS OTP bypass
This is a well-documented classic. Using social engineering, malwares, or hacking the SS7 network – carrier network where short-text messages are conveyed -, an attacker can redirect SMS OTP to his phone and thus impersonate a user. There’s no fix. Government agencies such as NIST have now black-listed SMS OTP.
[inWebo answer] The combined use of our 2FA options such as inWebo Authenticator and Virtual Authenticator makes SMS-OTP pointless, except in rare circumstances that, so far, 99% of our customers don’t need. Contact us and our solutions experts will explain how you can now implement MFA for employees or customers without SMS-OTP. Not only are the alternatives more secure, they are also more convenient – and probably less expensive.
Phishing and Man-in-the-middle (MITM)
The user is fooled into visiting a website or downloading an App that looks like the real website or App. That website or App establishes a back-to-back session with the real website or App. Hardware tokens solutions such as “keyfobs” or OTP-displays on credit cards are vulnerable, but also SMS-OTP and push-based notifications. With the former (tokens, SMS-OTP), the OTP is captured and reused for the attacker’s session. With the latter (push-based notifications), nothing is captured but the user authorizes the wrong session from her smartphone, the one established by the attacker.
While a few years ago, the main reason to implement MFA was weak passwords, phishing has become the real concern since it’s now used with back-to-back sessions (MITM). However, NONE of the popular MFA solutions – hardware tokens, SMS-OTP, and push-based notifications – are countering these attacks. These solutions are only countering attacks elaborated in 2005-2010.
[inWebo answer] inWebo browser-based authentication methods (Virtual Authenticator and inWebo Helium) verify the page and domain where they are executed, with the option to verify the SSL certificate of that domain (“certificate pining”). No OTP will be created if the domain is not correct. inWebo browser-based authentication methods are the only MITM-resistant methods on the market that do not need connected hardware tokens.
Stealing user credentials
Soft-tokens don’t have secure elements, therefore it’s relatively easy to access the authentication credentials. This is usually enough to break a 2-step authentication. For 2-factor, an extra – yet easy – step is required to brute force the user secret, even if it is not stored in any form with the soft-token.
[inWebo answer] We have developed and patented authentication algorithms based on random dynamic keys. Trusted device credentials are constantly updated in a random manner, making the attempts of an attacker trying to create a valid OTP or brute force a PIN pointless – this is math.
As long as user devices don’t come with a hardware secure element built-in, inWebo approach is more universal (it supports 100% of user devices at no extra equipment cost) and, most importantly, much more secure than the approach consisting in storing a private key in the user’s devices (e.g. FIDO). Private keys must be protected with a hardware secure element – which most user devices still lack -, while inWebo’s random dynamic keys are low sensitivity credentials that don’t require a high protection. inWebo’s hybrid approach provides the best of both worlds: very high protection of user credentials following FIDO standards for devices coming with a built-in hardware secure element, and universal support of user devices with an excellent protection of user accounts thanks to the random dynamic key approach.
Hack of the credential database
This is the most efficient attack, yet not the easiest. If the attacker has the credentials, he can impersonate any user. Authentication based on PKI is not vulnerable since there is no central credentials database.
[inWebo answer] Our credentials database is encrypted with keys that are created and stored in certified hardware security appliances (HSMs) where authentication algorithms are executed. The encryption keys can’t be exported. No one – not even us, not even an attacker who would hack our servers – has access to credentials in plain text. Only a trusted device of a legitimate user can create a valid OTP to access her accounts.
This is the lazy version of the credentials database hack. Instead of using hacked credentials to forge valid OTPs, the attacker hacks the authentication server so it validates any OTP, correct or not, therefore fooling the application. The attack can only target some accounts and thus stay unnoticed, even if the customer intentionally sends invalid OTP requests for test accounts.
[inWebo answer] inWebo certified hardware security appliances (HSMs) can sign the authentication result – along with some random data – with a private key. This is a real-time proof that the inWebo authentication service has not been compromised.
Recovery channel attack
This consists in resetting authentication credentials, usually by using some form of social engineering. Such an attack is usually more difficult to perform with 2-factor than with 2-step authentication.
[inWebo answer] All recovery channels use 2FA. In case one – and only one – of the factors has been lost or forgotten, a verified email address or phone number can be used to receive a temporary recovery code – this is an opt-in feature. The other factor – trusted device or secret – is then necessary to complete the recovery process.