Why Companies House Director Identity Verification is not reliable

 The current approach by Companies House to Id Verification is to have the Director's email address cross checked by GOV.UK One Login System. If that process checks out with the supporting identity documentation, the Director is issued with a personal identity code. It is sent to the Director's registered email address. The Director is then supposed to tell Companies House the detail of the personal code  tied to the director's registered email address.

Here's the problem; the email address is not proof of identity. It can be hijacked, and the "Personal Code" can be learned by social engineering over the phone. The Companies House system should use a physical token, such as a Yubikey to store an encrypted digital certificate to identify individual people. The token should be plugged into the PC/Phone and verified when the Director is filing documents on the Companies House website.

Here's a story:

The Day the CEO’s Email Wasn’t the CEO’s Email

It started with a routine request.
Our client needed to verify the identity of a company director. Nothing unusual — just send a secure link to the director’s official address, ceo@bigco.com, and wait for the confirmation click.

A few minutes later, the “CEO” replied. The system marked the verification as complete. The paperwork moved forward.
Everything looked fine.

Except it wasn’t.

---

The Silent Switch

What no one realised was that, a week earlier, the company’s domain name — bigco.com — had been quietly hijacked.
The attacker had gained access to the registrar account where the domain was registered. With just a few clicks, they redirected the company’s email hosting to their own server.

Now, when someone sent a message to ceo@bigco.com, it didn’t go to the real CEO. It went to the attacker’s freshly created inbox.
From the outside, nothing looked suspicious. The address matched. The email arrived. The link was clicked.

The attacker had just passed identity verification with flying colours.

---

Why Email Alone Isn’t Enough

Email verification checks one thing:

Can this person receive a message at this address right now?

It doesn’t check:

• Whether they’ve always owned that address

• Whether the domain has been compromised

• Whether someone inside the company created a fake account

If the domain itself is taken over, email verification becomes a rubber stamp for the attacker.

---

How to Stay Ahead of the Trick

Here’s how to make sure you’re not fooled by the same move:

1. Don’t rely on email alone — Combine it with phone verification, government ID checks, or live video confirmation.

2. Monitor domain history — Flag sudden changes in registration, transfers, or name servers.

3. Use domain security — DNSSEC, SPF, DKIM, and DMARC make some attacks harder.

4. Bind identity to a digital certificate — Once verified, use cryptographic keys instead of just email for ongoing trust.

---

The Lesson

In this case, we caught the problem — but only because another system noticed the domain had been altered days earlier. Without that extra layer, the attacker could have slipped right through.

When it comes to verifying someone’s identity, email is a useful tool — but it’s like a lock on a screen door.
If the whole doorframe can be lifted off, the lock isn’t doing much.

---

.

Tuning a local NAS network adaptor on your PC.

🖥️ Lessons Learned: Optimizing Network Performance Between Windows and Synology NAS

If you've ever found yourself wondering why your lightning-fast Synology NAS isn’t delivering the speeds you expected to your Windows PC, you’re not alone. I recently went down the rabbit hole of **multi-NIC networking**, **Windows routing quirks**, and **Synology access issues** — and came out the other side with a surprisingly lean and fast setup.

Here’s a breakdown of the lessons learned — and what actually worked.

🚧 The Problem: Speed Bottlenecks & Wrong Interface Routing

Even with a high-performance Synology NAS equipped with a 10GbE card, and a PC connected via a 2.5GbE LAN port, I was seeing inconsistent performance — and even security alerts from the Synology when accessing the NAS web interface.

Turns out, the culprit was simple: **Windows was routing NAS traffic over the wrong network adapter** — often defaulting to Wi-Fi or a secondary Ethernet port on a different subnet.

🔧 Lesson 1: Understand the Windows Routing Table

Windows doesn’t always choose the fastest interface — it chooses based on **metrics** (priority numbers), and these can change on reboot or reconnection.

To view your routing table:

```bash

route print

This shows which interface Windows will use for a given destination. If the wrong adapter is prioritized, even local NAS access can go through Wi-Fi, causing unnecessary latency or even subnet mismatches.

### 🛣️ Lesson 2: Add a Static Route to the NAS

To ensure that all traffic to the NAS uses the correct (fast) adapter, add a **persistent static route** targeting just the NAS IP address:

```bash

route -p ADD [NAS IP] MASK 255.255.255.255 [NAS IP] IF [Interface Index] METRIC 5

```

* Replace `[NAS IP]` with the actual NAS IP.

* Use `route print` to find the `[Interface Index]` of your fast LAN adapter.

* The gateway and destination IP can be the same when the NAS is directly connected (e.g., via a dumb switch).

This route forces Windows to send all traffic to that NAS through the correct interface — no guesswork.

📉 Lesson 3: Stop Letting Windows Auto-Assign Metrics

Windows uses **"Automatic Metric"**, which attempts to prioritize interfaces based on link speed and other factors. It's often wrong — especially with mixed wired/Wi-Fi environments.

Manually set the interface metric:

```bash

netsh interface ipv4 set interface "[Interface Name]" metric=50

* Use a **lower metric** (e.g., 5) for your fast LAN adapter.

* Use **higher metrics** (e.g., 50–100) for Wi-Fi and fallback links.

* You can check existing metrics with:

```bash

netsh interface ipv4 show interfaces

This ensures Windows consistently prefers your high-speed link.

⚠️ Lesson 4: Subnet Mismatches Can Trigger NAS Security

If traffic to the NAS web interface comes from an unexpected subnet (e.g., your Wi-Fi network), Synology’s security features may block or flag it as a potential intrusion.

Routing all NAS traffic through the correct interface **eliminates false positives**, avoids login delays, and keeps the experience seamless.

⚡ The Result: Instant File Access, Stable Connections

After applying these fixes:

* JPG previews and media access became noticeably faster

* File transfers reached expected speeds over 2.5Gbps

* Synology no longer flagged normal access as suspicious

* The setup stayed stable even after rebooting

And no extra hardware was needed — just a better understanding of how Windows routes traffic.

🧠 Final Thoughts

You don't need to upgrade everything to 10GbE immediately. By tuning your **network routes** and **interface priorities**, you can unlock the full potential of your existing hardware — especially in mixed environments with multiple adapters or subnets.

If you’re running Windows and a Synology NAS, take an hour to review your routing table and metrics — it might save you hours of unexplained slowdowns or weird security behavior.