Security (b)log - English edition: February 2026

2026-02-27

Telco hacked

Image from Unsplash

Most data breaches and hacks are the kind of inconveniences that happen to other people. This time, however, if you live in the Netherlands, there’s a good chance you’re staring rather glumly at an email from your telecom provider. After all, Odido controls roughly one third of the Dutch mobile market. On top of that, they provide fixed internet connections to a million households. And if you’re a Ben customer, you’re out of luck too.

The news is receiving wide coverage in the media. Understandable, given the scale: 6.2 million accounts were stolen from Odido’s customer contact system. Some of those accounts belonged to people who hadn’t been customers for years. Odido discovered this when these individuals responded, puzzled, to the notification email the company sent them. But the sheer size isn’t the only reason to be concerned. The kind of leaked information matters too. It wasn’t just the “usual” personal data such as name, address and email address. This hack also exposed phone numbers, bank account numbers, passport information, citizen service numbers, and even records of payment arrears.

Roughly two million records – containing nearly 700,000 unique email addresses – have already been published, because Odido didn’t comply with the demand from the criminals, who call themselves ShinyHunters, to pay “a low seven‑figure amount” (that’s at least one million euros). And they’re threatening to leak even more data. Plenty of reasons for millions of people to be worried.

Media coverage of the incident mostly focuses on sympathy for Odido and its customers. What you hear much less about is how this could have happened. I do understand that journalists focus on the victims. But still: how did this happen?

Phishing, ladies and gentlemen. In every presentation I emphasize again and again how important it is that everyone is resilient against this form of cybercrime. At Odido, that resilience failed this time. The phish reached customer service employees (possibly at a call centre abroad), who fell for it and handed over their passwords. Even two‑factor authentication (2FA) wasn’t an obstacle: the criminals called the employees, pretended to be colleagues from IT, and obtained the second factor as well. ShinyHunters executed an impressive piece of social engineering here: they didn’t hack the computer system – they hacked the computer users.

They then proceeded to download data. A lot of data. There should have been an automatic emergency brake for that. It should never be possible for a customer service account to download such vast quantities of information at once. It appears that there was no monitoring in place. If that’s true, it means not only the organisational measures (training) failed, but also the technical ones. You can hardly blame anyone for the failure of training; carefully crafted phishing emails are almost indistinguishable from the real thing. Oh, how I would love to see that phish. Employees handing over their 2FA, however, is something that deserves extra attention.

Odido itself is being notably tight‑lipped. I expected a statement on the homepage of their website, but only after some digging I found the “Information page Odido cyber incident”. First, there’s an extremely short official statement. Underneath, in giant letters, they advertise the free protection against phishing and other threats that they offer to their customers (one wonders if they use it themselves…?). Only then comes a detailed explanation of what happened, and some do’s and don’t’s. The bottom line: criminals with access to the leaked data can impersonate you and carry out all sorts of actions at your expense. So, in the coming period, keep a close eye on the invoices you receive and check your bank account for unfamiliar direct debits.

In the FAQ they raise the question of whether Odido’s security was adequate. But they don’t really answer it. Instead, we get the usual platitudes: safety is our top priority, we continuously work on improvements, but yes, criminals are very clever too.

Whether Odido was, after all, still clever in securing its assets – personnel included – will undoubtedly be investigated thoroughly. But whether we’ll ever get to hear the answer is another matter.

And in the big bad world…

…I was unfortunately too busy with other matters today to fill this section.

2026-02-18

Size matters

Click on image to enlarge

Exactly one year ago, my colleague Alexander asked a question. Some topics take a little longer to mature. His question was about passwords and whether it’s really necessary to make them overly complex. He sent along a well‑known chart that illustrates how quickly passwords can be cracked. Let me break it down for you, because it contains a lot of interesting information.

I’ll start with the title. The key term is ‘brute‑force attack’. Brute force against what? Any system you want to log into contains a file with all user accounts. After all, the system must be able to check whether you’re allowed in. Unless its designer has been living under a rock, the passwords in that file are not stored in plain text. Otherwise, anyone who manages to steal the file would have free access. Instead, the passwords are stored in encrypted form. When you log in, the password you enter is encrypted as well, so it can be compared to the stored version.

An attacker needs many attempts to crack your password. If they try logging into a website with your account, your account will usually be locked after a few failed attempts. That lockout is a security measure against brute forcing. So, that approach gets the attacker nowhere. What they really want is the full password file, so they can attack it offline without getting locked out. Of course, they first have to break into the target system to steal it.

Let’s assume they succeed. They then use a powerful computer to attack the accounts in that file. The chart shows how long that would take. Vertically, the password length increases from four to eighteen characters. Horizontally, the number of possible characters increases. The first colourful column represents ten characters: the digits zero through nine. The next columns give you 26, then 52, then 62 characters. The last column represents all possible characters – digits, uppercase and lowercase letters, and symbols (! @ # $ % ^ & * ( ) - _ = + etc.) – about 94 characters (‘printable ASCII’).

In the top-left corner, you see that a four‑digit password offers no resistance at all. There are only ten thousand possible combinations, meaning the attacker needs about five thousand guesses on average. That’s just too easy. In the bottom‑right corner is the other extreme: eighteen characters chosen from 94 possible symbols. That gives you 3.28 × 10³⁵ possible passwords – roughly a three followed by 35 zeros. According to the table, a powerful cracking computer would need 463 trillion years to guess it. A trillion is a thousand billions; the universe is only 13.8 billion years old.

What I find far more interesting is that the table changes much more vertically than horizontally. In other words: length matters far more than complexity. If you make a numeric‑only password four times longer, the attacker suddenly needs two thousand years. Meanwhile, expanding the character set (at the same length) hardly affects the cracking time. And if you look at the row for fifteen characters, a password made up of only lowercase letters already takes nearly half a billion years to crack. That square could have been coloured green, as far as I’m concerned.

Conclusion: if a password is long enough, you don’t need to worry about complexity. Many systems insist you include at least one digit, one lowercase letter, one uppercase letter, and one symbol — but that’s unnecessary if your password is sufficiently long. Allow your password manager to generate and store those long passwords for you. For the few passwords you can’t store — such as the master password for your password manager — choose something you can remember but others can’t easily guess. For example, “You won’t hack my password” or “mhallfwwasmfwas” (Mary had a little lamb…).

And in the big bad world…

2026-02-13

Receipt required

Photo from author

Do you ever find yourself in Germany? And have you ever taken a close look at a receipt there? Well, I have. And what immediately caught my eye was the cryptographic information printed on it.

To be clear: when I talk about crypto, I mean cryptography, not digital money like bitcoin. Cryptography is the mathematical art of securing data, as someone at a conference recently put it. But what exactly was on that receipt, and more importantly: why?

There were long strings of letters and numbers, as you can see in the photo. My attention went straight to the ‘PublicKey’ line at the very bottom of the receipt. Behind it: a blob of 132 characters. The receipt also contains a similar string representing a digital signature. You don’t often see information about digital signatures printed on an analogue medium (the paper slip).

The reason lies in German law: the Kassensicherungsverordnung (Cash Register Security Ordinance, or oddly abbreviated KassenSichV). It requires electronic tills to be equipped with a Technische Sicherheitseinrichtung (TSE – Technical Security Module). The TSE prevents tampering with the till: every transaction is logged in order, assigned a sequential number, and digitally signed. This allows the Finanzamt (tax administration) to check for irregularities, such as missing receipts. A shopkeeper using a till without a certified TSE can be fined up to € 25,000 (almost US$ 30,000).

All that cryptographic work happens inside the register. But why print that information on the receipt? Because the receipt itself must also be verifiable. You as a customer won’t do anything with it – you may consider the fact that I noticed it a case of professional deformation. But the tax administration can run spot checks, for instance by sending in a mystery shopper who later has their receipt verified. In the past, retailers could hand the customer a perfectly decent-looking receipt while deleting or altering the transaction inside the system. That’s no longer possible: the digital signature would expose it immediately.

On more modern receipts, the printed TSE information has been replaced by a QR code. That makes the life of inspectors easier (even though it’s marketed as a paper-saving measure). Even more eco-friendly is the digital receipt which, very un‑German, is called a fiskaly receipt (they actually use the English word receipt). The customer scans a QR code on the till. But it can be even simpler: at the supermarket we visit from time to time to buy things they don’t have here or that are much cheaper there, you can receive the receipt directly in the store’s app.

That digitalisation is great, but I do see one problem. When I buy something with a warranty, I scan the receipt and store it under a meaningful filename on my computer. I do this for two reasons: printed receipts fade, and my computer can search for me. Digitally issued receipts, however, I never find back. Once you realise that, you then need to remember which shop sold you the product, so you can search the relevant app or website. To work around this, I now store a small file in my records noting where the product was purchased. Another tip for fellow administrative nerds: since clothing tends to break or fray, I store a photo of the garment alongside the scanned receipt. Then you always know which receipt belongs to which pair of trousers.

One more thing that stood out on the receipt from Shawarma Al‑Zaiem: the line ‘Es bediente Sie: LPADMIN’ (“You were served by”). The administrator was logged in at the till. Now, Al‑Zaiem is a small place where only two people were working, but still: using an admin account for routine operations is never a good idea.

Send me photos of your bewildered travel companions the next time you find yourself attentively studying your receipt in Germany (-;

And in the big bad world…

2026-02-06

On thin ice

Image from Unsplash

Freezing rain had been forecast. On the radar you could see a mighty precipitation area rolling in from the south. Like many colleagues, I decided to go home early. I got home dry and, more importantly, without slipping, and spent the rest of the afternoon watching how, in this region, things didn’t get nearly as bad as expected.

After work I was supposed to go for a run. However, the threat of freezing rain still lingered in the air (even though I hadn’t seen anyone slip in my street). So I decided not to run outside and instead put my treadmill into action. Safely exercising indoors. Added bonus: inside it was about twenty degrees (36 °F) warmer. Shorts and a light shirt would do just fine.

After twelve minutes and fifty seconds my athletic ambitions came to an abrupt end. I made a misstep: my right foot didn’t land on the belt but on the edge of the machine. The entire right side of my body suddenly stopped, while the next step – with the left foot – was already underway. You can imagine this didn’t end well. First my left knee hit the moving belt, then the right one. My left foot had meanwhile planted itself on the ground behind the treadmill. Which meant I stood still. While the belt kept running underneath me. With my knees still on it. It burned quite a bit.

Treadmills have a safety cord. One end has a clip you attach to your clothing, the other end a plug you stick into the control panel. If you fall, the plug should be pulled out by the cord so the belt stops. The cord turned out to be slightly too long for the position I had ended up in – the safety plug stayed in place. The belt kept spinning until I pulled the cord by hand.

My wife and daughter rushed in, worried, and a bit dazed I asked for two wet washcloths to cool my knees. Three days later, the left one is almost healed, but on the right one I’m currently missing about four centimeters (1.5”) of skin. Nothing dramatic, it’s just the occasional sting and the healing wound pulling a bit.

I learned two things. First: organizational measures can backfire. I chose not to go outside because I didn’t want to fall. And that is exactly what happened. Of course I try to project this onto my work (this is still the Security (b)log, right). Do we sometimes make decisions there that ultimately cause the very thing we tried to prevent? Those decisions are usually well thought-out, thoroughly discussed, and we’ve slept on them. We’re currently revising our password requirements. Obviously with the intention of making our employees’ accounts more secure. But we must be careful not to make things so difficult that people get ‘creative’. Communication and support are crucial when implementing changes that affect everyone personally.

Second: if technical security measures are not implemented well, they won’t work in every situation. The safety cord works perfectly if you fall straight backward off the belt, but not if your fall stops halfway. You have to be very clear about the purpose of a measure, and you must examine all possible scenarios. Only then may you expect the measure to do what you intended. Example: we’ve been encrypting our data and communications for years. But if you don’t take the coming of the quantum computer into account – one that can crack today’s encryption with ease – you remain vulnerable. Maybe not today, but certainly when the data you send now can be decrypted by unauthorized parties a few years from now.

Our daughter is celebrating her eighteenth birthday today and wants to drive to school*. We’ve taken all kinds of measures: she got her driver’s license, we practiced extensively with her, we agreed on rules. The car was recently checked. And we have expressed our trust in her. And yet, as parents, you’re relieved when she gets home safely. Because you know that measures don’t always work.

*: In the Netherlands, you can take driving lessons from the age of 16.5. Once you get your license, until your 18^th birthday you have to be accompanied by a registered driver who must be no younger than 27 years.