$ \def\Vec#1{\mathbf{#1}} \def\vt#1{\Vec{v}_{#1}(t)} \def\v#1{\Vec{v}_{#1}} \def\vx#1{\Vec{x}_{#1}} \def\av{\bar{\Vec{v}}} \def\vdel{\Vec{\Delta}} $

Harald Kirsch

about this blog
Image Stitch App



GitHub introduces 2FA for everyone

Recently I got an email from GitHub that everyone is shortly forced to use two factor authentication (2FA). Everyone obvious includes me. As the second factor, apart from the normal password, they provide what is called time-base one-time password (TOTP). As can be expected these days, they suggest having an app on the phone that can do it. And indeed, checking the app stores, a whole armada of apps advertise to provide it. Hmmpf, yet another app. What does it actually do?

TOTP as second factor in very simple terms

As I understand it, the whole process in actually quite trivial:

  1. The website, in this case GitHub, presents you with a secret. I strongly assume and hope that it is specific to your account and not shared between accounts.
  2. You tell the app this secret.
  3. The app does its best to store the secret savely.
  4. When logging in to the website, after providing the normal, old-fashioned password, the second factor comes into play. The website wants you to ask the app for a one time password to enter. You ask the app, you get a few digits or characters, enter them much like a second password, and if the website verifies it as correct, you are logged in.

Let me comment and explain some of the steps above:

The Secret

This is, no surprise, just a sequence of characters. The website presents it as QR code or even lets you just type it into the app.

Storing the Secret Savely

I didn't try any specific app, but it is likely not much different from banking apps which require their own password on top of the mobile phones password or authentication. The weirdest thing is the strong suggestion to use a cloud based app which stores the secret, of course secured by yet another password of yours, on someone else's computer (aka cloud). Well, maybe these days it does not really matter any more. The storage on your phone is as open to your phone's app store owner as the cloud itself, I guess. So whether the app encrypts the secret on the phone's storage or into a cloud storage is very much the same when it come to who can extract the encrypted data when they want to try to decrypt it. Cloud storage owner, app store owner — what is the difference?

Insofar the statement that cloud storage is still available if you lose your phone may be a half valid point.

Time Based Password

This is probably the most interesting part, if anything. Read more details on the Internet, but this is the rough procedure: Use the secret together with the current time with, say, minute resolution in a fixed time zone, UTC, to create a hash value of 6 or more digits. That's the one time password. Provide it to the server which does the same with the secret assigned to you and the current time and compare the outcome. For more convenience and allow slighty deviating clocks, the previous and the next minute may be valid as well.

I don't want no reeking app

Yes, apps accrue by the dozens on mobile phones these days. Ehem, not on mine, really. And for the extra trivial shit described above, why another app? And when I am in front of the desktop, there is enough computer availabe right in front of me. And the phone may actually be in another room. Yes, believe it or not, sometimes I don't have it in arm's length reach. Must be old age, born in the previous millenium :-) So:

% apt-cache search totp

Turns out there is otpclient. And it stores the secret in an encrypted database. And it asks me where I want to have this database stored (think external USB drive). And it can read the presented QR code in several ways, like screenshot or clipboard. And it just works.



Fakten zur Energie

Bei der Diskussion um erneuerbare Energien ist es immer gut einige Fakten und Größenordnungen vor Augen zu haben. Insbesondere sind Meldungen in der Presse immer einordnungsbedürftig. Ist ein Jubelartikel zum Windpark mit 10MW zum Jubeln? Nein ist er nicht. Eine einzelne Windkraftanlage hat schon zwischen 5 und 18MW (Frühjahr 2023).

Große Windkraftanlage erhältlich "von der Stange", Frühjahr 2023

  • offshore 15MW, z.B. Vestas V236-15.0MW
  • offshore 18MW, CSSC Haizhuang H260-18.0

Jährlicher Energieverbrauch in Form von Strom in Deutschland

  • 500 TWh in 2022
  • Anstieg über die nächsten Jahr erwartet wegen Elektrifizierung auf 1000 TWh.


Energy Dome, Energiespeicher per Umsetzung zwischen flüssigem und gasförmigen CO$_2$.

  • Errichtung: 220€/kWh für
  • Kapazität und Leistung: 20MW$\times$10h

Vanadium Redox Flow

  • Errichtung: 430€/kWh
  • Kapazität und Leistung: 7MW$\times$4.3h


Why I hate Software Frameworks

Everyone seems to be using software frameworks these days and each has its own hype-culture, uniqness-claim, and provides an in-group for its followers. Being somewhat distrustful by nature I developed an aversion against software frameworks over the years. To be a bit more specific, I had to work with Spring, Spring Boot, Angular, Gradle and Reactor. So what I say below is inspired by those and may or may not apply to others.

I make a difference between a software framework and software library. Though the border is a bit blurry, a library is roughly a software framework without all the ugly stuff I mention below.

What is wrong with frameworks?

  1. They prescibe a way to set up your software, it is not up to you.
  2. They are full of magic behaviour supposed to make your live easier and to give you a fast start. Yet the downside of magic is that it is magic to you: you don't understand why and how it works. For a fast start, this looks great, things just happen, but beware, the first quirk is waiting for you. To fix it you need to read the documentation and the code and lots of misguided stackoverflow answers of people in the same situation as you without the stamina to actually understand what is going on.
  3. Doing things their way is easy only at the start. With every deviation from their way your work gets exponentially harder.
  4. The magic may stop working from one version to the next. Either because of a new bug, or a new feature, or a dependency incompatibility or your previous need to deviate from their way which now no longer works.

I contrast this all with a software library providing a well designed API. There is no magic, behaviour is invoked explicitly by calling into the API. Getting started is slightly harder, because some boilerplate code needs to be written to invoke the needed API functionality in the right order. Yet often the boilerplate is not as boilerplate as framework designers assume. There are always those quirky deviations from the assumed and enforced "standard" which force you to fight against framework magic, while the not-quite-boilerplate code you have to write when using a library is all yours to adapt to your needs.

In addition, when leaving a project alone for half a year and coming back, the boilerplate makes explicit what is going on. It can by understood easily again. With a framework, things, hopefully, just happen and you might have forgotten some of the magic details you had researched — until they stop to work or you need to change something.

Using a framework, you literally sell your soul and bet the future of your software on that one framework, since switching would require a complete rewrite. Call it vendor lock-in if you want. But not only with regards to your software. Also with regards to your knowledge and experience. The experience you gather comprises a lot of how to fight or subvert the framework magic to get it your way, not their assumed default way.

In contrast, with a well designed library API, chances are that the next best library covering a similar topic has a similar API. You learn how to use the API, not how to fight against off-by-epsilon magic behaviour. Switching your software to a similar library may actually be possible, while switching away from or to another framework is typically a 100% rewrite.