At Onboardbase, security is at the core of what we built and how we interact with third-party services. In this document, we will share the details about how we handle security to ensure enough transparency and help experts analyze our implementations and approaches.

Encryption

We use a combination of both AES-GCM and RSA to provide a secure hybrid security implementation - an implementation similar to SSL security mechanism.

Account/Login Sessions

Once an account has been authenticated, two RSA keys(public and private) are generated from the authenticating client, and upon successful confirmation of the authentication, the public key is shared with the server.

The private key is maintained on the client to further ensure confidentiality of any information the server would send to it afterward.

The generation of these public/private keys on each login session ensures that information shared with a client can only be read by that client alone, which secures the information against a MITM attack.

When the server receives a public key, it also generates its public/private RSA key authentication against the login session and sends the public key only to the client.

Both the client and server preserve their public/private keys but only share their public key with each other, which helps to enforce the integrity of encrypted information across the parties.

API Keys Passphrase

Service tokens are other means of authentication with Onboardbase. To enforce confidentiality, each service token is attached to a unique passphrase.

All data communicated via the API key authentication are encrypted, as shown via our public APIs. The end client must decrypt the data using the passphrase supplied when generating the API key to authenticate the request.

Algorithms

We use both RSA and AES-GCM algorithms to enforce our security rules.

RSA

RSA is asymmetric encryption, and at Onboardbase, we use it when data has to be communicated between two ends(client and server), and the data is prone to pass through an untrusted middle man like the internet.

We use a 4096 key length as recommended by NIST (NIST, 2014), ENISA (ENISA, 2014), ANSSI (ANSSI, 2007), and BSI (BSI, 2018).

Onboardbase relies on standard libraries from programming languages to help in this implementation. For example, Golang Crypto Libraries, Ruby RSA Library, and Node RSA.

AES-GCM

For symmetric data(which does not need to be communicated back to the sender), Onboardbase uses an AES-GCM algorithm with a 16bit padded passphrase. This can be seen in the response of our GET secrets API.

Onboardbase relies on standard libraries from programming languages to help in this implementation. For example, Golang AES-Crypto Libraries, Ruby RSA Library, and Node CryptoJS.

Authentication & Authorization

Email Confirmation

Onboardbase web app can be accessed with a registered email through email confirmation. We don't support the email/password authentication model because we know that passwords can be compromised, and some users might use weak passwords.

With emails / password-less flow, users have to visit a link that we send to them, which would give them secure access to their secrets via the web browser.

API Keys

Onboardbase secrets can be accessed via the API, which is secured via an API Key that can be generated from the account settings section using the web app.

API Keys are generated with a passcode, then used for secured and encrypted communication between the client calling the API and the server. Secrets retrieved via API Keys are decrypted using the AES algorithm with the passphrase of the API Key as the AES Key.

Device tokens

Onboardbase CLI is authenticated with a mechanism called device token. A device token is a unique token generated for any account attached to the CLI.

The device token authentication process follows the account login process, which generates RSA Keys for secure and encrypted communication between the CLI client and the Onboardbase server.

Service tokens

Service tokens are the preferred choice for cloud services where it is impossible to follow the CLI login process.

This token also has similar security and encryption features as the device tokens. The major difference is that Device tokens are generated via a CLI while the Service tokens are generated via the web app.

Server Security

TLS

Communication to and from Onboardbase servers is secured via the SSL/TLS.

Secrets and other credentials can only be communicated to clients that have implemented the HTTPS layer. And in addition to the encryption mechanism, this security feature further prevents Onboardbase from being prone to MITM attacks.