Hooray, there is a new exciting project!

There will be elections at the FernUniversität in Hagen in March next year. Among other things, the students will vote to decide on the composition of the student parliament. Political elections are the central means of a democracy: a group of people can express their will and appoint representatives. They give the office holders their legitimacy. And yet, there is a regular struggle to achieve a reasonable voter turnout. Especially in the elections for the student parliament or the student council of a university the participation is typically close to negligible. In the last elections at the FernUniversität in Hagen only ~ 11% of those eligible to vote exercised their right to vote.

One of the main reasons is probably the difficult assessment of the candidates. Students usually do not know the names on the lists, and are probably too busy to investigate the large number of candidates. Understandable! In 2014, after all, almost 150 candidates ran for the coveted seats in the student parliament.

In search of a solution to this problem, the AStA of the FernUniversität in Hagen wants a technical tool that makes it possible to compare individual positions with those of the candidates. So they want their own Wahl-O-Mat… (We from the coast are less fussy with words)

The AStA approached Tom and me, as we already demonstrated with DeinWal that we can realise something like this. They however did not only approach us, but also to developers of other decision-making tools: Everyone could apply for the project with a concept and an offer. After a tendering phase, the concepts were reviewed and apparently I was able to prevail. And now I am very happy that I have the chance to implement this exciting project! :)

From DeinWal I already learnt how much a matter of interpretation politics can be. My horizons are of course only limited and unfortunately I cannot absolve myself of some prejudices (even if I don’t like to admit it to myself). So I am happy that I was able to motivate a small crew for the project. The core team consists of 2 employees:

• Sophie Flack is a political scientist who not only specializes in party research, but also has an exceptionally international perspective. For example, Sophie studied in Germany, the Netherlands and Spain and most recently worked in the Consulate General of Chile.
• Martin Peters is a DevOps engineer and software developer who has an impressive feeling for web applications. He works for a company in the maritime logistics and tracking industry. Martin focuses on the development of modern web applications, the optimization of development processes and the analysis of stream data. With Martin I already did some cool projects in the past.

In addition, a few helpers will support us if necessary:

• For the protection of your personal data, we have brought competent support into the team with the data-protection-concern-beam Benjamin Winter. He helps us to find the stumbling blocks on that subject and to get them out of the way.
• The mathematician and data scientist Saptarshi Bej from the University of Rostock pays attention that we don’t do mistakes when developing the evaluations.
• Last but not least, Tom Theile is also available for discussions. Unfortunatelly, for private reasons he cannot join full-time.

Since the concept of DeinWal is a bit different (and very special), we decided to name the new platform differently. We already have some funny ideas, but a final decision is still pending. A little whale will definitely be included, but we won’t reveal more yet! :)

In any case, the contracts are all signed, and we are highly motivated to develop a tool that will support the students of the FernUniversität in Hagen in making their next choice. In particular, we would also like to show that these “technical aids” can be implemented in a data-protection-friendly and barrier-free manner, but do not need to be boring!

I’m looking forward to see how much innovation we can incorporate into the tool without losing focus and clarity!

So, whale ahoi!

# On the Complexity of Passwords

Nowadays, many applications and services run remotely somewhere on the Internet. In order to use the tools, you usually need to authenticate yourself with a user name and password. The complexer the password the safe your account. There are several ways to make a password complex. For example, you can choose characters from many different character classes: small letters, capital letters, numbers, special characters. Or you can use an extraordinarily long password, for example a sentence like ‘my pigeon loves to jump with the sunglasses of my neighbour on Sundays’. The password will be even more secure if the sentence contains a spelling mistake, and if it reveals something embarrassing it will be easier to remember the sentence :)

I claim that the password sentence above is much more secure than the password a0%Al;k/m (and various password analysis tools support my claim). Consequently, it is even more vexing when the service providers have annoying requirements for a password: it must, for example, consist of lower case letters, upper case letters, digits and be at least 8 and at most 20 characters long. I absolutely cannot understand why some providers put a ceiling on the length of a password!? My secure password sentence above would be rejected, but the rather insecure password gets accepted.

## The password strength measured in terms of entropy

I wrote this article when I needed to implement password authentication for one of my projects. However, instead of demanding different character classes and a minimum length I decided to demand a minimum complexity. Here, I measured the complexity in terms of theoretical entropy of the password: the entropy per character of a password, which contains characters from many character classes, is much higher than the entropy of a password, which only consists of numbers.

I calculate the entropy $\Eta$ (Greek letter Eta) as $\Eta = L\log_2 N$, with $L$ being the length of the password and $N$ being the size of the alphabet. Thus, a long password has a higher entropy than a short one; a password, which contains characters of different classes, has a higher entropy than a password, which contains only numbers. According to this method, the following passwords have a similar complexity:

• a0%Al;k/m (59.2647 bit entropy)
• 123456789012345678 (59.7947 bit entropy)

This allows service operators to define a minimum entropy for chosen passwords and users can chose passwords more liberally. I have attached my implementations below this article.

Finally, I have some general tips on choosing and storing passwords.

Of course, it is difficult to remember a different password for each service, especially if you want to have them very complex. Therefore, two tricks:

• Choose a password rule. For example a_0%Al;k/m, where you always replace the underscore with the first and last letter of the service you want to use the password for. For Twitter the password would be atr0%Al;k/m. This password will then fail on Facebook, where the password would be afk0%Al;k/m.
• Use a password manager! They are really good. If you do not trust the password safe, you can also remember a prefix or suffix to the passwords. Thus, the password manager only stores a part of the password (which can be complex and long), but you would have to enter a few more characters to use it. This means, even if the password database gets into the wrong hands, an attacker cannot do anything with it: None of the passwords work without your additional knowledge! :)

#### Use several factors

Many services offer a two-factor authentication. Usually you have to enter a code in addition to a password,

• which you will receive via SMS,
• which is calculated by an app, or
• which is generated by a hardware token.

This type of authentication is much more secure than a pure password.

## Implementation of the entropy check

Maybe my implementation helps someone?

Client side at an Angular frontend:

Server side at an PostgreSQL database:

# Share files over the network: smoothly and gracefully

You probably know the situation: You are sitting at a friend’s and/or client’s place and want to share some pictures or an installer. For small files, an e-mail may be justified, but even a few MB may take ages, if the mail server doesn’t refuse larger files at all. Those, who understand the path that an e-mail needs to follow, can certainly understand that this is an extremely inelegant solution.

An alternative is to copy the files to a USB stick, but who always has a stick with them? And then the stick may be formatted in a way that it is not readable on the target system…
Those solutions are rather like this… nineties… ;-)

It is much more elegant to start a webserver on your own laptop, which serves the files in the local network!

Installing and configuring a whole web server for such a nonsense? How fast should the operating system age??

Yes, exactly! But install it virtualised in a container, instead of natively on the laptop. Nowadays, every good IT professional has Docker or something similar on his laptop anyway, and an image from a web server is usually already downloaded (otherwise Docker loads it relatively quickly on first use).
This way, you can share any file very quickly and elegantly. For example, I prefer to use the Nginx web server (but of course you can also use the httpd of Apache, lighttpd and others). If I want to share the file /path/to/file.zip I just call:

Thada…! Now file.zip can be downloaded from the laptop as http://IP.OF.THE.LAPTOP/file.zip. If the laptop received a DNS name in the network it is even more comfortable.

Anyway, this is really amazingly fast and reliable in almost every network. Much faster than sending it to your mail server, which then forwards it to the next mail server, etc…
The only requirement is that the computers must be able to communicate with each other in the local network (a few networks prohibit client-to-client communications). Only files mounted into the container are shared. The webserver will not be able to see any other files on your laptop and, thus, will not accidentally share something else!
However, don’t forget to stop the container at the end of the session to avoid accidentally “sharing” files in the next network and/or accumulating sharing web servers ;-)
Thanks to the --rm flag everything is tidy again afterwards. The system stays young!

## More alternatives

• If both people use the same chat system, you can also quickly transfer files via Matrix or Threema or something like that.
• If you have a cloud (Nextcloud, Dropbox, Onedrive, Google Drive, Mega, etc), you can of course also share files conveniently via it. There are also a number of providers on the net where you can upload and share files without registration.

However, these approaches mean that the files have to leave the local infrastructure. This is not very nice in terms of security and privacy and tends to take longer.
The solution with the local web server in a docker container would certainly be preferable.

Translated with www.DeepL.com/Translator (free version)