# 4.16. Security¶

## 4.16.1. Privileges¶

quasardb does not need administrative privileges. Running the daemon as an account with administrative privileges is strongly discouraged.

quasardb only needs the following privileges:

• The ability to listen on a TCP port. The default port is 2836.
• Read and write-permission on the hard drive to persist entries. The default location is ./db/.
• Read and write-permission to its log files, if enabled. Log files are disabled by default.

For more information on how to change the quasardb daemon configuration for your environment, see quasardb daemon.

## 4.16.2. Authentication¶

QuasarDB has a built-in authentication mechanism based on asymetric cryptography. The performance impact of authentication on performance is negligible for the great majority of use cases.

Authentication only implies the exchange of small messages between the client and the server at the establishment of the connection.

..note::
The key exchange algorithm used is X25519. Authentication is made using Poly1305 MAC. The implementation is based on libsodium.

When configuring a cluster, the administrator must generate a long-term cluster key pair that will be reused for the nodes within the cluster, the public key part will be used by the clients connecting to the cluster, whereas the secret key should only be kept on the server and must never be communicated to any client (see quasardb cluster key generator).

The admnistrator then must add users to the cluster (see quasardb user adder). Users cannot chose their password, instead, they will receive a security token they must use to authenticate to the cluster. This security token must not be shared with anyone and be kept safe.

The server does not need to keep a copy of this security token, meaning that if the user list is stolen, it cannot be used to connect to the server.

It is possible to completely disable security and authentication, for example for test clusters or clusters running in physically secure environments.

## 4.16.3. Traffic encryption¶

QuasarDB has built-in support for full traffic encryption as well as message integrity. Traffic encryption requires authentication to be turned on.

Note

Traffic is encrypted using AES GCM with a 256-bit key. It requires the AES-NI instructions or equivalent. Thus, it is not available on all platforms.

Because traffic encryption can have a significant performance impact, it is turned off by default.

## 4.16.4. Perfect forward secrecy¶

The QuasarDB security protocol provides perfect forward secrecy by default. This means that communications recorded in the past cannot be decoded should any of the long-term private keys be compromised.

Each client connecting to the cluster uses a two phase authentication where a temporary, short-term key pair is generated and exchanged using the long-term keys to generate a symmetric session key.

## 4.16.5. Denial of Service (DoS) protection¶

The quasardb protocol, especially the serialization layer, has been designed to resist buffer overflows and most of current denial of service (DoS) attacks. Keep in mind, however, that quasardb is designed to accept large amounts of requests or arbitraty sizes and will therefore not limit incoming or outgoing requests in any way.

QuasarDB limits on the client and on the server the maximum message size that is allowed to be transmitted by setting a maximum value to the network buffers size. The default value is 25 MB. Because of protocol compression, larger amounts of data may be allowed to go through the network in one message. This value is configurable (network buffer sizes) and needs to be changed both in the server and in the client to transmit larger messages (see quasardb daemon and C).

There is no limit to the configurable maximum message size, however excessively large values may cause out of memory errors.