MasterKey FAQs
SaaS (software-as-a-service) where web applications are delivered to users via their browser, now spans almost every type of online business. Regardless of what the application does, if users login via their browser then MasterKey fits.
There is a wide range of web technologies but the MasterKey architecture works across all of them.
Password Managers, whilst convenient for the user, actually expose login credentials to any software in the browser. When they load encrypted credentials into a webform it is no longer encrypted, but is plane clear text. Password Managers actually expose user credentials, whether using a browser plugin or simply the browser remembering passwords,
MasterKey makes Password Manager redundant for the websites it is configured on. Users no longer need to remember or enter their credentials to this site, and it raises the security because the credentials are no longer entered through the local device.
“Identity and Access Management” is a major rationalization project for organizations. The goal to unify all systems as one, with each user having a unique digital identity, can take many man-years of work and frequently encounter unexpected issues. Passwordless Authentication is often not possible to deploy until this foundation layer is rolled out first.
MasterKey allows an organization to deploy Passwordless Authentication on each web application allowing a clean, secure interface to be deployed straight away. It doesn’t compete at the layer where users are receiving digital identity. Rather, it simply provides an alternative means of login to each web application.
Once an IAM transformation project has allocated digital certificates all users then MasterKey can be used to provide Passwordless Authentication to that new foundation.
This is virtually Self-Service. Simply request a Test Drive from us and we’ll send you an access code and the instructions to integrate the API.
Your front-end programmer needs to add 20-lines of code and setup a separate Test login page. It is little more than a cosmetic change to display a QR code on workstations.
This Test page can be shared with a few choice users as a Proof-of-Concept.
It can then be shared with a wider group of users as a Pilot.
The pilot can be progressively expanded in a Canary rollout, until all users are operating off it.
At the point where you are ready to commit and want your own brand on the user’s phone, then we request a formal contract. We in turn setup dedicated infrastructure for your organization.
WebAuthn, part of the FIDO2 standard, is an emerging standard allowing web applications to leverage user mobiles to prove that a person is present.
This can be though a fingerprint, a screen swipe patter, a physical device over Blue-Tooth, or simply a PIN. This data never leaves the users mobile so it not transmitted. Instead it uses Public Key Encryption.
This can be enabled at any time during the life of the system. Simply contact us and we’ll turn it on. The users mobile will prompted next time they login, to choose their preferred way to give proof-of-presence.
It can also be disabled at any time during the life of the system.
There is no technical risk. In a worst case scenario where MasterKey is cut-off for any reason, the user simply gets a normal login screen. They enter their user credentials and login.
There is no security risk. The user’s normal credential input is simply abstracted away so it never need to be entered again. It is controlled by your organizations webserver by triangulating with the users mobile, and the user themselves.
The integration is simply adding about 20-lines of code to make cosmetic change to the user login screen. It can be deployed immediately because it simply provides users an alternative login experience.
On workstations it is offered as a clear choice with three words, “Scan to Login”. When users decide to investigate and scan it their system logins.
On mobiles, it is virtually seamless as there is no QR code.
When done carefully there should be no Change Management with users. They simply adopt it by osmosis.
MasterKey provides Multi-Factor Authentication. Something you know (credentials), something you have (mobile phone) and something you are (fingerprint or such).
It achieves MFA in 1-invisible-step (not 2 steps), and without requiring any client software or user setup.
MasterKey operates from the webserver and so is relevant for any web based application where a user logs in via a browser.
The MasterKey system is actually the combination of the enterprises webserver working in conjunction with the users mobile phone browser, and a cloud hosted service which can reside anywhere. The users credentials flow through the system in a double-encoded-and-encrypted form that can never be deciphered if intercepted. The data can actually be stored anywhere and can only be converted into credentials inside the original webserver.
The MasterKey service is hosted in the cloud. Multiple instances can be deployed around the world for global organizations. If needed, the option exists to host the service on-premise.
The users mobile phone browser is harnessed and the phone creates a series of random strings to be used for encoding and public key encryption. The webserver is granted a unique identifier for each session. The combination of the webserver, the mobile, and optionally the users proof-of-presence (biometric scan or equivalence that shows the original user is present) are used to create a unique triangulation.
The user enters their credentials through an Encrypted Keyboard, which is an illusion set up on the mobile phone to capture cell coordinates which were created by the webserver.
Ultimately it is only double-encoded-and-encrypted cell references that flow through the system, and these can only be interpreted by the webserver, when the original triangulation of the webserver, the users mobile and the user themselves are present.
The user input is via an Encrypted Keyboard, an illusion on the users mobile that simple captures encoded cell references. This has no context or meaning outside the original webserver which set it up. As it flows through the system it is further encrypted and then encoded a second time.
The information can only be deciphered by the original webserver, and only when the original users mobile is present and initiates the recall, with the optional extra layer if chosen at setup, of requiring the user to prove they are also present (using WebAuthn).
Security on mobiles is extremely strong. This was very publically displayed in 2016 with the FBI unable to log into the San Bernadino terrorists phone.
MasterKey harnesses the users mobile and generates a number of elements in the mobile itself which never leave the device. These are used for public key encryption and encoding. Without physical access and being logged into the phone, these are not accessible.
The secure encrypted connection between the phone and the webserver can pass through enough information to uniquely identify the phone. This can be used as one of the factors in a multi-factor authentication system.
DNS poisoning can hijack a user device and take them to a rogue website.
However, if the user has previously logged in using MasterKey system, it won’t automatically log the user into a rogue website.
If the rogue website was to spoof a similar look alike technology and used this to trick the user into revealing their credentials, it still can’t capture all the elements in the phone used to identify this user and so the information captured wouldn’t be enough to impersonate the user.
Most Passwordless Authentication solutions require infrastructure changes at the backend which will be used to identify users. This may require a data migration, and even extra infrastructure. Client software is normally required to be downloaded, installed and configured by each user. These solutions can be set up to secure devices, as well as applications, etc.
MasterKey only applies to web services, where a user is entering data such as their credentials through a web browser.
- No backend system changes. MasterKey harnesses the existing login credentials and so doesn’t need to changes the backend authentication system. The authentication system is always behind a firewall so is never exposed directly to the Internet.
- No client software. MasterKey leverages the users mobile device browser so there’s nothing to install or configure.
MasterKey integration requires just 20-lines of code in the webserver to make what amounts to a cosmetic change. It can be deployed overnight, and when offered as a choice to users, adoption is by osmosis.
WebAuthn can be deployed without any system integration development. It can be selected as a choice during implementation or enabled at a later time.
WebAuthn is the standard, within the FIDO2 standard, that relates to web services.
When enabled, users are prompted to setup an additional security layer. This is dependent on the capabilities of the user’s device and may include a biometric fingerprint scan, a screen swipe pattern, blue-tooth device, or simply a PIN.
This content entered by the user, such as their fingerprint scan, stays local to their device and is never transmitted across the network. Public Key Encryption ties back to the MasterKey system.
When enabled the MasterKey provides Multi-Factor Authentication having: (i) something you know, (ii) something you have, and (iii) something you are.
MasterKey uses a ‘Clientless’ and Webserver-Controlled Architecture which requires:
- No backend authentication system changes (it doesn’t change username/passwords)
- No client software (nothing to download and install)
- No user setup (no Change Management as it’s intuitively obvious)
Users accessing their web login screen via a workstation are presented with a choice. They can continue to login as normal or can scan the QR code.
Users accessing their web login screen from a mobile or tablet, discover the system simply identifies them. No instructions are necessary.
Step 1: Setup a Test Drive by creating a separate Test Login page on a separate URL to the normal login page.
Step 2: Grant access to some choice users for a Proof-of-Concept.
Step 3a: Grant access to a larger number of users as a Pilot.
Step 3b: Expand the pilot and keep expanding in a Canary Rollout until all users are operating.
No Technical Risk: If the MasterKey system goes offline, then users can continue to login with their normal credentials.
No Security Risk: This is simply the users normal credential input, only its been separated from their device and never needs to be entered again.
We recommend simply deploying it as an optional choice for users.
- On workstations a QR code appears with three words: “Scan to Login”. The user can ignore this for days and continue to login with their normal credentials, but after a few days will get curious and scan to see what happens.
- On mobiles, the process is completely seamless and needs no explanation.
Good User Interface/User Experience design means that little explanation is necessary and that eliminates the need for training and change management.
MasterKey creates Multi-Factor Authentication in 1-invisible-step, unlike other 2FA solutions which require configuring software or adding a device. While most 2FA solutions add to the support burden, MasterKey doesn’t.
The existing procedures for adding, removing or changing credentials for users remain untouched. MasterKey is simply the interface between the user and the webserver.
Cloud Hosting is completely secured by the webserver and the users mobile.
The credentials flowing through the MasterKey system are double-encoded-and-encrypted. As such the credentials cannot be uses if ever intercepted, because they can be deciphered or injected.
The simplest implementation is to leverage BankVault’s cloud infrastructure. This can be expanded and distributed wordwide for large organizations.
The option exists for large enterprises to run an on-premise infrastructure. This generally requires a project to configure and so is a more expensive solution and if customized then it lays outside the stringent consistent standards of the rest of the BankVault infrastructure.
The goal is to minimize the training and support burden on IT staff. The simpler and more intuitive the process, then the less support requests there are on IT staff.
Empowering users by giving them choice, allows them to discover it when they are ready.
Yes, the normal login fields can be removed and made available on a subordinate webpage, however we recommend a gentle transition period allowing users to trial it without being forced and thus reducing the load on the IT team.
A user can borrow another users mobile/tablet and enter their credentials to login. A button gives them the choice to not save the credentials.
A user can also setup several devices with their credentials. There is no limitation to the number of devices.
Whenever WebAuthn is enabled, the users mobile prompts them for an additional security factor. The options presented will depend on the capability of the mobile. Generally they will have enabled some level of security on their mobile to being with. The user may be prompted to choose: Fingerprint scan, screen swipe pattern, a Blue-Tooth enabled device, or to enter a PIN.
If the users device isn’t capable of supporting these other modes, then it will prompt for a PIN.
All data entered by the user, whether a fingerprint scan or a PIN, remains local to the phone and is never transmitted across the network.
If the WebAuthn service is disabled during the life of a system, the users will first be prompted to confirm their presence and then afterward won’t be asked to show this again.
