Alien Pastures

My thoughts on Slackware, life and everything

Page 2 of 173

Authenticators for 2FA

Multi-factor authentication: it is difficult to find high-profile websites these days that allow you to get away with a simple password-based login. It’s a sobering thought to realize how fast your ‘secure’ password can be hacked using sophisticated techniques that go way beyond brute-force cracking.

So, multi-factor authentication has become the rage. When you authenticate yourself, you increase the security of your account by providing multiple ‘factors‘: something you know (a password or PIN code); but also something you have (a cryptographic identification device or a token); and something you are (which could be a biometric quality such as a fingerprint or a face-iD).

When requiring 2 of these factors,  we talk of ‘two-factor authentication’, better known as ‘2FA’. Then, usually these will be the use of a password combined with the string of digits (a token) produced by an authenticator – whether that is a hardware device or a software implementation.

Popular are authenticator apps on smartphones. Google, Apple and Microsoft have their own authenticators which you can find in the respective stores for your smartphone. They are really easy to use and completely interchangeable – every authenticator will generate the exact same code for a website at the same moment in time.
The disadvantage of these authenticators becomes clear when you lose your smartphone… gone are the authentication codes you need to logon to your account! You’ll have to contact customer support to disable your 2FA so that you can access your data again, and then re-enable 2FA using an authenticator on your new phone.

That’s why Authy became so popular: this is an authenticator which stores your 2FA tokens securely in the company’s (Twilio) cloud storage. With Authy, you can authorize another device (smartphone or desktop) to generate the same 2FA codes for you. And as long as you remember the passphrase which encrypts your cloud-stored tokens, you do not need your original phone to authorize a new phone. Really convenient!
Unfortunately, Authy does not offer a way to export your tokens from their app.  It’s total vendor lock-in as it happens so often. And this month, Authy’s Windows and Linux desktop applications stop working, leaving only Android and iOS as supported platforms for your authenticator. On top of that, there was a recent breach of Authy’s cloud storage, leaking 30+ million email addresses associated with Authy accounts. That facilitates phishing attacks of course, but also, when you try to recover your account after the loss of your phone, Authy would first ask for your phone number and then continue granting access to the related account. Security updates to Authy apps on all platforms are now preventing application initialization based on your phone number, but it speaks a clear message: if you cannot fully trust the company providing you with one of two authentication factors, it may be time to switch.
But, the lack of export capability… indeed.

I have been using Authy for a couple of years, precisely because of the convenience it offers in the rare case that you lose (access to) your phone. Now being really pissed about the vendor lock-in, I went to look for an acceptable alternative authenticator. And I found Ente Auth. It is an open source 2FA authenticator, with the option (not mandatory) to create an account at Ente and sync your local 2FA tokens to their cloud server.  The end-to-end encryption used by Ente has been independently audited,  and the app allows you to both import (from other authenticators that are not Authy) as well as export your tokens. Ente’s server offers a read-only version of the authenticator interface which means, after login you can find your 2FA codes in your browser as well.
Switching from Authy to Ente Auth was a slow and painful proces, where I had to disable and re-enable 2FA on many web sites, but now I am ready to use Ente Auth exclusively. I can only highly recommend this app.

What’s more: Ente has also open-sourced its backend server. Ente is first and foremost an open source and secure alternative to Google Photos or iCloud: a place to store your photos and videos. But the authentication backend has been built as a standalone functionality from the start, which allowed the company to build Ente Auth around that backend. By open-sourcing the backend, you can actually have complete control over cloud-storage of your 2FA tokens! An account on ente.io is then not needed, you simply instruct the authenticator app to connect to your own server address.
And as a bonnus, you also get a secure and self-hosted alternative to Google Photos.

If there’s an interest in a follow-up article explaining how to self-host the Ente Auth server backend, let me know in the comments section below.

Have fun! Eric

Java updates for 2024Q2

Three weeks ago, the quarterly (security and stability) updates to various Java source code repositories were released. This means, new packages for OpenJDK versions 8, 11 and 17 are now in my Slackware repository. It took a while but hey, here they are.
For OpenJDK 8 I still use icedtea to compile the Java sources because it is convenient. The more modern versions like 11 and 17 are easier to compile (plus, icedtea does not support them).

All of these Java packages are nowadays targeting Slackware 15.0 and newer. So, get one of these if you have a need for it (and do not install more than one of them):

  • OpenJDK 8u412_b08 comes as an openjdk package.
  • OpenJDK 11.0.23_9 (aka the 11.0.23 General Availability release) comes as an openjdk11 package.
  • OpenJDK 17.0.11_9 (aka the 17.0.11 General Availability release) comes as an openjdk17 package.

Have fun!

Eric

Chromium update fixes 5th zero-day exploit for 2024

In Google’s release notes for the latest Chromium 124.0.6367.201 source code it is  mentioned that this release fixes a zero-day vulnerability. Beware: this is already the 5th zero-day which was reported and fixed in Chromium in 2024.

This vulnerability is already actively exploited in the wild, and is labeled CVE-2024-4671, so please upgrade your chromium and also ungoogled-chromium packages as soon as you can.

You can fetch my Slackware 15.0 and -current packages both for chromium and chromium-ungoogled . You can also visit mirror servers (like my own US server and in a short while, the UK mirror) in case my own server is not responding or too slow.

Note that I still do not provide 32bit package updates for Chromium and Chromium-ungoogled. It is a lot of work to find out how to compile rust and llvm on 32bit Slackware ‘the Google way’ and so far the solution has eluded me.
I need these custom rust and clang compilers to compile Chromium sources on 32bit.
And please don’t tell me ‘to look at how Debian does it’ – it does not help.

Cheers, Eric

In the works: LibreOffice 24.2.0 for Slackware 15.0

Apart from post-COVID syndrome there were some other setbacks lately, but those were mostly software-centered. Like the fact that I can not build a 32bit Chromium package for instance.
But also the realization that the latest LibreOffice 24.2.0 can no longer be compiled on Slackware 15.0 – its gcc 11.2.0 compiler is considered “too old”.
With the help and insight of Pat Volkerding I was able to compile LibreOffice on Slackware 15.0 anyhow:

I need to test the resulting binaries, and I still need to see whether I can repeat this on 32bit Slackware of course… but it looks promising.
More to follow.

Update 2024-Feb-21:

+--------------------------+
Wed Feb 21 12:41:50 UTC 2024
libreoffice: updated to 24.2.0 for Slackware 15.0 and -current.
Depends on openjdk17.
openjdk17: added v17.0.10_7 for Slackware 15.0 and newer.
Only install one version of Java!

Cheers, Eric

« Older posts Newer posts »

© 2024 Alien Pastures

Theme by Anders NorenUp ↑