One-time passwords based on Trusted Devices
Really quick set-up
We went the extra mile so that you can add inWebo secure authentication to your applications in no time. You don’t need to write code to get started, it’s all off the shelf. At later stage, integrating our APIs will help you automate some tasks (e.g. collect logs) or improve user experience (e.g. embed authentication directly in your sign-in pages or Apps).
Once you have registered an organization account here, you only need to configure a few things: application connectors, authentication methods, enrollment settings. You’re all set.
Smooth user and device enrollment
When a new username is provisioned in our platform for your service, we issue a Secure Site ID (= activation code) and send it to the user as a link in an invitation Email (there are many alternative scenarios, this one is the most popular). The link points to an enrollment page that gives the user the option to enroll her current browser and / or her smartphone as trusted devices. For that, she only needs to define or verify her PIN. You can fully customize the enrollment experience in the admin console.
Enrolling a browser (respectively, an authentication App on a smartphone) means that secret keys are generated in the background and securely exchanged between the browser (respectively, the smartphone) and our platform. These keys are then securely stored both in the trusted device and in our platform. Think of some kind of certificate, but much more secure and without the headache for admins and users. The keys are unique to the user, the trusted device, and your service. They will be used at the authentication stage.
Trusted devices, keys, and OTP
A trusted device is basically an authentication method. It’s used to generate on demand a unique password for a transaction (one-time password aka OTP). An OTP is calculated locally by the trusted device using mathematical cryptographic functions called hash functions. Simply put, hash functions transform the keys and the PIN entered by the user (and a few other things) into a device-dependent, transaction-specific, unique password. That password proves that the user owns the trusted device and knows the PIN but it doesn’t reveal anything about the keys or the PIN. Note that if the trusted device is a smartphone equipped with a fingerprint sensor, you can read this section replacing “enter her PIN” by “pressing her finger on the sensor”. Besides, since keys stored in a browser or an App are easily accessible, inWebo designed and patented an additional security layer by making the keys randomly dynamic.
Enough for the theory. Below are the real use cases.
Mobile offline OTP (the old-fashion way)
inWebo Authenticator App (= trusted device) is used as an offline one-time password (OTP) generator. The username and OTP are then submitted by the user in your authentication page. Our platform is interrogated via the application connector, validates the OTP, and authenticates the user.
This works in any circumstances, but fortunately, users almost never have to do that. There are much easier ways.
Push notifications (the trendy way)
The user submits her username in your authentication page. Our platform is interrogated via the application connector and sends a push notification to the registered inWebo Authenticator App (= trusted device) for that username. It wakes up and pops up the App on the user’s phone. She enters her PIN so that an OTP is generated by the App and submitted in the background to our platform for validation.
With the assumption that there’s enough signal, this method is much easier. However, the user still needs her phone each time she authenticates. This is fun initially, but users get rapidly tired of it. Can’t we do better?
Browser-based authentication (the frictionless way)
The browser used to access your service has been enrolled as a trusted device. Your authentication page detects it and displays inWebo browser-based authentication method, Virtual Authenticator. The user optionally checks the security information (as she would do for a website with an SSL certificate) and enters her PIN. An OTP is generated and submitted in the background to your server. Our platform is interrogated via the application connector, validates the OTP, and authenticates the user.
Much easier: the user didn’t need her phone since she was accessing your service from one of her usual devices – as we all always do.
Convergent authentication (the ultimate way)
Of course, your authentication page is now smart enough to test for any given transaction if the browser-based authentication method can be used, and to automatically propose alternative options (push notifications, mobile offline OTP) otherwise. The whole experience is seamless. Only with inWebo.