Secure by default

The security debacle. As a database user or administrator, you may have learnt that MongoDB recently took a very serious hit. A hit of over 28,000 hacked installs.

If you tried MongoDB you probably found out that it’s very easy to install and get started. This ease of use was at the heart of MongoDB and probably explains the popularity they enjoyed.

The problem, is that by default MongoDB was in a very unsecure mode with all your data accessible to everyone.

It’s not entirely their fault. One should not expose a database server directly to the Internet! However the in-depth security principle dictates that you should design your security so that it can resist one or several security shortcomings.

It’s easy to criticize MongoDB, but many other databases have the same problem. For example with MySQL it’s very easy to accidentally store your passwords in plain text in the database.

Why this fiasco? First security is hard. Secondly, security measures usually add to the complexity of a product. Are you willing to add friction when the attention span of your potential customer is so short?

Safety and security at QuasarDB

QuasarDB was born in market finance and responsible for millions of dollars of operations from the first day it went into operation.

Simply put, the requirement of QuasarDB were:

• The database must deliver first class performance
• The database must deliver first class reliability
• The database must deliver first class security
• While you’re at it, prove the Riemann hypothesis

Luckily, we managed to negotiate one of these requirements out.

The difficulty is that reliability and security have a negative impact of performance. For example, if you need to cipher the data you send to the database to guarantee confidentiality, this is an extra step and no matter how optimized it can be, it’s still more work to be done.

Also, if you need to make sure the data is written to disk, this means you can’t just buffer the input and acknowledge the write. You must wait for the disk to actually record the write.

Secure by default

The first version didn’t have all the security bell and whistles, but everything we did, we did it with security in mind.

Here is a non-exhaustive list:

• Our protocol has been designed to resist a wide range of denial of service attacks
• We have fuzzing in our continuous integration chain
• We use coding practice that greatly reduce, if not eliminate, buffer and integer overflows
• We had our code audited by security experts to look for security vulnerabilities
• By default, all daemons are bound to the loopback address and are not accessible from the outside
• It’s not possible to bind the daemon to the “any” address
• When using a random number for security purposes, it comes out of cryptographically strong pseudo random number generator (PRNG)

Cryptographically Strong authentication

There was however one piece missing: authentication. Since QuasarDB was running on dedicated infrastructure, the need for authentication was not very present, and we could get away without it.

Also, we wanted to get authentication right. No quick and dirty feature that could be broken easily and give a false impression of security. Remember, an attacker can be very motivated to get access to the data kept inside QuasarDB.

Today, we are very happy to announce that starting with QuasarDB 2.1.0, cryptographically strong authentication and confidentiality is available and yes, you guessed it, enabled by default.

Fast and secure

When designing the secure protocol of QuasarDB, the team quickly evacuated SSL/TLS.

Although high quality implementation are emerging (LibreSSL, BoringSSL…), the protocol is way too slow and complicated.

A client authenticated TLS handshake requires almost 15 messages to be exchanged. The client and the server will exchange certificates, agree on the cipher suite to use, ask how the kids are doing, and what the world is coming to.

Inefficiency, isn’t our cup of tea, and as always, our target was: do the impossible.

That’s why we designed a protocol, based on NaCl, that only need the client to send one message that could fit in a tweet, the server to respond with one message that could also fit in a tweet, in order to secure the link even against extremely motivated and well equipped attackers.

Only the server can decipher the message sent by the client, and only the client can decipher the message sent by the server. Messages are digitally signed to prevent forgery and increase the difficulty of Man-in-The-Middle attacks (MITM).

User and password being so last century, you authenticate with a certificate that can be encoded in a short printable string.

It’s not that we don’t trust you to choose strong passwords, it’s just that we believe you have better things to do.

How far will we go?

Your certificate was compromised? No worries, we guarantee Perfect Forward Secrecy meaning that should someone have recorded all past communications, they will not be able to decrypt them. Just ask your administrator to generate a new certificate and you’re all set!

Worried that an attacker might trash the memory of the server so that server puts sensitive keys into the swap file? Very unlikely, as we put them in specifically reserved areas not to be paged out, we zero out keys after usage, and on install we configure the system to minimize swapping.

Wonder how to set up security? If you use one of our installers, we generate, on install, all the certificates you need and setup the cluster in such a way that it is not possible to connect without a valid client certificate. Because, it’s easy to miss a step, even with a tutorial.

And yes, we still bind it by default to the loopback address, because, you know, in-depth security.

Availability

Authentication is currently available in our nightly build. If you are a QuasarDB customer or part of the beta program, this feature will be available in the forthcoming 2.1.0 release.

As for the Riemann hypothesis… Well, maybe we can’t solve everything.