Why protect user accounts with robust 2FA
Whether users are employees working with applications, system administrators in your IT department, or customers accessing your platform, user accounts are where your organizations’s business and reputation have or will be hit. 2FA (2-factor authentication) designates in a broad sense any security solution beyond user-defined passwords (not secure) and password policies (inapplicable or ineffective because they are too complex for users).
Any 2FA solution is a trade-off between a security level, the level of friction introduced for users, and costs & efforts for the organization. Unlike legacy (hardware token) or vanilla (SMS based authentication) user authentication solutions, inWebo is very strong on all 3 dimensions, not only security.
inWebo supports established standards such as radius and SAML v2. Just with these two, you can use our authentication solutions for most – if not all – VPN (Cisco, Juniper / Pulse), reverse-proxies or equivalent (F5 Big IP, Citrix NetScaler, …), SaaS applications (Office 365, Salesforce, Google Apps, and many more), as well as vendor products installed on-premises (SailPoint IdentityIQ, CyberArk, Wallix and many more)
We also expose a REST API, which is interesting in 3 situations:
- If you have a website using a CMS such as WordPress, Drupal, or Joomla. We have developed authentication plugins based on our API for these solutions;
- If you use federation or access management products such as ADFS, Shibboleth, Forgerock OpenAM, Gluu Server, PingFederate, Memority, Ilex… Modules based on our API have also been developed, either by us, or by a partner. More are being developed. These modules provide more flexibility or options than radius or SAML v2.
- If you develop your own back-end, web or mobile, in which case you might want to directly integrate our API. It is fully documented on our developer website. Sample projects are provided for several frameworks.
Making passwords device-dependent
inWebo adds a layer of security to static passwords by adding one-time, device-dependent passwords. Actually, our technology turns any user device into a robust authentication method, such as laptops, mobile phones, tablets. At sign-in, one of the users’ trusted devices is used to generate a one-time, device-dependent password. Note that this password is not sent to the user.
How does it help secure accounts? Someone wanting to access a user account must know her password – as it is the case without 2FA – but must ALSO have access to one of her trusted devices, because there is no other way to obtain a valid device-dependent password. One or the other is not enough, both are required.
All devices. No prerequisite. No dependency.
What we mean by a trusted device is actually not the equipment itself, but a web browser or a native App (or client). inWebo supports:
- App-based authentication: inWebo Authenticator mobile App is used to generate one-time passwords, either on-demand, or when triggered by a notification from inWebo platform. inWebo Authenticator is available for iOS, Android, Windows, and Blackberry.
- in-App authentication: inWebo mAccess SDK turns your own Apps or clients into a one-time password generators. inWebo mAccess is available in C, java, and C#.
- browser-based authentication: the browser is the authentication “token”, i.e. the one-time password generator. Virtual Authenticator and inWebo Helium are available for all browsers.
Furthermore, authentication methods are simply added by configuring group policies. You never need to know which user owns which device(s). Also, the integration of our technology into new versions is totally transparent, you do not need to change anything each time a device or OS vendor releases new versions.
Multiple Devices. One PIN.
Unlike most solutions where a user must always carry her token with her to be able to access your services, inWebo manages multiple trusted devices for a user. Secure access is therefore not uniquely attached to a single trusted device. Furthermore, you do not have to manage those devices, their pairing, and their revocation.
Also, in a 2FA scenario where one-time passwords are issued based on a trusted device and a PIN, the user has the same PIN for all her trusted devices. When it is changed, reset, or unlocked, it is done only once. The PIN is of course not stored on any trusted device and never transmitted.
The experience is therefore identical whatever the way users access your service. It might seem obvious in the context of a static password authentication, but it is far from true in the 2FA world.
These authentication methods cover most situations, use cases, and circumstances in a very flexible way. You can deploy inWebo 2FA Solution to all users without worrying about who has a smartphone and who has not, or not yet. A given user might sign-in with a browser-based, “hand-free” method from her usual computer(s) and use mobile-based authentication in the rare cases when she connects from a new or not trusted device – even if she has no signal or WiFi on her mobile phone.
Low friction. More use. Less risk.
Unlike legacy 2FA solutions, inWebo methods do not add to the password-based authentication friction, and in most situations even reduce it. Since there is no additional friction, the question is no longer whether or not to request 2FA or step-up authentication for a given transaction (based on some estimation of the risk of not requesting it). There is indeed strictly nothing to win in taking that risk.
A turnkey solution.
Authenticating users, all things considered, is an easy task. There is a lot of technology available for this, as well as standards, RFCs, industry alliances, vendors, and smart developers. The challenge that your organization faces with 2FA is to turn all these technology options into a managed service. This involves integration, testing, provisioning, on-boarding, user support, administration, audit, usage data analysis… Most activities that large organizations already run for their in-house and sanctioned applications, with a lots of processes, tools, and resources.
We made sure that these processes are covered in our solution. Thanks to our API, you can still execute them from the existing tools. Provisioning and on-boarding can be fully handled from your identity management platform. User support from your service management platform. Correlation from your SIEM. And so on.
However, since all these processes can also be managed directly from our administration console, you do not need to integrate our API from day one. Actually, there are good chances that you can start without any integration at all. For user provisioning, you need an automated solution. IWDS (inWebo Directory Sync) is precisely made for this purpose, helping synchronize users, groups, and policies with your inWebo authentication service. Logs can be generated and exported manually if you want to start without integrating the log collect API. Built-in and customizable on-boarding tools will help you roll out 2FA to users without creating workflows for this. And so on.
Implementing our 2FA Solution is much easier than you would have imagined.
Available, robust, certified.
Since you expect the authentication service to be always available, we engineered fully redundant platforms. A platform is a cluster of several (currently 3) independent server infrastructures distributed in distinct certified datacenters. We could lose connectivity to all but one servers without any impact on the authentication service. Unlike most solutions, our platforms do not rely on any single provider. This architecture has resulted in 100% service availability in the last 5 years. As a comparison, services such as Gmail or AWS have lower availability rates.
2FA security is not a given. As a user, you need to know a secret and own a device, which feels more secure than password-based authentication. But as an attacker, your options for account takeover are not substantially different (you can read our white-paper for more details on this topic). What makes a 2FA solution secure is its design and its implementation, both user- and server-side. Our patented algorithms implementation confer a level of security that most CISOs and security specialists we have met did not expect, especially from a software-based solution. In our platforms, authentication algorithms run within security appliances (also known as Hardware Security Modules, HSMs), protecting against server-side attacks or abuses. Unlike traditional Cloud-based authentication solutions, inWebo really controls and protects the complete chain.