Security principles

Archiveopteryx is designed from the start with security in mind. Below we explain the basic design and how we arm the servers against some common types of attacks.


Archiveopteryx supports TLS wherever possible, to provide encrypted client-server communications, to guard against injection attacks, and to prevent message tampering and forgery.

Archiveopteryx also uses SASL for authentication, and supports challenge/response mechanisms (CRAM-MD5, DIGEST-MD5) that make it unnecessary to use cleartext passwords.

Optionally, Archiveopteryx can reject all use of cleartext passwords. We don't do this by default yet, because too many clients still insist on using insecure communication channels. A future version of Archiveopteryx will provide features to help migrate away from cleartext passwords.

Denial of service

Archiveopteryx servers are designed to prevent any single client from monopolising system resources (for example, by limiting the amount of memory allocated to each client or command), and can thus continue to serve other clients without degradation.

It is still possible to issue a DoS attack, e.g. by sending an unending stream of NOOP commands.

SQL injection

Database frontends are often vulnerable to attacks that cause them to compose and send unintended queries to the database server, because they are too trusting of query parameters obtained from clients. For example, logging in as

name'; delete * from users where ''='

could cause the server to delete all of its users if a query were composed simply by substituting the username into a template like

select * from users where name='$username';

Archiveopteryx defeats this attack by using prepared statements, where the database first parses SQL queries with placeholders for every parameter, and later obtains the actual values, which are used without any further processing. (This also provides a nice performance benefit, since each statement is parsed only once and generally used many times.)

In the attack described above, the database would look for the 37-character login name name'; delete * from users where ''=' in the users table. It would have no opportunity to interpret the string as SQL statements.

Buffer overflows, etc

Use of C strings and buffers have opened the way for many buffer overflows. Archiveopteryx uses proper ASCII and Unicode string classes for all string manipulation, and a single Buffer class for its I/O. These classes have extensive test suites. For example, our ASCII String class currently has about 700 lines of code, 1200 words of documentation and 1800-2600 tests.

The Archiveopteryx source code is strongly modular and well-documented. Each API is clearly specified. Modules cannot write into other modules' data. For example, only the Unicode String class can read/write its content. Even the 8-bit to Unicode converters cannot access the internal data of either String or UString, but must work via their APIs.

File system access

There have been many problems where servers accidentally grant more file system access than would be proper.

Archiveopteryx defends against these problems by having nothing to grant: User-facing servers have no access to the file system. The user-facing servers do all their file access at startup, then drop privileges, check that they can no longer access any file or directory, and only then do they start accepting user connections.

Two backend servers do have limited file system access (most importantly to the logfile). Both of those can be firewalled such that potentially hostile users cannot reach them.

Relevant links

In case you have any questions, please write to

About this page

Last modified: 2010-05-03