inWebo launches a new offering for IoT Security

Posted by | News | No Comments

San Francisco and Paris, December 18th, 2017 – inWebo Technologies expands its security portfolio for IoT security by launching a new offering called inWebo Local Authorization.

Service providers in verticals such as Connected Cars, mobility services, Smart Cities, Connected Home, Connected Health, etc., can now benefit from inWebo exhaustive framework for secure access control, both to cloud-based IoT services and to local IoT resources.

« In a first wave of IoT services, service providers have requested access control solutions to protect their cloud-based services. inWebo has met these requests by successfully adapting and implementing its multi-factor authentication solution in connected-car services for instance », said Didier Perrot, CEO at inWebo Technologies. « In a second wave, service providers need new solutions for secure access control to local resources such as vehicles, locks, meters, ticketing systems etc., that are not constantly connected to a central authorization platform via the Internet. These ‘offline’ use cases are becoming mainstream in the IoT and demand a new security approach to protect the IoT resources and businesses, while being extremely easy and intuitive to use. This is what inWebo Local Authorization now enables. We’re now willing to partner with more service providers to make the IoT a secure place. ».

Developing a framework for secure local access control has required a significant R&D effort and has led to a patent application. inWebo Local Authorization (IWLA) is an alternative or a complement to connectivity solutions, such as 3G or low-bandwidth mobile connectivity.

IWLA allows a resource such as a lock or a driverless vehicle to take a local authorization decision to give access to a user based on the verification of a virtual key that includes non-spoofable claims and rights about the resource. A virtual key is carried in a smartphone App for instance. The verification happens instantly without the need for the resource or the smartphone to connect to a central server. The verification doesn’t expose the key itself, thus preventing a wide range of attacks.

inWebo provides an API to issue and manage smart locks and virtual keys, based on an infrastructure that makes extensive use of FIPS-certified hardware security equipment. IWLA is therefore both extremely secure and extremely easy to implement by service providers.

You can read more information on inWebo security framework for the IoT on our website

Forgerock Trust Network Technology Partner

Posted by | News | No Comments
Forgerock logo  

Forgerock announced today the extension of its technology partnership program, of which inWebo is now a member. See the full press release and partner directory featuring inWebo.

“For years, Forgerock and inWebo have been sharing a common vision of Identity and Access Management for Web applications, IT applications, and now IoT”, said Didier Perrot, CEO at inWebo. “This renewed partnership and the investment we make in integrating inWebo MFA solution with Forgerock products will allow any organization to take a best-of-breed and future-proofed approach to IAM and security, combining Forgerock’s leading identity platform and inWebo’s innovative MFA and local authorization framework.”.

Strong Authentication – Now!

Posted by | News | No Comments
2fa Jetzt  

inWebo has joined the German Strong Authentication – Now! initiative as a new partner. The initiative’s goals are to educate service providers and end-users about the benefits of strong authentication and to develop its use for Internet services. Find more information here.

“Strong Authentication – Now!” participates to the European Cyber Security Month event that aims at increasing awareness of cyber security threats, at promoting cyber security among citizens and organizations, and at informing about best security practices.

New US Patent

Posted by | News | No Comments

San Francisco, June 15th 2017 – Completing a 4-year procedure, the US Patent Trade Office (US PTO) has granted a patent to inWebo, its second one in the US, thus extending the reach of its prior IP protection. This patent is for an authentication system, and more specifically for a technology known as “Dynamic Random Keys” that inWebo has invented and developed over the past years.

« This technology allows for a secure implementation of multi-factor authentication (MFA) in modern web-browsers, while a hardware secure element was conventionally required to achieve a high security level » said Didier Perrot, Director at inWebo. « It therefore extends the our MFA market to organizations in segments that can’t afford to deploy hardware ‘tokens’ to the users that they need to securely authenticate and are looking for easier yet secure user authentication methods ».

This technology was also the ground foundation for inWebo mobile and in-App authentication library (mAccess) that has been certified by the French governmental IT-Security Agency (ANSSI) in 2012.

in-App MFA

In-App MFA, What Is That?

Posted by | News, Tutorials | No Comments

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

To sum it up, In-App MFA and browser-based MFA bring an optimal security to any mobile App, desktop client, or web application, at no cost in terms of user experience, unlike all other 2nd factor methods such as smartcards, key fobs, MFA Apps, or short-text messages.

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.

For more information, please visit inWebo developer website or contact us to set up a customized demo.

inWebo Log API

A new Log API

Posted by | News, Tutorials | No Comments

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:

  • Authentication
  • 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.

Biometry as a second factor

Biometry as a second authentication factor

Posted by | News, Tutorials | No Comments

Following Apple’s introduction of a fingerprint sensor on iPhone 5s in 2013, smartphones increasingly come with a biometric sensor. Market research firms expect that 100% of the installed base will have some form of embedded biometrics by 2020 – this is not yet a commodity, but it will come fast. inWebo has therefore upgraded its solutions to support biometry as a second factor. This option is available on request to all customers, existing as well as prospects still evaluating inWebo (free trial).

Upon activation of this option, it offers 2 alternatives, “biometry enabled” or “biometry forced”. The former applies to services that require users to enter a PIN as a second factor. Users who opt for it replace that PIN with biometrics. The latter mandates biometry as the second factor, therefore adding the authentication service on a smartphone will succeed only if that smartphone has a fingerprint sensor.

Biometry Settings

Biometry as a second factor can implemented with

  • inWebo Authenticator version 4.2.0 or higher. The App supports Apple TouchID, as well as fingerprint sensors on Android Marshmallow (6.0+) smartphones.
  • inWebo mAccess version (0.)2.8 or higher. Developers can use mAccess library to support fingerprint biometry in their App but also virtually any kind of biometry (voice, face…), as long as it is implemented with a “match on card” mechanism (i.e. the biometric data is stored and verified locally on the smartphone). The mAccess library documentation on inWebo developer website provides a complete implementation for fingerprint sensors.

The biometry as a second factor option can be requested by checking a box when you create an evaluation account (here), or when you upgrade a basic plan to a premium one (there). You can also ask our solutions experts about it.

DACH expansion + IT-SA 2016

Posted by | News | No Comments

Paris and Frankfort, October 3rd 2016 – inWebo is pleased to announce the appointment of Carlos Pinilla as a VP of Sales for the DACH Region: Germany, Austria, and Switzerland.

Mr Pinilla is a seasoned IT-security professional, having been among others a regional sales & marketing director for Utimaco, an Aachen (Germany) based hardware security module (HSM) vendor, and a partner of inWebo.

Based out of Frankfort, Mr Pinilla will spearhead inWebo development by building a channel of selected security partners, software vendors, and system integrators. As one of its first appearances in the Region, inWebo will be present at the IT-SA security show in Nuremberg October 18-21.  –

SailPoint IdentityIQ supports inWebo multi-factor authentication

Posted by | News | No Comments

San Francisco & Paris, June 30, 2016 – Sailpoint ( and inWebo have completed interoperability tests to use inWebo as an Identity Provider (IDP) for IdentityIQ, SailPoint’s popular identity governance suite.

The integration relies on SAML v2 support by IdentityIQ and inWebo. The integration “how to” documentation is available on inWebo developer website.

Customers can now use inWebo robust and convenient multifactor authentication to protect users access to IdentityIQ.

inWebo Virtual Authenticator

Virtual Authenticator Is For Real

Posted by | News, Resources, Tutorials, Tutorials | No Comments

We have a blog post on why browser-based authentication makes sense, explaining why and how we came to develop Virtual Authenticator.

A new and convergent authentication method

Virtual Authenticator is the latest authentication method added by inWebo to its solutions, and the successor of Helium, a browser-based authentication method released in 2012, used to protect millions of identities.

The name refers to inWebo Authenticator, the smartphone App available for iOS, Android, and Windows Phone, which supports on-demand OTP (one-time passwords) as well as OTP triggered by push notifications. The reference goes beyond the name, since Virtual Authenticator proposes a unique and converged user experience with inWebo Authenticator.

In particular, users have the same PIN for a given service on Virtual Authenticator and on inWebo Authenticator. This is the same experience on web and mobile, in both cases just a PIN to enter, no ‘security codes’ or copy-paste or App to launch.

What’s in for me?

From an organization perspective, deploying Virtual Authenticator is, actually, not a deployment. There is no software to install or to distribute to the users. You only need to make a change to your authentication page and to authorize Virtual Authenticator from your inWebo administration account. This is described here.

All things considered, this is the easiest to roll out authentication method.

A smooth transition from inWebo Helium

For those already familiar with inWebo Helium, Virtual Authenticator is not a revolution. It comes with features already available with Helium, such as:

  • 1- or 2-factor OTP generation; it can therefore be used both in step-up authentication and multi-factor authentication scenarios
  • PIN change
  • PIN reset
  • a security self-check based on a secret sentence optionally defined by the user, which can be verified by the user whenever he is asked to enter his PIN in Virtual Authenticator.

As it was the case for Helium, the secret sentence is only displayed after a successful and automatic browser authentication with inWebo servers. It cannot be obtained by phishing. We have slightly changed the way it is presented and made it similar to how websites using SSL certificates are displayed in browsers, since users are now familiar with that.

Virtual Authenticator antiphishing

Virtual Authenticator antiphishing

Additionally, Virtual Authenticator has a keyboard for the PIN-entry, which is especially useful with touch screens.

Helium is still supported!

New customers are now proposed Virtual Authenticator and inWebo Authenticator as a default. Customers already using Helium will not see any change since there is no automatic or required migration to Virtual Authenticator. Helium will continue to be supported for existing customers, but also for new customers needing more customization (e.g. branding or PIN policy).

Can I see it?

Yes, we would love to! You are only 3 clicks away. Just sign up for a free trial account for your organization here. You will be able to use Virtual Authenticator to access your administration account, but also to provide it to users so that they access your applications safely and conveniently.