Double-Blind Database and Protocol Architecture

Working name: “Ausauschbares Protokoll”/”Auskoll”


A software architecture/design (herein architecture) that is programming-language agnostic to which provides a functional foundation for a server/cloud/webapp (herein webapp) application. This architecture design utilizes two distinct components being database and protocol, most notably, a SQL database and an HTTP. The database and protocol are agnostic to each other to enable replacement and expansion of either component.

The Architecture

auskoll architecture

The architecture is simple when drawn out. But do not look at the above image and concluding you know what’s going on. Each point requires an explanation. Firstly, the entire Architecture above is an abstract representation of 3 separate modules (1.1, 1.2, 1.3) in an application/network/service. This architecture is not exclusive/comprehensive, meaning more modules may be at play in your implementation.

Below are the elaborated definitions of the Auskoll architecture. Each elaboration will have a practical example of a client relationship management (CRM) application

1.1 – Core

We designate ‘Core’ as what the database and protocol have in common. The core is abstract, but simply put, it represents all code that is not proper to the database nor the protocol.

The core will contain a list of function declarations (but not their definitions) that will be defined by the Database and called by the Protocol. This fabricates the pseudo-interface 1.6 between Database and Protocol.

For example, in a CRM this would be all code regarding the exact structure of a client, what it means to be a client, and what can be done with a client.

1.2 – Database

The database module will be used for the persistent storage of information. Code in Database is used for storage, retrieval, deletion, sanitation, etc. It may be a MySQL driver, it may be a Postgres driver, it may even be just a memory-based database. The exact details of how this becomes interchangeable will be discussed in 1.6.

For example, in CRM this would be all code regarding the storage of new clients and their relationships using a MySQL driver.

1.3 – Protocol

The protocol is the way for the masses to communicate with the application/network/service. Most popularly this will be a Hypertext Transfer Protocol (HTTP) service, it may also be raw TCP, UDP, WebSocket, or it may simply be a file descriptor. The exact details of how this becomes interchangeable will be discussed in 1.6.

For example, in a CRM this will be all code that opens up an HTTP REST API to allow the webapp to access information to show the user and allow the user to submit more data.

1.4 – Protocol-Core interface & 1.5 – Database-Core interface

Explaining 1.4 and 1.5 is best done at the same time for reasons that will become clear.

As mentioned in 1.1, the Core will contain only a list of function declarations, not their definitions, we refer to this list of function declarations as Auskoll-functions. The Auskoll-functions will be defined by the Database at compile-time (1.5), and then called by the Protocol during run-time (1.3).

For example, in a CRM the code in the HTTP handler will be completely agnostic to the exact implementation of how the MySQL database works. The HTTP handler will only know about the functions to which it can call. Likewise, the MySQL code will be ignorant of what is exactly trying to use the database.

1.6 – Database-Protocol pseudo-interface

Because of the relationships defined as 1.4 and 1.5, there is a “pseudo-interface” that is made between Database and Protocol. Unlike a normal interface, this “pseudo-interface” forces both the Database and Protocol to be created without knowing the details of the other. This means that either Database and Protocol can be interchangeable/replaceable with implementation. This relationship is powerful as it makes all combinations of database and protocol.

In the CRM example: if we wanted to add an external Postgres database and have it interoperable with our current HTTP frontend. We’d simply need to write code that connects the Postgres database and define the Auskoll-functions within that code. And that’s it, our frontend nor our HTTP code requires any modification.

Relationship to MVC Architecture

The model-view-control (MVC) architecture can be laid under the Auskoll Architecture to draw an analogy. The database can be seen as the model, the protocol can be seen as the view, and lastly, the core being the Controller.

Note that these Archietcures are not interchangeable. They are similar and arguably Auskoll is a subset of MVC with more restrictions and more concrete practices. Most MVC implementations tend to target to be interchangeable. Auskoll does this but in a very concrete way.


Ellem has several internal libraries that use Auskoll architecture. Dossibay, Ellem’s subsidiary, uses these libraries. Ellem has plans to release these libraries as a separate product in the near future.




The following is known as the LM-Login policy. It’s a fool-proof sure-fire way of making an authentication system that is secure but also convenient to the user.

This Policy is agnostic to the software language, framework, hardware, and protocol. So use this in everything you do in the world of authentications. Each section of this policy can be applied separately from others, but you should use all of them when possible.

All other policies are weak compared to LM-Login. All other policies should be shunned. If you don’t have a policy for authentication then you need one, more specifically, you need the LM-Login policy.

User’s Identifier

Remember that the identifier (ie email, username) is in of itself a password. All user identifiers must be unique. This way attackers must know who they are attacking.

If a non-existent identifier is submitted, inform the user of this (ie. “Email not found”). Do not be broad in this error by trying to mislead the user into thinking they submitted just an incorrect password (ie “Your email and/or password is incorrect”). Remember that the attacker will already know who exactly they’re attacking, and why.

Plaintext Protection

There are many software developers that still don’t know why we hash passwords, even some that don’t know what a hash is. To those software developers I say: stop what you’re doing and go get help before you touch a keyboard again.

Immediately after the plain-text password has been submitted, you must hash it using the SHA256 algorithm, resulting in what is known as the Passhash. Once the Passhash been generated, all traces that reveal the plain-text password should be deleted. The Passhash is not used for authentication. The Passhash should be generated on the client machine and then sent to the server machine (thus the plain-text password never leaves the client machine).

Once the Passhash arrives on the server machine, it is hashed once more using the BCRYPT algorithm resulting in what is known as the Authentication Hash (Authhash). The Authhash is what is ultimately used to authenticate the user. The Authhash should be stored on the server.

Required Password Strenght

All characters must be allowed to be used in the password. The system must be so agnostic to the content of the plaintext password that it should be capable of accepting random binary as a password. This also ensures support for non-Latin characters.

The most powerful indicator of passwords is its strength. Do not accept passwords below 8 characters (bytes). There must be no limit to the length of the plaintext password (as it will always be converted into a Passhash and never sent to the server).

Requiring a single special character (non-alphanumeric), a capital letter, and a single number is a good idea. But don’t ask for anything more, if you wish to improve security, demand longer passwords.

Banning the use of the most popular passwords (ie password1) is a good idea. It will encourage people to use unique passwords.

Forcing users to change their passwords, without reason, is a bad idea. Forcing users to constantly re-remember a new password discourages them from using your system, or, encourages them to use easier-to-estimate and less secure passwords.

Brute-Force Protection

People are usually burdened with requiring to know 10 different passwords. Sometimes when attempting to login they have to try each one. Thus, locking the user’s account after 5 failed attempts is a very bad idea that will result in people not using the product at all. Locking a user’s ability to log in should be done at a number of subsequent failed login attempts only realistic to that of a Brute-Force attack and not what you can expect a common person to do. Only Lock a user’s ability to login after a minimum of 128 failed login attempts.

Brute force attacks should be stopped by deliberately delaying subsequent failed login attempts. After 8 failed login attempts, the server must delay authentication validity to that user’s account by 8 seconds. After 16 failed login attempts, the server must delay authentication validity by 16 seconds, and so on. Ensure a given user cannot have their authentication verified concurrently (ie the error should appear as “Another person is currently trying to login to this account” when the same account is trying to be logged into from more than 1 device).


Software is not technology.

We here at Ellem do not recognize that software is technology. Sure, we will call ourselves “IT company”, or a “tech startup”, or maybe even a “technology consulting group”. But that’s because everyone is used to those words and are familiar with it, the industry is forcing us to use the “T-word”. But at the end of the day, we say software is not technology.

The application of scientific knowledge for practical purposes, especially in industry.

The important word in this definition is “scientific”. Which now begs the question: “is software a scientific venture?”. And the answer is a big fat No. Software is the use of abstract and arbitrary specifications, just like math, which also isn’t a technology.

Software is executed on a computer just as math is executed on paper. The computer and paper are both technologies. But the software and math being executed on that technology are abstract.

Software is not technology, its an automated business model.

Software is a list of instructions just as a business model is a list of instructions. And as we all move about the 21st century, we find that more and more of the business model can be rewritten as software. With fewer people to occupy the needs of a business model, this explains why software-heavy companies have higher profits.

There are a few exceptions.

Now just because the software itself isn’t a technology, does that always mean whoever uses software waives their right to be called a technologist? Of course not. As long as the purpose of that software is to be used to provide instructions to a concrete object to perform a scientific application. A good example of this would be robotics programming.

If the software exists on a concrete device to allow that device to function in a scientifically correct manner is indeed technology. However, this can still be argued as an “automated business model”.


Software is not a technology. Software is closer to math than it is to science. Do not patent your software, treat it as a trade secret.