2FA or not 2FA

A few weeks ago I received an unsolicited email from the Belgian Center for Cyber Security. It starts with the statement that 80% of cyber attacks could be avoided if 2FA was active and then says literally that If you only use a username and password for your remote logins, you're a sitting duck.

This is not true, username and password are no less secure than 2FA. In a way, they are more secure. I know this is controversial, but please bear with me, and I will explain CCB assumptions, my assumptions, and how it all makes sense.

CCB assumes that people can not be trusted with passwords. Over the years, the most popular passwords have been 123456 and password, closely followed by 12345678 and qwerty. Research has proven time and again that we use weak passwords whenever possible.

But hold on. These same people behave reasonably and optimally. Whenever they start using a new website or app, its value is close to zero, so it it an optimal strategy to use a weak password. More often than not, the interaction is unique or spaced in time so much that it makes no sense to save the password at all. When I visit a website I have not visited for years, my old password usually does not work anymore, and I have to reset it.

I have a workflow for auto-generating passwords and storing them in a password manager, but it is totally reasonable to expect other strategies for occasional users:

Resume vs Curriculum Vitae

Old farts like me often have long and detailed LinkedIn profiles that we just copy as Curriculum Vitae when applying for leadership roles.

This is based on two assumptions:

  • People are good at glancing over long texts, reading between lines and forming opinions.
  • Automated resume ranking tools are better at extracting data from long and detailed curriculum vitae rather than one-page resumes.

Both are wrong:

  • HR are not people. Senior HR partners do not read CVs, junior HR may not be as skilled as your Software Engineering pals at reading at drawing conclusions. Your CV has to be digested into a shorter resume for them.
  • None except big tech uses automated resume ranking tools, and even these let junior HR filter the results.

So better:

  • Use your long and detailed CV to feed to ChatGPT so that it tailors it to the individual job description.
  • Assume that people reading your resume are less skilled.

Finally, a curriculum vitae can be roughly translated from Latin as the course of one's life while resume is... well, a resume of your course of life, tailored to a particular situation.

Use one or the other when appropriate.

Tags: 

Adaptive delivery for websites: a forgotten concept

Back in 2011 my team built a news website with adaptive delivery. It loaded a small html page with a JavaScript that checked the screen size and user agent, then based on whether the user was on a phone, a tablet or a desktop, downloaded and displayed the content crafted for that particular device. It then left a cookie to avoid the extra round-trip for returning visitors.

Nowadays people tend to adapt the design to devices with CSS frameworks and flexbox layout, but this does not always reduce traffic and CPU time for low-powered devices.

While our engineering feat was adorable and I praised the team for the achievement, this architecture did not last. The editorial team did not want to maintain essentially 3 different content layouts daily, the marketing team was not willing to compromise on ads on smaller screens.

None was happy except the readers.

Falsehoods people believe about email

Not everyone has an email.

A businesswoman once proudly shown me a dumbphone and said that she does not have a personal email, only a corporate one. That persuaded me for a while, until I learned that her husband was prosecuted for money laundering around the same time. So yes, not everyone has email, but those who don't are few and they have very good reasons.

Email is unsecure

Aside from spam and automated emails, pretty much all email typed interactively in an email client is encrypted between the sender and the receiver.

We could have a long technical discussion here about the opportunistic encryption of STARTTLS or about the market share of Google, Microsoft and Apple, but the reality is that is is protected for all practical purposes that matter to ordinary people. That is, it is impossible to view and modify in transit emails that are written by individuals.

You can impersonate anyone in an email

Long gone are the days when you could send a mail from gates@microsoft.com from your personal computer. To start with, port 25 is probably blocked for sending at your ISP. Then, even if you managed to send an email, it will be probably rejected as coming from a residential range of IP addresses. But even if you send a mail from Amazon SES, then the receiving SMTP server will use SPF and DMARC to check if Amazon SES can send emails on behalf of @microsoft.com and it won't.

Tags: 

Hetzher vs AWS

I moved a business of ~100 FTEs from AWS to Hetzner once. Aside from the migration cost, the price was roughly 25% of AWS. I left many years ago, the business switched frameworks since then but they stayed on Hetzner.

Thinking again of this old story I now realize that the biggest gain was not monetary, but human. For years, that business could retain skilled engineers who had the opportunity to work closer to bare metal, caring about the nitty-gritty technical details of backups, failover and high availability.

And they did not even cost much. That they had so much leeway in designing the system instead of "relying on the cloud" was a major retainer.

PHP must die

One thing PHP got right is its 'PHP must die' mode of operation where every request spawns a new process (ok, not a process anymore but still an isolated execution environment that lasts until the response is served.

Java, Ruby, C#, etc are mostly used for application servers and this massively complicates everything.

For an engineer, it feels like one-process-per-request model, even with php-fpm and other optimizations should be much harder to scale than Java applications servers, but the reality is different.

I've spent many years doing PHP and Java-based development. Often times in parallel, having PHP projects on the side and earning money in Java development.

At some point, I had a stint of several years doing exclusively PHP-based work.

Every single time, PHP projects I worked on were serving orders of magnitude more people orders of magnitude cheaper than Java-based projects.

And when I say "orders of magnitude", it is not an exaggeration but sad truth.

I am now in the Java land again, because pay is better. My current project has already burnt several millions serving 20 secretaries that handle 1000 individual cases each year.

My mind is with the PHP project I sold several years ago when it was serving 120,000 people at the cost of a few hundred euros per year + my labor, which was essentially free, but if I could slap my usual daily rate on it, it would still be somewhere between 20,000 and 30,000€/year.

Even this blog is written using Drupal 7, a 14-years old PHP software that still works perfectly well and needs little maintenance. Go find a similar Java piece of software.

The strange origin of ISO20022 abbreviations

One of my favorite watercooler stories is about the origin of ISO20022 abbreviations.

ISO20022 is the XML-based format to exchange messages in inter-banking networks like SWIFT or SEPA., It replaced the old, ASN.1 inspired format. You can see both side by side here:

Notice the strange element names. Cdtr stands for Creditor, Nm for Name... for the most part, the abbreviations are easy to guess, but the obvious question is, why do they use abbreviations to start with?

Turns out, the standard first used unabbreviated element names, but once SWIFT and banks started implementing it, multiple complaints were raised about the increased traffic and storage space. The complaints bubbled up to the Standards Department and were put in a panel discussion during the yearly SWIFT conference. Where suits decided that the best way to fix the situation is to abbreviate the element names.

The rumor is, most abbreviations were penned on the spot in a way that created multiple naming clashes. That is, one can not automatically convert between abbreviated and unabbreviated XML without taking into account the context.

Anyway. The conferenced ended with the statement that the problem of message size has been solved.

And this is how we landed with words like Ccy forever ingrained into the banking vocabulary.

As any tech-savvy person may guess, the best way to make the XML smaller is to compress it. At the time, there was already the XML Fast Infoset standard which, among other things, defined how to optimize the compressor vocabulary by deducing it from the XML Schema, leading to higher compression rates.

Belgian diplomatic mail goes straight to NSA, right?

Ever since I worked on mailing lists, newsletters and transactional mails I have a habit of looking at mail server logs.

So did I today after sending a mail to the Belgian Foreign Ministry.

Turns out, my mail first passes through the servers of an US-based conglomerate that owns RSA Security, a company that has been publicly caught implementing backdoors for NSA.

Here's the exim mainlog:

diplobel.fed.be R=dnslookup T=remote_smtp H=primary.emea.email.fireeyecloud.com [3.123.5.10]
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 DN="C=US,ST=California,O=Musarubra US LLC,CN=mx.emea.email.fireeyecloud.com" C="250 2.0.0 3yW4eTU-47539-06g0D5C1032540783A662d84a39 mail accepted for delivery"

Yes, 3.123.5.10 is hosted in Germany, but so what?

The curse of Active Directory

I broadly divide organizations into

  1. Active Directory based
  2. Other

When I say Active Directory based, I do not mean Microsoft. Price Waterhouse Coopers for instance is not Active Directory based but they have Windows notebooks and use Google Workspace.

Active Directory promotes a certain way of decision making that bonds all such companies together. The management attend the same events, receive the same vendors, buy the same solutions from the same suppliers, and in general tend to structure their businesses in similar ways.

People around me are so used to Active Directory companies, that they do not see it, but I had a chance to work in a Silicon Valley style unicorn, local and European businesses that are not Active Directory based, and the difference is huge.

A company that by choice or by accident has no Active Directory also had a chance to reinvent its organisation, not just its IT. Such companies differ more from each other than Active Directory companies. Adaptation, improvisation are their competitive advantage.

The Worst Kind of Programmer

After 25 years of my career I came to understand that one particular type of programmers is the source of many problems in our industry. Here is the story of a project that was nearly destroyed by two such programmers. One of them was leading frontend development, the other – backend. While the rest of the team was slacking off because business requirements were in the works, these two chaps were working hard.

The frontend lead bootstrapped an Angular mono-repository with NX, Rx and other trendy technologies of the moment. The corporate environment did not lend itself easily to NX, but he pushed hard to solve or circumvent infrastructure problems by working with the domain expert. He set up a workflow that, while having Angular as the base framework, bore little resemblance to the official Angular tutorials.

The backend lead was no less motivated to bootstrap the Spring Boot project according to the corporate guidelines while adding a bit of a personal touch in the form of the Vavr library and a highly sophisticated hierarchy of JPA entities with multiple levels of inheritance, discriminators and generators. He then sprinkled it over with a hierarchy of validators based on both Spring Bean Validation and a third-party validation framework and polished with a trendy testing framework.

The rest of the team observed them in admiration.

Pages