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?
As I understand it, the whole process in actually quite trivial:
Let me comment and explain some of the steps above:
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.
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.
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.
Nice.
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).
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.
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.