MagicEndpoint provides secure,
passwordless multi-factor authentication
 

MagicEndpoint uses Bluetooth and biometrics on a user’s phone

Transcript

This video shows some of MagicEndpoint’s methods and concepts for endpoint access with multi-factor authentication, here using a phone. For remote access, authentication can be passwordless, even with no user action. The endpoint is the authentication: more secure than any other multi-factor authentication devices or methods.

Here the user logs in at pre-boot using a Bluetooth connection to the user’s phone. With a simple tap on the phone to authorize, this unlocks the user’s SecureDoc key file. Then, using SecureDoc single sign-on functionality, the device authenticates the user into the Windows desktop via the user’s unlocked SecureDoc key file with no user action on the laptop at all. Based on the messages that appear, the SecureDoc local key file and MagicEndpoint are logged in and available to use.

The user opens a browser and logs into Zoom using MagicEndpoint. The MagicEndpoint identity server appears to handle the authentication. The request UID appears briefly, then the user is immediately logged in, again with no user action. Let’s examine what has happened during login to Zoom. The first step is pre-association. The IdP checks in this first step that the browser ID belongs to the expected endpoint. Next, the IDP will show the unique request UID in the browser.

The next step is the intention. Using the persistent connection, some steps are performed to verify that the endpoint and therefore the user intended to request services from this service provider. First, the client will start looking for that unique request UID. It finds it and sends it back. Next, the endpoint is validated using the FIDO protocol. To do this, the IdP will check it and, if it’s correct, it will send back a unique challenge value. The client will sign the challenge using its private key and send the signed value back as its response to the challenge. The IdP will check the response against the public keys it has stored. Once it determines the signed response is the same as the original challenge, then the authentication request is accepted and authorized.

Here the user opens the Cisco VPN Connect application and connects. This uses MagicEndpoint with SAML-based authentication — again with no user action. Here, SecureDoc credential provider is configured to authenticate the user’s RDP session via MagicEndpoint silently in the background. In this last example, where SecureDoc single sign-on is not configured, the user can use the device’s Bluetooth connection to the phone to both authenticate at pre-boot and at Windows without any user interaction with the laptop and only a simple tap on the phone to authorize access. As we can see from the foregoing examples, MagicEndpoint, MagicEndpoint IdP, and SecureDoc can combine in highly secure yet easy-to-use ways to provide truly next-generation authentication functionality. For more information on MagicEndpoint, please contact us.

The user inserts a YubiKey token into a USB port on this laptop. He logs into Windows using his password. The user is prompted to convert his SecureDoc key file to token-based authentication. He enters the key file password, enters the token’s PIN, and logs into the token. A message confirms his key file has been converted to token protection.

The user powers on his computer and inserts his YubiKey token into a USB port. When SecureDoc pre-boot log-on panel appears, where the user is prompted for a password, he enters the YubiKey pin and successfully boots into Windows.

In this video, we’ll show how a YubiKey is used for logging into Windows. At the SecureDoc credential provider panel, the user inserts his YubiKey token into a USB port. The user enters the YubiKey PIN and successfully logs into the Windows desktop. This user is logging into Windows for the first time. The relevant keys will be generated right after this login and then a pop-up appears prompting the user to convert from a password-protected key file to a phone-protected key file. A pop-up request for authorization appears on the phone screen. Registration is complete once the user taps on authorize. From now on, this phone can be used for Windows and SecureDoc pre-boot login, even if the device is off the network.

In this session, we’ll demonstrate how a user who does not have access to his registered phone, whether misplaced lost or stolen. That user can still recover access to their device using SecureDoc’s challenge-response access recovery functionality. To do this, the user will read the challenge data over the phone to the SES administrator. The administrator provides the response string, which the user enters into the screen, permitting the device to load Windows. SecureDoc’s single sign-on will sign the user into Windows automatically, following a successful challenge response recovery. Once at Windows, the user is prompted to set a new password, which will be a temporary measure until they get a new phone and register that.

Once the new phone is available, the user will be prompted to register the new phone. Now that the new phone’s key is used for authentication, to illustrate use of the new phone-based authentication, the user can now log into SecureDoc control center using the phone app. The first user logs into Windows using the phone to authenticate. When there are multiple phones and users registered on the same device, the phone near the laptop that has the app running will get the pop-up requesting login approval. Here the user opens the OpenVPN application and clicks on login with SSO, which, in our example, uses Ping Identity. It gets redirected to the Ping Identity portal and there he or she clicks on the MagicEndpoint IdP to do the authentication for Ping Identity as the delegated IdP.

MagicEndpoint finds the right TPM key for this user and uses it to authenticate the user into the application via public key cryptography and no action required by the user at all. The user is logged in and we can see the OpenVPN ID of this user at the top right corner. The log will show our IdP has identified the right user, ad1, with the corresponding TPM key. Now user ad1 logs out and closes the WinMagic authenticator app on the phone and will perform the same steps for user ad2. Again, this user opens the OpenVPN application and clicks on login with SSO. The request gets redirected to the Ping Identity portal and, again, the user clicks on MagicEndpoint IdP to do the authentication for Ping Identity as the delegated IdP.

MagicEndpoint again finds the right TPM key for this user and uses it to authenticate the user into the application. User ad2 is logged in and we can see the OpenVPN ID of this user at the top right corner. The log will show our IdP has identified the right user ad2 with the corresponding TPM key.

Here we have another device: a loner laptop which our user has never used before. The administrator had prepared this laptop with SecureDoc, MagicEndpoint is installed, it has been encrypted and configured for use. This laptop is given to the same user as above and this is the first time this user logs into this laptop. The user logs in at Windows with his user ID and password. Since this is the first time this user has logged into this device, SecureDoc creates a key file for him and MagicEndpoint is automatically registered.

Let’s explore the logs to see what’s happening behind the scenes. We’ve overlaid some annotated screenshots of example log entries. We’ll begin with registering a user on MagicEndpoint IdP. First, the MagicEndpoint profile dictates in SDMode equals one, that it is integrated with SecureDoc. Then it recognizes there is no MagicEndpoint key file for this user and tries to create one, checking also to determine if this user has a SecureDoc encryption key file, after which it creates a MagicEndpoint device key file for this user. Lastly, it determines if the user has a key in the context of the domain the user belongs to and, if not, it creates one. On the CTAP module, having just been requested to create a credential by the MagicEndpoint control application just discussed, it creates a non-duplicable IdP TPM key. Control then returns to the MagicEndpoint control application on the endpoint device. This registers that it has received the IdP non-duplicable credential TPM key from the CTAP module and below that the public portion of the credential has been sent to the server. And so, registration is complete.

In this video, we’ll show how the user can log into an application, such as Office 365, on a device that doesn’t have any of our clients installed. As you can see, the phone screen is mirrored on the side of the video. As soon as the user clicks on sign in, a prompt will be sent to their phone asking the user to authorize this access. Once authorized, the user is logged in successfully.

The MagicEndpoint administrative console provides administrators with useful dashboards and reports that show the deployment status user-and-device enrollments within their entire environment. These dashboards can, for example, identify devices that do and don’t have MagicEndpoint installed. Also, for user registration, there’s a similar pie chart which can show the users that are either registered or for those who have MagicEndpoint installed which users might not be registered or have not yet completed the registration process. By clicking on a pie chart section, the administrator can drill down into a report showing, in this case, which users are using MagicEndpoint. Ideally, these pie charts should trend towards 100% deployed as users and devices are registered with MagicEndpoint so administrators can focus on those pie chart slices that track “lack of compliance.” Similarly, there’s a pie chart at lower right that tracks phone enrollment. Phones can be used for out-of-band access, unmanaged devices or even for recovery purposes making it important, where your policy defines the use of phones, that you target those users who have not completed their phone registration process.

Looking now at the top menu, there are several reports that can be accessed directly. These can be printed out or sent via email to team leads for example to help manage any stragglers. Lastly, in addition to the dashboard and reports, there’s also a log section, permitting administrators to track activities such as unsuccessful logins or as an aid in troubleshooting.

Suggested Videos

MagicEndpoint Passwordless Authentication

MagicEndpoint Demo: Multi-user with Ping Federate

SANS Zero Trust Solutions Forum 2023 Presentation

keyboard_arrow_up