If there is anything to be learned from 2017’s array of massive data breaches, it’s that single-password authentication is no longer enough to warrant security. Deloitte, one of the world’s top accounting firms, learned this the hard way. Last year, the company was hit with a massive hack that compromised private emails as well as confidential information of some its blue-chip clients. Sources told The Guardian that the breach occurred through an administrator’s account, which gave hackers unrestricted access to everything else. The account in question required a single password, with no two-step verification. Read More
The selection of the “right” MFA solution can be tricky. First, because there’s a constant flow of innovation in the authentication industry, resulting in numerous and diverse technologies even for solutions supposedly following a standard. Second, because the applications and environments needing MFA are also very different (cloud vs. onprem, legacy vs. web, ldap vs. radius, SAML, or OIDC, etc.). Lastly because not all solutions have the same objectives or protect against the same risks. Read More
As we should all know by now, 1/ everything is getting connected, the Internet is no longer about computers and servers only but also about billions of objects that once belonged to distinct categories, such as consumer electronics, automotive, medical devices, industrial and infrastructure systems etc. And 2/, security issues are going to be even larger and scarier in the era of the Internet of Things.
This raises a few questions for the cybersecurity industry, such as: Are we ready to address this challenge? Have we developed the right tools yet? The short answer is no. Read More
One of the main new features presented during Apple keynote this September is a face recognition mechanism that will be part of the iPhone X. FaceID, how that mechanism is called, will initially be used as a way to unlock the phone screen, which is also how TouchID was introduced on the iPhone 5s in 2013. Read More
Passwords are prehistory. Passwords are dead. We’re going to end passwords. Sounds familiar? Google probably has millions of results for each of these searches. Yet, for as long as I can remember – since the rise of the World Wide Web at least – passwords have been fingerpointed as the flaw in this otherwise amazingly well engineered system. Read More
It was supposed to be a nice weekend, but for many people working in IT and security organizations, last weekend turned out to be a nightmare. A self-replicating ransomware going by the name of WannaCry hit several hundreds of thousands of computers worldwide, many of them in large organizations – the NHS, Renault, and Telefonica have been mentioned in the news. Every time such an attack makes it to the headlines, the priority for IT and security people is to manage the crisis: contain the spread, eradicate the worm, and resume normal business operations. This can take hours or days (and nights), sometimes longer, but hopefully everything is back to normal before the next one hits.
Multi-factor authentication (MFA) has become so commoditized in the recent years that it’s easy to forget that it’s a service running on servers. And as such, that it can suffer interruptions and hacks. Recognizing this has consequences on how to pick and to use an MFA service.
Various types of authentication factors
Multi-Factor Authentication (MFA) means using a combination of factors of different types to authenticate a user when she signs in to an application. Factor types include knowledge (“what you know”, a secret, a password), possession or ownership (“what you have”, a key-fob, a USB key, a phone, a smartcard…) and inherence (“what you are”, biometry).
The trouble with ownership
The possession / ownership factor is actually not the plastic or the smartcard itself. It’s a secret information (aka seed) stored in a memory chip called a secure element. Because of the need for secure elements to implement MFA, it has long been too expensive and inadequate for many use cases, especially but not only, the consumer facing ones.
The situation has improved in recent years when hardware secure elements have been progressively replaced with software on a smartphone. inWebo, as many other vendors has an MFA App, inWebo Authenticator. Once activated for a user, inWebo Authenticator stores a seed key specific to that user and uses it, possibly combined with other authentication factors, to generate one-time passwords (OTP).
inWebo Authenticator can seamlessly switch between a connected mode, a stand-alone mode (useful for roaming situations, in-flight, no or bad signal…), and a notification-based mode that prompts the user for her confirmation or additional authentication factors (PIN, fingerprint…) and completes the authentication and sign-in without asking the user to copy-paste an OTP. Nice…
We need MFA, but why do we need a token?
A mobile App is definitely more convenient than a key fob to carry around, but it requires that all users have a smartphone and have downloaded the MFA App, then activated it. There are many situations when this is not the case. Actually, when you think about it, it’s almost never the case. How could we remove this constraint?
This question led us to the idea of In-App MFA, as early as 2010. Instead of using a stand-alone ‘token’ (hardware or App) and have the user enter OTP in an authentication interface (a desktop client, a mobile App, a page in a browser), why not generate the OTP directly from that interface? That would alleviate the need for tokens but also for smartphones, MFA Apps, and even short-text codes.
inWebo mAccess (for native clients) and inWebo Virtual Authenticator (for web applications) are the In-App authentication technologies developed for this. They are available and documented on inWebo developer website.
How does it work?
With In-App MFA, the OTP generation is done by a software library instead of a standalone App. That library – inWebo mAccess for native clients – can be integrated in any mobile App or desktop client. That App or client literally becomes an MFA token. inWebo mAccess manages the user’s unique seed key, i.e. the possession / ownership factor.
At sign-in, the user is prompted by the client for her usual credentials (username and password). There’s no experience change compared to a normal, non-MFA sign-in. Then, the client silently makes a call to an inWebo mAccess function to request an OTP. This call is local to the client.
In a 2-factor authentication scenario, the password is used as an input argument for the OTP calculation function of the mAccess library. That function also uses the user’s unique seed key attached to the user’s App – hence “2-factor”. The client uses the multi-factor OTP returned by mAccess for authentication to the back-end.
In a step-up or 2-step verification scenario, the user’s unique seed key is used to calculate the OTP. The client uses both the user password and the single-factor OTP for authentication to the back-end. It’s also 2-factor but in a different way (for more on that, you can read a blog post about 2FA vs. 2SV)
Secure MFA that users can’t see
The obvious benefit of inWebo mAccess compared to a stand-alone MFA App or ‘token’ is that the user doesn’t copy-paste, interact, or even see one-time passwords.
What are the downsides, if any?
At first, when discovering In-App or in-browser MFA, most people are confused. Since there’s no experience change, they say, what’s the difference with a password-based authentication? Why is that MFA? Here, what you see is not what you get. As explained above, authentication is based on several factors. If someone has hacked the user password but doesn’t have the possession / ownership factor (stored with the client), his authentication attempt fails. 100%.
Ha ha, they say next, but what if the device with the client and the possession / ownership factor is stolen? Well, there’s no difference with stealing a smartcard, a key fob, or a smartphone with an MFA App. If the hacker steals the ownership / possession factor AND somehow manages to guess or phish the user password (which is truly independent because it’s not stored with the client), he will successfully access the user account, whether or not the ownership / possession factor is a library, a key fob, a smartcard, or a smartphone App. There’s no difference.
Mmmm, well, but what if the client is compromised, they say next, hoping that this one is the trump card. If the client is compromised, the hacker will succeed, whatever the authentication method, even the most ‘extreme’ ones such as connected smartcard readers: once the door is open (i.e. the user has logged in), it’s open bar for whoever controls the client.
inWebo mAccess is as secure as the clients used to sign in.
Tokenless secure MFA for any App, native or web
As discussed, inWebo mAccess turns any native App or desktop client into a secure ownership / possession factor. inWebo Virtual Authenticator is to web browsers what inWebo mAccess is to native clients: it turns the user’s browser into a secure ownership / possession factor.
I attended the Gartner IAM Summit in Vegas this week. Great conference, lots of smart and inspiring people. Multi-Factor Authentication (aka MFA or 2FA or 2-factor…) was a frequent topic of discussion, both in the analysts sessions, who did brilliant projections of the market trends – future, present, and past – and in the Access Manager vendors’ booths.
inWebo provides a Log API so that you don’t have to export activity logs manually every day or every week. Logs are automatically made available in your collect and analytics tools.
inWebo Log API gives access to logs for a given service. Authentication to the API requires the same client certificate as the other inWebo APIs. Following log categories are available:
- Actions related to authentication devices (activation, online OTP, notification requests)
- User management
- Service configuration and Administration
With a call to the Log API, you can specify start and end dates, make page requests, or filter results by log category. Each record in the result is provided as a JSON table containing the following data:
- Method used (authenticate, loginCreate…)
- Result (OK, KO…)
- User login
- Time and date
- IP address (when available)
- Authentication device used
- Authentication device identifier
Contact inWebo if you would like to activate this option for your authentication service.