Security Best Practices

Securing your administrator access

TrustBuilder MFA is a strong authentication cloud service. The administration console access is highly protected and rely on our technology (browser token). Hence, it is important your administrators are aware of the following recommendations in order not to loose their access.

Please note that once your service is in “Production” state (i.e not during “Trial” period), TrustBuilder have no authority nor is not able to create/recreate any type of account on your service (including administrator profiles). In other words, TrustBuilder won't be able to help you in case of lost access to your administration console.

To prevent this situations to happen, we recommend you to follow the steps below :

1. Install and use our Helium Backup browser extension for the enrollment to persist in your browser

2. Always have two active TrustBuilder MFA token (your browser and your mobile phone by example)

3. Always have at least 2 different administrators for your TrustBuilder MFA service

4. It's strongly recommended to generate an API certificate and to keep it carefully in a secure place

1- Keep your browser enrolled / Helium backup

The administration console is a web console. You authenticate and log on it using the TrustBuilder MFA browser token (Helium or Virtual Authenticator). In order to keep you access to the administration, you have to keep you web browser enrolled.

To keep your browser enrolled, it's strongly recommended not to clean your cookies/localstorage. If your browser permit it, you can also whitelist the 2 following domains :

• www.myinwebo.com

• ult-inwebo.com

An additional security is to install our browser extension : Helium Backup.

You will find here detailed information about web browser enrollment persistence and Helium Backup.

2- Activate a second device

It is strongly recommended you enroll a second TrustBuilder MFA token as soon as you can.

You probably have already enrolled your main web browser, we recommend you to enroll a second one. Your mobile phone is probably the better choice at this stage.

Download the TrustBuilder Authenticator application (Mobile or PC): https://www.trustbuilder.com/app-downloads

3- Enroll a second administrator (or more)

Create one (or more) administrator account(s) for your colleague(s) if possible. It is probably one of the best advice we can give to you.

To do so:

1. log on to the administration console (https://www.myinwebo.com/console/ )

2. under the 'Service Users' tab, click the 'Add a new user' button

3. fill-in the different fields, especially the 'login' and 'email address', select 'Send an activation email' and finally choose 'Administrator' in the 'USER SERVICE ROLE' dropdown list.

4. click on 'Save' to validate the administrator account creation.

Congratulations, you are done. 

4- Generate and keep a TrustBuilder MFA API certificate for emergency use

You can do a lot of things by using our https API, and especially generate new activation codes or create new TrustBuilder MFA accounts on the service.

The access to the API is protected by an SSL certificate authentication. Thus, you have to generate and download a client certificate to be able to use the API. Additionally, the access to the API can also be protected by an IP address filter, set up on the administration console.

Here is the process to generate a client certificate for the TrustBuilder MFA API :

1. log on to the administration console https://www.myinwebo.com/console/

2. under the 'Secure Sites' tab, click the 'Download a new certificate for the API' button

3. give it an explicit name, choose the rights (provisioning read/write mandatory), type a 'Certificate passphrase' and keep it in a secure place as you will need it to invoke the API, choose a validity period

4. finally select PKCS12 format (.p12) and click on 'Download' to validate the certificate creation and proceed to download.

Store this certificate and its passphrase carefully in a secured place.

Prevent access to your information

In order to prevent any unauthenticated person from retrieving information about your company, here are our recommendations:

• Name your service without explicitly writing your company name. e.g: my company name is TrustBuilder → I will name my service “TB_company”

You can edit your service name from the admin console, in the Service Parameters tab > “Edit service name”.

• When your service is created, there is a secure site created by default. Please, delete the demo Secure site as soon as you no longer use it.

  

• To test the OTP display, you can add a secure site of type “OTP display”. Please delete the “OTP Display” secure site as soon as you no longer use it.

Protect your users from Push Bombing attacks

Push bombing (or Prompt bombing or MFA fatigue) attacks use MFA to flood users with push notifications and hack their accounts. Whether intentionally or not, some end up accepting requests initiated by the hackers.

To prevent your users from accepting requests out of habit, force them to enter knowledge/inherence factor to validate operation. Forcing the user to enter its PIN code or biometrics to validate operation will limit the habit-based acceptance. In fact, the end user has to perform conscious action and will pay more attention to the context of the operation.

Below are some additional solutions we offer to help you protect your MFA users against Push Bombing attacks. The solutions differ depending on the type of MFA integration.

SAML 2.0 integration

To protect users from Push Bombing attacks with a TrustBuilder MFA SAML integration, we highly recommend setting the following parameters to "Yes": Browser Token Authentication and Push Authentication in the SAML connector.

See SAML integration > Configuration > Step 4

This adds an authentication factor: a hacker will not be able to send push notifications to a user without an enrolled browser token. If users want to use push notifications with the TrustBuilder Authenticator app to authenticate, they will need to enroll a browser token to trigger push notifications.

Microsoft Azure AD and OpenID Connect (OIDC) integrations

To protect users from Push Bombing attacks with a TrustBuilder MFA integration through OIDC or Azure AD, we highly recommend using the QR code authentication method. The QR code authentication method does not use push notifications, therefore it does not enable a push bombing scenario.

The QR code scanning feature is not yet available. It will be released soon.

To configure QR code authentication method:

• the QR code authentication should be enabled at the service parameter level (see Administration Console > Defining Service parameters > Configuring Authenticator app)

• in the connector parameter, set the Default Authentication URL to https://ult-inwebo.com/authentication-oidc/authenticator-with-qrcode . This is the page displaying the QR code

• users should use TrustBuilder Authenticator from version 6.31 to see the “Scan a QR code” menu.

Authentication API

To protect users from Push Bombing attacks using TrustBuilder MFA Authentication API, we highly recommend using the context parameter.

See Authentication API (SOAP and REST) > Authentication with REST API > PushAuthenticate

The context links the authentication request to the response. The person making the authentication request should check whether the information context displayed in the login screen matches the information context displayed on his mobile device.

Example:

• A context information “From WebExemple - 1.2.3.4 Paris” is displayed in the login screen

  

• The context information “From WebExemple - 1.2.3.4 Paris” in the push notification matches the context information displayed in the login screen