News

PSD2 SCA: The Clock Is Ticking

Posted by | News | No Comments

The introduction of the revised Payment Service Directive (PSD2) that came into application on January 13, 2018, brings a shift in financial transactions. If in the past SMS codes were the preferred way to confirm an online payment, organisations such as Payment Initiation Service Providers (PISPs) and Account Services Payment Service Providers (ASPSPs) now have deadlines to meet PSD2 requirements:

  • March 14, 2019: ASPSPs’ access interface must be ready for external testing by PISPs as required by the Regulatory Technical Standards (RTS).
  • September 14, 2019: PISPs need to comply with RTS and PSD2 requirement and propose Strong Customer Authentication (SCA) to their customers.

As the clock is ticking by, let’s understand the hows and whys of this regulation.

PSD2 SCA: What and why?

Payment services are evolving, creating new opportunities and new ways to transact beyond borders. As a consequence, the EU has decided to harmonize the different country-specific practices in order to:

  • Contribute to a more integrated and efficient European payments market,
  • Improve the level playing field for payment service providers (including new players),
  • Make payments safer and more secure by reducing fraudulent activities,
  • Protect confidentiality of consumers.

This is the PSD2. When it comes to security, text messages have shown their limits to make online transactions safer. Latest breaches such as Voxox leak exposing millions of SMS messages prove that systems can be easily corrupted when it comes to proving identities. This is why PSD2 has issued new requirements with the aim of creating a secured environment to online buyers.

Welcome to the Strong Customer Authentication (SCA)

A compliant SCA is based on 2 or more authentication factors of different types among the following options:

  • Something you know, such as a password.
  • Something you have, such as a mobile device, a plastic card.
  • Something you are, such as a thumbprint.

As everyone initiating an online transaction will soon have to use SCA, it is important to stress that SCA solutions must provide a high level of security but also an easy customer experience. This is actually a more difficult challenge.

Providing physical tokens to everyone is hardly an option because of the costs to issue and manage such devices at a large scale. Also, customers with multiple banks would need several tokens, resulting in an authentication fatigue that is counter-productive to the objectives of PSD2.

Only software-based solutions provide the flexibility required by banks and third parties and ensure a smooth deployment while keeping costs low. inWebo MFA perfectly matches these requirements since it provides a secured method to validate buyers’ identities without impacting the experience. inWebo is easy to implement, to deploy and to manage. The different authentication methods available from inWebo make it possible for users to have a seamless experience for any payment use case. inWebo Transaction Sealing feature makes the transactions non-disputable. The alignment of its solutions with PSD2 SCA requirements has enabled inWebo to already support leading banks to secure transactions and account access.

PSD2 is just the start. inWebo expects that most of the banks will switch to the 3DS 2.0 worldwide regulation coming into force in 2020. inWebo is already supporting financial institutions and banks in deploying its solution to swap prior authentication methods with SCA compliant ones.

If you’d like to know more about inWebo MFA for financial institutions, you can download our tailored white-paper or request a demo by clicking the relevant option below:

Request White-Paper Request a Demo

inWebo Renews Participation To Forgerock Trust Network

Posted by | News | No Comments

inWebo releases certified 2FA module for ForgerockAM identity platform

San Francisco, CA – December 3, 2018 – ForgeRock, the leading platform provider of digital identity management solutions, today announced a major milestone in advancing its technology partner ecosystem, in welcoming 54 partners to its ForgeRock Trust Network. Program Unites Leaders in Strong Authentication, Risk and Fraud and Related Fields to Extend Value in ForgeRock Identity Platform. The Trust Network was created to unify ForgeRock’s extensive community of technology partners for customers to seamlessly integrate complementary technologies and realize the highest value from their ForgeRock Identity investments.

inWebo was one of the early partners to join Forgerock Trust Network in 2017 and is pleased to announce the release of a certified extension module for ForgerockAM. That module enables Forgerock customers to benefit from inWebo multi-factor authentication, thus enhancing the security of their applications, meeting compliance requirements, and making it easier for their internal and external users to access trusted applications.

Ben Goodman, Vice President, Global Strategy & Innovation, said, “The ForgeRock Trust Network for Technology Partners was built to deliver capabilities beyond our own identity platform, and the reception from our partner community and customers has been overwhelming. The Trust Network is unlike the typical ‘partnership by press release’ program seen in our industry, as our partner directory is loaded with integrated solutions that have been certified, to give customers technical confidence and cost predictability. As the identity ecosystem continues to expand, the ForgeRock Trust Network of partners will continue to deliver unmatched innovation to those who use our platform.”

Jeff Sherwood, Director of Business Development for inWebo North America, said, “Strong Authentication (MFA) has become a critical part of modern Identity & Access Management projects. We are very excited to partner with Forgerock, a global leader in IAM & CIAM, and thus to deliver a certified interoperability between ForgerockAM and inWebo MFA platform. It will greatly help Forgerock customers meet their compliance requirements while reducing the time and costs needed to protect their applications, as well as the pain for internal and external users.”

About inWebo
inWebo is a leading vendor of B2B solutions for multi-factor authentication (MFA) and local access (IWLA). inWebo makes customers, members, and employees access to VPN, IAM, web, Cloud, and IoT applications & devices more secure, but also easier. Our technology seamlessly adds a layer of security during authorization by turning user devices including laptops, cell and smartphones, or tablets into trusted authentication methods. It uniquely combines certified hardware-grade security with extreme ease of use. inWebo protects millions of identities for global organizations. Visit us at inwebo.com.

About ForgeRock
ForgeRock® is the Digital Identity Management company transforming the way organizations build trust and interact securely with customers, employees, devices, and things. Organizations adopt the ForgeRock Identity Platform™ as their digital identity system of record to monetize customer relationships, address stringent regulations for privacy and consent (GDPR, HIPAA, FCC privacy, etc.), and leverage the internet of things. ForgeRock serves hundreds of brands, including Morningstar, Vodafone, GEICO, TomTom, and Pearson, as well as governments such as Norway, New Zealand, and Belgium, among many others. Headquartered in San Francisco, California, ForgeRock has offices in Austin, London, Bristol, Grenoble, Munich, Paris, Oslo, Singapore, Sydney and Vancouver, Washington. ForgeRock is privately held, backed by leading global venture capital firms Accel Partners, Foundation Capital, Meritech Capital and KKR. For more information and free downloads, visit www.forgerock.com

GDPR at inWebo

Posted by | News | No Comments

From Security-by-Design to Privacy-by-Design

In the weeks and days before (and after) May 25th 2018, everyone’s mailbox has been filled with emails such as “GDPR update” or “Update of our Privacy Policy”. You might wonder why you have not seen any of these from inWebo, what we have done about the matter, and how ready we are.

inWebo’s business is identity protection. We design and implement cyber-security techniques to protect our customers’ user identities. PIIs (Personally Identifiable Information) are highly protected in our systems, using strong encryption, crypto-servers, firewalls, etc. GDPR requirements in terms of security are met and exceeded. However, GDPR is much more than that, therefore we had to figure out the journey from our “security-by-design” starting point to a “privacy-by-design” destination.

Here are the various topics we addressed and what our approach is:

  • User consent to data processing purposes: as a B2B provider of authentication solutions, we do not collect data from the end-users of the solution, our customers do. We collect data from administrators when they create their organization account, for the sole purpose of creating that account and giving access to it.
  • Minimal set of data: we only store in our systems the user data that is necessary for our customers to operate and monitor the authentication solutions we provide them, such as a username, an email address, and authentication usage data (time and date, IP address, authentication status). It is our customers’ responsibility to use anonymous aliases instead of usernames and to not store email addresses if they do not use features such as “Reset PIN with email” that need it.
  • Data governance: that was a benefit of GDPR to have us design a data governance and a data retention policy. We have now standardized our data retention durations: by default, authentication and other usage data is kept one year. Also, all organization account data are deleted maximum 6 months after an organization account expiration. Customers who need a longer retention duration e.g. for long-term security analysis can subscribe to an archiving option.
  • Access to data and traceability: since we operate the authentication platform and since we rely on service providers for some aspects of the solution (email service provider and hosting service provider among others), we needed to design and enforce policies for access to data, both for ourselves and for our service providers. Service providers have issued their own GDPR compliance statements and we have analyzed that they are compatible with our goals and practices. For ourselves, by default we never access user data unless a customer requires us to do so, for instance in order to troubleshoot an issue. We have formalized how our operational teams authorize and log such requests.
  • Data protection: critical data such as authentication factors are encrypted with crypto-servers (HSMs) in our platform. Usernames are usually not critical information (if it is, it is our customers’ responsibility to use aliases instead) and they are needed in plain text e.g. to run search queries. Other identifiers such as email addresses or “trusted devices” names are usually not critical information but we have nevertheless decided to encrypt it at rest.
  • Rights (to access, to modify, to be forgotten): we do not know the end-users of our customers and have no way to match a request that we would receive with an actual end-user in our platform, or to verify that such a request is legitimate. Besides, if one of our customers has created an authentication profile for a user in our platform, our responsibility is to not access it, not modify it, and not delete it. Therefore our role is to provide our customers with the tools and processes they need to answer their users’ requests, e.g. an API function to delete user data in the authentication logs in our platform. Nevertheless, we have created an email address for privacy and PII-related requests from end-users. We will limit our role to reply to emails advising the user to send his/her request to his/her organization or service provider.
  • Update of our privacy policy and of our general terms: we have updated our privacy policy and our general terms in January 2018 in order to include the changes resulting from our GDPR compliance.

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 https://www.inwebo.com.

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.