Alexander Mikhailian

One of the nefarious aspects of Multi-Factor Authentication that I have not mentioned in my previous post on the subject is the risk of loosing Digital Sovereignty.

Authentication via a login and a password is well understood and is usually implemented within existing software. On the other hand, Multi-Factor authentication is often implemented via US-based third parties: Google, Facebook, Github, Linkedin, etc.

Countries can not implement Multi-Factor Authentication for their citizens themselves either. Case is point is Belgium, with the national service that provides authentication services relying on the US-based COTS software for most of its functionality.

There's a simple way to enforce Digital Sovereignty. Digital Services should be legally coerced to enable user login via a single string, akin to an API key already used by many services.

We all know that login/password combos are flawed, as users tend to choose weak passwords. For a lay person, the combination of a unique login and a weak password is enough to differentiate them from all other users. They do not know about rainbow tables nor multi-site attacks.

That same lay person presented with the need to have a single string as authentication key will ponder seriously on its length and randomness.

That string will not be called password but something else, be it passkey or key or passphrase. With a whole new world of assumptions and software helpers to generate them and securely store in key managers.

Amateur radio strives as a niche hobby. Clubs are actives and while the average age of radio amateurs is well over 60, there is a steady stream of newcomers. States and international organizations recognize the importance of nourishing amateur radio communities and there are endless possibilities to excel in this space.

In contrast, none yet cares about the possible demise of the hobbyist internet. It all started with phasing out HTTP in favour of HTTPS for good reasons: ISPs and network providers in some places of the world were injecting ads into HTTP pages. Big content providers and the general public wanted to stop that. They could have gone the legislative route but a technical solution to force all websites to use HTTPS was easier to implement. It was enough for Google to hint that it will penalize HTTP websites over HTTPS in search results, and everyone started to happily switch over to HTTPS.

Things did not stop there, though.

Browsers show content served over HTTP as not secure, making HTTPS the "default" and HTTP the visibly dangerous option, they limit many web APIs to sites served over HTTPS, they block or upgrade mixed-content by default (HTTPS sites cannot request HTTP-only resources anymore), they require HTTPS for HTTP/2 and HTTP/3, they increasingly attempt HTTPS to a site first even if linked or typed as HTTP, they warn about downloads over HTTP, and they're continuing to ratchet up such measures over time.

Lately, WhatsApp completely stopped opening HTTP urls.

This is an old fart's rant but it is none the less true.

In a recent interview, Linus Torvalds expressed regret about the pointless churn of SHA1 deprecation and this immediately reminded me of a similar, although much smaller pointless churn.

There was once a company-wide ban on SHA1, so a developer replaced SHA1 with SHA256 in a Hashcash implementation in one of the projects... without thinking of the negative side effects:

1. Hashcash became ~1.5..2 times slower
2. Third-party tooling could not be used anymore

The project uses this half-assed Hashcash implementation even today.

P.S. In case it is not clear, SHA1 was "broken" by generating two PDFs with identical SHA1 hashes but different content by adding random binary data to it. This is why the "attackers" used PDF and not C or Java code in the first place. And when they say broken, they mean that the SHA1 collision was generated 100,000 times faster that it should be, but it still took quite a lot of computing and coding.

Where there have been better SHA1 attacks since Google's, they are mostly impractical due to collision detection built into git for a long time already.

One thing about Peppol is how worryingly complex it is. I really hope it will be lobbied out in favor of a simpler solution.

As a reminder... remember the structured communication in your Belgian bank transfers? The one with triple pluses at the beginning and at the end? Like +++250/4171/01095+++.

The below shell script generates a unique one from today's year, month, day, hour and minute.

Things should not be more complex that they need be.'

DATE=date  +"%y%m%d%H%M"
CHECKSUM=printf "%02d" $((DATE%97?DATE%97:97))
echo $DATE$CHECKSUM |\
  sed -e 's#\([0-9]\{3\}\)\([0-9]\{4\}\)\([0-9]\{5\}\)#+++\1/\2/\3+++#'

Bert Hubert wrote at length and more openly about EU dependance on US software since the election of Trump. Not that engineers did not know about all that, but European IT is not run by engineers to the same extent as in US.

The situation is slightly different in Belgium:

1. We have our own government cloud. It runs on US software, but we are pretty much in control of it.
2. We have our own authentication service, but large parts of it run on COTS software from US.
3. We forgot how to host our own email, even the Ministry of Foreign Affairs and the Cabinet of the Prime Minister use M365.
4. We voluntarily gave up control over Belgian Certificate Authority to the US-based conglomerate DigiCert.

I guess things have to be fixed in the reverse order:

1. Take back control of Belgium Root CA
2. Host our own email
3. Own government auth
4. Migrate government cloud off Broadcom and IBM (anyway we need to migrate off Broadcom for money reasons)

That's a nice task list and luckily we already have an IT czar

P.S and Disclaimer: I indirectly work for the government, but everything above is public knowledge, for instance: