What can a fifty-year-old book teach us about cybersecurity? Written just as computing was beginning to enter the mainstream, The Electronic Criminals takes us into a terrifying new world of crime!

Fraud over Telex! Ransomware of physical tapes! Stealing passwords and hacking into mainframes!

The books has a strong start, but gently runs out of steam because there simply weren't many electronic criminals in the mid-1970s! Instead, the book is over-stuffed with "Catch Me If You Can" tales of chequebook fraud, stolen aeroplane tickets, and regular blackmail and bribery. It isn't quite a how-to guide for the budding fraudster, but it isn't too far off.

Nevertheless, there are some amazing and mind-boggling computer crimes described:

Computer print-outs concealed the massive fraud and fakery. Tapes were programmed so that computers would reject incriminating data and accept and produce only what would support the conspiracy. Computers were also used in playing hide-and-seek with investigators by switching data damaging to the swindlers from one code to another, just a step ahead of the authorities.

One common refrain is that the law of 1975 hadn't caught up with the reality of modern crime. In the above case, the…

… investors decided to sue IBM for $4 billion, claiming that the company’s inability to manufacture a swindle-proof computer had contributed to their loss. Despite the fact that IBM had claimed their computers are virtually tamper proof, the case was thrown out of court. Obviously no one can be expected to be perfect, not even an IBM computer.

And in another:

In a recent case in France the accused was charged with sabotage. He had intentionally erased valuable information recorded on a magnetic tape by passing it through a strong magnetic field. However, since the tape itself was undamaged the court ruled that no offense had been committed. The jury was directed to issue a verdict of “not guilty.”

Many of the "electronic" crimes are able to be facilitated by poor physical processes:

Computer center near London, England: Unguarded side door hooked open to allow employees to step out for fresh air. Top secret military and industrial information was stored in the center’s files.

Anyone who has done an ISO 27001 audit knows that pain!

It isn't just computers and data-tapes that are discussed. There's rather a large section on phone-tapping and eavesdropping bugs. Rather terrifyingly, there's also a section on what we might now call "Deep Fakes":

On tape recordings, words can be rearranged and new words can be built up from an assortment of syllables. The process is somewhat like fitting together bits of a jigsaw puzzle. Simply by inserting or deleting “nots” in a taped voice recording, affirmatives can be changed to negatives and negatives to affirmatives. Words can be borrowed from one part of a tape and fitted into another so the entire meaning is changed. By the same techniques, inflections of words can be altered.

Oh, and drone warfare!

Today there are infrared cameras that can indeed see you in the dark, even portable TV cameras that can record pictures by moonlight, and radio-controlled miniature aircraft (some that can hover like helicopters) to carry these cameras to subjects that someone wants to photograph.

As with any good book on the subject, it spends plenty of time talking about how to defend oneself from these attacks and the downside of protection:

Another scheme, called “hand-shaking,” requires the inquirer seeking information from the computer to correctly answer a personal question, something known only to him, before he can find out what he wants to know. This slows down the running of a business. I remember sitting in the office of a man who has a computer terminal on his desk. In the middle of our conversation a question came up and he said: “Wait a minute. I'll get the answer from our computer.” He put the question in by typing on the keyboard. The terminal’s screen lit up and displayed another question: “In what month was your mother-in-law born?”

It also predicts the rise of music and film piracy; albeit by analogue means.

Rather pleasingly, it doesn't just limit itself to crimes committed in the USA. It acknowledges the pervasive nature of criminality and goes into some detail about cases in the UK, France, Germany, and Italy.

It is always fascinating to look back on our industry's history. Much like 1999's Information Warfare and Security by Dorothy E. Denning, we have to constantly go back to see what assumptions we have baked in to our processes.

I'll leave you with this rather chilling excerpt from the prologue:

Our world is still a fine place in which to live—a better one perhaps than any previous generation has enjoyed. But some of the people in it are causing serious problems. In 1974 many people experienced diminishing respect for persons in high places who acted as if they were above the law, and this led to a loss of respect for the concept of leadership itself. We should not confuse diminishing respect for a president with respect for the presidency, for example. Our society needs people in high places. It cannot function without leadership at every level, from the head of a household to the manager of a business to a chief of state.

What is missing in our society today is the necessary preparation and training for the responsibilities of authority in high places. If parents in the home and people in business and government never learned the lessons of fair play when they were growing up, we cannot expect them to know how to play fair when they reach high places. Consequently we all suffer every time “the boss” makes expedient judgments rather than proper moral decisions.

If coming generations are to be spared the tragic consequences of even more widespread corruption, the teaching of morality in the family and in the school ought to be as important to us as curbing inflation and other socioeconomic problems. Our children should be taught how to deal with everyday actions fairly and ethically. They should be exposed to those philosophical and ethical concepts, with practical examples that illustrate the alternatives of right and wrong so that they are better able to cope.

This cybersecurity book is badly written, contains multiple offensive stereotypes, is technically inaccurate, and spends more time focussing on the author's love affair with the New York Times than almost anything else. Seriously, if you take a drink every time the book mentions the NYT, you'll spend most of the chapters drunk. Which, to be fair, is probably the best way to experience it.

The epilogue pre-emptively complains that "the technical community will argue I have over-generalized and over-simplicifed". I don't have a problem with that; it is essential to write about cybersecurity for the lay audience. But this book just gets things wrong. As a quick sample:

Some pushed to have his cybersecurity license stripped.

Does anyone know where I can get one of these fabled licenses?

Jobert would send discs flying out of Michiel’s hard drive from two hundred yards away.

If you can make a disc fly out of an HDD, something has gone very wrong!

It does become moderately interesting when the author stops gushing about the NYT and describes some of the implications behind the hacks which changed our world. The descriptions of Stuxnet, EternalBlue, and other cyberweapons are well done. But it quickly lapses back into lazy clichés.

For example, hackers are variously described thusly:

Every bar, at every conference, was reminiscent of the Mos Eisley cantina in Star Wars. Ponytailed hackers mingled with lawyers,

Their diet subsisted of sandwiches and Red Bull.

These young men, with their sunken, glowing eyes, lived through their screens.

hackers—pimply thirteen-year-olds in their parents’ basements, ponytailed coders from the web’s underbelly

Germans don’t do small talk, and they don’t do bullshit.

Then there's this:

To any woman who has ever complained about the ratio of females to males in tech, I say: try going to a hacking conference. With few exceptions, most hackers I met were men who showed very little interest in anything beyond code. And jiujitsu. Hackers love jiujitsu.

I don't even know where to start! Sure, the gender ratios are skewed, but every hacker I know has multiple interests and I don't think any of them include jiujitsu!

It's also sloppily edited. There are multiple odd typos and weird inconsistencies. For example:

Leonardo famously labeled himself with the Latin phrase senza lettere—without letters—because, unlike his Renaissance counterparts, he couldn’t read Latin.

He used the phrase "sanza lettere" - not "senza" - see Codex Atlanticus.

not the testosterone-fueled “boo-rah” soldier Hollywood had conditioned us to.

I can't find any reference to boo-rah outside of Hallowe'en articles.

Panetta told an audience on the USS Intrepid in New York. “They could derail passenger trains, or even more dangerous, derail passenger trains loaded with lethal chemicals..

That's not what he said. The author has cribbed a incorrect transcription from - of course! - the New York Times.

Do passenger trains tend to carry lethal chemicals? No, obviously not. It took me less than 5 minutes to find the original video. At 1h 8m 22s, Panetta clearly says "derail trains loaded with". No "passenger".

Littered throughout attackers’ code were references to the 1965 science fiction epic Dune, a Frank Herbert science fiction novel set in a not-too-distant future

I'm not a big enough nerd to have read Dune. But most scholars agree it is set in the far future.

A century and a half earlier, in 1949, he reminded the crowd, a dozen countries had come together to agree on basic rules of warfare.

This book was written in 2020. While 1949 is a long time ago, it isn't a century ago. Perhaps this is a reference to the original 1864 convention?

I'll begrudgingly admit that the book does a good job of explaining some of the problems facing the world as cyber-warfare takes hold of industries and nations. But it is hidden behind so much American hegemony and basic mistakes that I found it borderline unreadable. On the rare occasions that the author stops unnecessarily inserting themself (and the New York Bloody Times) into the story, it can be rather interesting.

This is too important a story to be written up this badly.

It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this, it uses the Ukranian KYCaid platform.

So far, so standard. But there's a small problem with how they both integrate.

I installed Chimoney's Android app and attempted to go through KYCaid's verification process. For some reason it hit me with this error message.

Well, I'd better click that email and report the problem.

Oh, that's odd. What happens if I click the protected link?

Huh! I guess I've been taken to Cloudflare's website. What happens if I click on the links on their page?

Looks like I can now visit any site on the web. If Cloudflare has a link to it, I can go there. For example, GitHub.

Why is this a problem?

MASTG-KNOW-0018: WebViews

One of the most important things to do when testing WebViews is to make sure that only trusted content can be loaded in it. Any newly loaded page could be potentially malicious, try to exploit any WebView bindings or try to phish the user. Unless you're developing a browser app, usually you'd like to restrict the pages being loaded to the domain of your app. A good practice is to prevent the user from even having the chance to input any URLs inside WebViews (which is the default on Android) nor navigate outside the trusted domains. Even when navigating on trusted domains there's still the risk that the user might encounter and click on other links to untrustworthy content

Emphasis added

A company's app is its sacred space. It shouldn't let anyone penetrate its inner sanctum because it has no control over what that 3rd party shows its customers.

There's nothing stopping an external service displaying a message like "To continue, please transfer 0.1 Bitcon to …"

(Of course, if your KYC provider - or their CDN - decides to turn evil then you probably have bigger problems!)

There are some other problems. It has long been known that people can use in-app browsers to circumvent restrictions. Some in-app browsers have insecure configurations which can be used for exploits. These sorts of "accidentally open" browsers are often considered to be a security vulnerability.

The Fix

Ideally, an Android app like this wouldn't use a web view. It should use a KYC provider's API rather than giving them wholesale control of the user experience.

But, suppose you do need a webview. What's the recommendation?

Boring old URl validation using Android's shouldOverrideUrlLoading() method.

Essentially, your app restricts what can be seen in the webview and rejects anything else.

Risk

Look, this is pretty low risk. A user would have to take several deliberate steps to find themselves in a place of danger.

Ultimately, it is "Code Smell" - part of the app is giving off a noxious whiff. That's something you cannot afford to have on a money transfer app. If this simple security fix wasn't implemented, what other horrors are lurking in the source code?

Contacting the company

There was no security.txt contact - nor anything on their website about reporting security bugs. I reached out to the CEO by email, but didn't hear back.

In desperation, I went on to Discord and asked in their support channel for help.

Unfortunately, that email address didn't exist.

I also tried contacting KYCaid, but they seemed unable or unwilling to help - and redirected me back to Chimoney.

As it has been over two month since I sent them video of this bug, I'm performing a responsible disclosure to make people aware of the problem.

My friend Sal has written a book! I was lucky enough to get early access to it.

Code, Chips and Control is an in depth look at cyber security. And I do mean in depth - this literally starts at the silicon wafer level! It isn't just about the trivial logic bugs which so often get exploited; this goes into the geopolitics of supply chains, the physics of satellite hackings, and the history of the way legal systems have developed with respect to computer security.

It is a little unforgiving - there are a lot of obscure acronyms to keep in your head and it dives straight in to the problems with semiconductors. This isn't a book for casual script-kiddies.

That said, Sal has an evocative turn of phrase when describing complex interactions:

To think about this, let’s bring out three chess boards onto a table in our minds. There is a single, invisible player - the adversary - on on side of that board. On the other side of the table there is a lot more commotion.

Governments huddle over one board. Security researchers cluster around another with disclosures, deadlines. Vendors and corporations share a third. The boards share the same table, the same global digital surface, their moves have always have lateral effects.

A public disclosure sacrificed on the researcher’s board becomes a backdoor that that advances a government’s checkmate. A patch delayed on the vendor’s board opens a flank for an adversary’s quiet advance. Disclosure is not a single match between attacker and defender. It is three simultaneous games being played out of sync.

She's (rightly) scathing about some of the corporate responses that we see to the security challenges of today:

In the modern enterprise, paperwork can be more lethal than malware. The result is a paradox: organizations are better at proving they responded to vulnerabilities than actually responding to them.

There are a few phrases I might get stencilled onto a t-shirt:

Email is not a protocol. It is a confession that the systems cannot speak [to each other].

It's rather hard to summarise but this is comprehensive survey of multiple aspects of computer security. You get a lot of breadth and a suitable amount of depth - if you can keep up with the pace.

Code, Chips and Control is available now on LeanPub.

Mostly.

A few weeks ago, I received this email from GitHub.

On the surface, this is a sensible email. They want all their members to only have strong 2FA and I still had SMS configured as a fallback method. Except, of course, I should not be a member. I should have been kicked out when I handed back my laptop and lanyard. There was still a bit of pandemic pandemonium about - but surely in the last few years someone should have audited the organisation's membership?

The JML process is critical to cybersecurity. There's no point having fancy controls if you don't revoke the permissions of people who are no longer entitled to access. On a fully integrated system this is (usually) easy - untick a box on Active Directory or whatever and *poof* the user is banned.

But with external systems the problem is harder. You now need to keep track of external usernames, synchronise them with internal names, periodically check them for updates, integrate with an API, and - in some cases - take manual action. It's clear that this particular bit of the NHS had slipped up. Looking through the private list of collaborators, there were many old accounts.

I was able to see all private collaborators:

I could see all private repositories:

I even had access to create new repositories - including special ones:

To be abundantly clear, there was no medical data on GitHub. There was no patient data available for me to view. Absolutely nothing medically sensitive was stored there. This isn't a GDPR or medical privacy issue. If I had made any changes to the code stored on there, it would never have made it to production. There were no API keys or sensitive data or passwords for me to exfiltrate. The NHS BSA is a business unit - not a medical unit.

Nevertheless, it is important that all parts of a large organisation are able to quickly and competently remove users once they have left.

Timeline

• 2025-10-17
  • Received GitHub email.
  • Visited https://www.nhs.uk/.well-known/security.txt to get details of how to raise security issues.
  • Raised the issue on HackerOne
• 2025-10-21
  • After triage, the issue was assigned directly to the BSA.
• 2025-10-31
  • I was removed from the organisation.
  • 
  • Requested permission to publish this post. No objection received.
• 2025-12-02
  • Published

Proton have release a swish new authenticator app for Android, iOS, Mac, Linux and Windows. Sadly, their open source repository doesn't allow for bug reports so I'm blogging in public instead.

The good news is, the majority of tests pass. It accepts a wide range of acceptable codes and refuses to store most broken ones. There are a few niggles though. None of these are severe security issues, but they probably ought to be fixed.

Very long codes

The maximum number of digits which can be generated by the standard TOTP algorithm is 10. Proton happily scans codes containing 1 - 9 digits, but complains about 10 digit codes. So this fails:

otpauth://totp/issuer%3Aaccount%20name?secret=QWERTYUIOP&digits=10&issuer=issuer&algorithm=SHA1&period=30

The TOTP RFC says:

Basically, the output of the HMAC-SHA-1 calculation is truncated to obtain user-friendly values

1.2. Background

But doesn't say how far to truncate.

There's nothing I can see in the spec that prevents an implementer using all 10.

Risk: The user may not be able to store a valid code.

Recommendation: Allow 10 digit codes.

Invalid Secrets

Here we get to yet another deficiency in the TOTP specification. How is a secret defined?

Google says the secret is:

an arbitrary key value encoded in Base32 according to RFC 3548. The padding specified in RFC 3548 section 2.2 is not required and should be omitted.

Whereas Apple says it is:

An arbitrary key value encoded in Base32. Secrets should be at least 160 bits.

Either way, the Base32 alphabet contains only uppercase letters and a few numbers. What happens if we give it a secret like QWERT!£$%^)*(YUIOP?

Proton Authenticator just accepts it. It stores the full secret but I'm not sure how it generates the code based on it.

Risk: The code may be generated incorrectly.

Recommendation: Warn the user that the secret may be invalid and that a correct 2FA code cannot be guaranteed.

Issuer Mismatch

In this example, the first issuer is example.com but the second issuer is microsoft.com

otpauth://totp/example.com%3Aaccount%20name?secret=QWERTYUIOP&digits=6&issuer=microsoft.com&algorithm=SHA1&period=30

What should the TOTP reader do with this? Proton chooses microsoft.com.

This is something which, again, is inconsistent between major providers.

Google says this parameter is:

Strongly Recommended The issuer parameter is a string value indicating the provider or service this account is associated with, URL-encoded according to RFC 3986. If the issuer parameter is absent, issuer information may be taken from the issuer prefix of the label. If both issuer parameter and issuer label prefix are present, they should be equal.

Apple merely says:

The domain of the site or app. The password manager uses this field to suggest credentials when setting up a new code generator.

Yubico equivocates with

The issuer parameter is recommended, but it can be absent. Also, the issuer parameter and issuer string in label should be equal.

Risk: The code may be displayed with the wrong issuer.

Recommendation: Warn the user that there are multiple issuers. Let them choose which one is correct.

Dealing With Defaults

What should a TOTP app do if there is missing information? Proton does the following:

• If the code has no number set for digits, it defaults to 6
• If the code has no time set for period, it defaults to 30
• If the code has no algorithm, it defaults to SHA1

Risk: Low. The user normally has to confirm with the issuer that the the TOTP code has been correctly stored.

Recommendation: Let the user know that the code has missing data and may not be correct.

Odd Labels

The label allows you to have multiple codes for the same service. For example Big Bank:Personal Account and Big Bank:Family Savings. The Google spec is slightly confusing:

The issuer prefix and account name should be separated by a literal or url-encoded colon, and optional spaces may precede the account name. Neither issuer nor account name may themselves contain a colon.

What happens if there are spaces before the account name?

otpauth://totp/Spaces:%20%20%20%20%20%20%20%20%20%20%20%20test%40example.com?secret=QWERTYUIOP&digits=6&issuer=&algorithm=SHA1&period=30

Proton strips the spaces (probably wise) but also removes the issuer.

Risk: The user will not know which account the code is for.

Recommendation: Keep the issuer.

Timeline

These aren't particularly high severity bugs, nevertheless I like to give organisations a bit of time to respond.

• 2025-07-31 - Discovered.
• 2025-08-01 - Disclosed via a web form.
• 2025-08-31 - Automatically published.

Next Steps

• If you're a user, please contribute tests or give feedback.
• If you're a developer, please check your app conforms to the specification.
• If you're from a security company - wanna help me write up a proper RFC so this doesn't cause issues in the future?

All I need to do is add something like this into my site's source code:

<link rel="monetization" href="https://wallet.example.com/edent">

A user who has a WebMonetization plugin can then easily pay me for my content.

But not every website is created by an individual or a single entity. Hence, the creation of the "Probabilistic Revenue Share Generator".

Probabilistic revenue sharing is a way to share a portion of a web monetized page's earnings between multiple wallet addresses. Each time a web monetized user visits the page, a recipient will be chosen at random. Payments will go to the chosen recipient until the page is closed or reloaded.

Nifty! But how does it work?

Let's say a website is created by Alice and Bob. Alice does most of the work and is to receive 70% of the revenue. Bob is to get the remaining 30%. Within the web page's head, the following meta element is inserted:

<link
   rel="monetization"
   href="https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDcwLCJBbGljZSJdLFsiaHR0cHM6Ly93aGF0ZXZlci50ZXN0LyIsMzAsIkJvYiJdXQ"
/>

The visitor's WebMonetization plugin will visit that URl and be redirected to Alice's site 70% of time and Bob's 30%.

If we Base64 decode that weird looking URl, we get:

[
   [
      "https://example.com/",
       70,
      "Alice"
   ],
   [
      "https://whatever.test/",
       30,
      "Bob"
   ]
]

Rather than adding multiple URls in the head, the site points to one resource and lets that pick who receives the funds.

There are two small problems with this.

The first is that you have to trust the WebMonetization.org website. If it gets hijacked or goes rogue then all your visitors will be paying someone else. But let's assume they're secure and trustworthy. There's a slightly more insidious threat.

Effectively, this allows an untrusted 3rd party to use the WebMonetization.org domain as an open redirect. That's useful for phishing and other abuses.

For example, an attacker could send messages encouraging people to visit:

https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDk5LCJpbWciXV0

Click that and you'll instantly be redirected to a domain under the attacker's control. This could be particularly bad if the domain encouraged users to share passwords or other sensitive information.

If the Base64 data cannot be decoded to valid JSON, the API will echo back any Base64 encoded text sent to it. This means an attacker could use it to send obfuscated messages. Consider, tor example:

https://webmonetization.org/api/revshare/pay/W1siUGxlYXNlIHZpc2l0IFJlYWxfZ29vZF9DYXNpbm9zLmJpeiBmb3IgbG90cyBvZiBDcnlwdG8gZnVuISEhIiwxMjM0NTYsImltZyJdXQ==

Visit that and you'll see a message. With a bit of effort, it could be crafted to say something to encourage a visitor to enter their credentials elsewhere.

When I originally reported this, the site could be used to to smuggle binary payloads. For example, this URl would display an image - however, it seems to have been fixed.

Nevertheless, it is important to recognise that the WebMonetization.org domain contains an unvalidated redirect and forwarding vulnerability.

I recommended that they ensured that the only URls which contain legitimate payment pointers should be returned. I also suggested setting a maximum limit for URl size.

Timeline

• 2025-03-27 - Discovered and disclosed.
• 2025-08-05 - Remembered I'd submitted it and sent a follow up.
• 2025-08-26 - Automatically published.
• 2025-08-27 - A day after this post was published, the issue was made public on their repo.
• 2025-09-10 - Confirmed fixed.

Let's take a look at details of the vulnerability:

An unauthenticated attacker who knows the target device's serial number, can generate the default administrator password for the device.

Recently, the UK brought in some laws aimed at strengthening consumer protection - the Product Security and Telecommunications Infrastructure act (PSTI). There's a readable summary on the National Cyber Security Centre's website.

There are three interesting points to note in that blog post. The first is about passwords:

The law means manufacturers must ensure that all their smart devices meet basic cyber security requirements. Specifically:

1. The manufacturer must not supply devices that use default passwords, which can be easily discovered online, and shared.

Secondly, is a question of jurisdiction:

Most smart devices are manufactured outside the UK, but the PSTI act also applies to all organisations importing or retailing products for the UK market. Failure to comply with the act is a criminal offence

Thirdly, what is actually covered:

The law applies to any ‘consumer smart device’ that connects either to the internet, or to a home network (for example by wifi).

Is a WiFi enabled printer a "consumer smart device"? One of the things that techies find confusing is that the law is not code. It usually doesn't enumerate a definitive list of what is and what isn't in scope. It gives a general outline and then allows case-law to develop. This means laws don't need to be updated when someone invents, say, an Internet connected tinfoil dispenser.

Let's move beyond the consumer-friendly summary and go to the actual law. The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023

2. Passwords must be—

   a. unique per product; or

   b. defined by the user of the product.

3. Passwords which are unique per product must not be—

   a. based on incremental counters;

   b. based on or derived from publicly available information;

   c. based on or derived from unique product identifiers, such as serial numbers, unless this is done using an encryption method, or keyed hashing algorithm, that is accepted as part of good industry practice;

   d. otherwise guessable in a manner unacceptable as part of good industry practice.

How does this apply to the printers? Rapid7, who discovered the vulnerability, have this to say about how it works:

[The vulnerability] allows an attacker to leak a serial number via the target's HTTP, HTTPS, and IPP services. However, should an attacker not be able to leverage [the vulnerability], a remote unauthenticated attacker can still discover a target device's serial number via either a PJL or SNMP query

So, yes. The default password is unique but it can be automatically derived from the serial number. That serial number is available to anyone with a network connection to the printer.

But, do printers fall under the scope of this act?

The Product Security and Telecommunications Infrastructure Act 2022 says:

4 Relevant connectable products

1. In this Part “relevant connectable product” means a product that meets conditions A and B.

2. Condition A is that the product is—

   A. an internet-connectable product, or

   B. a network-connectable product.

3. Condition B is that the product is not an excepted product (see section 6).

It goes on to define what Internet-connectable means, along with some other clarifying details. But is there a get-out clause here? Are printers an "excepted product"?

In this Part “excepted product” means a product of a description specified in regulations made by the Secretary of State.

OK, let's look at the regulations. I've expanded out the relevant bit:

Schedule 3 Excepted connectable products

5. Computers

   1. Products are excepted under this paragraph if they are computers which are—

      a. desktop computers;

      b. laptop computers;

      c. tablet computers which do not have the capability to connect to cellular networks.

Nope! The Brother printers don't appear to be exempt¹. What's the maximum penalty Brother could be subject to?

The greater of £10 million or 4% of worldwide revenue.

Ouch!

Of course, much like GDPR fines, these are headline grabbing numbers. The prosaic reality is that the enforcement policy is much more likely to suggest remedial steps. Only the most flagrant transgressors are likely to be punished harshly².

So, to recap. The law says an Internet-connected device (including printers) must have a password which is not "based on or derived from publicly available information". As I understand it, having a serial-number based password is OK as long as you don't publicise the serial number. I expect that if it were printed on a sticker that would be fine. But because the serial can be discovered remotely, it fails at this point.

In Brother's (slight) defence, unless the user has specifically connected the printer to the Internet this is only a local vulnerability. Someone on the same network would be able to monkey around with the printer but, similarly, they could plug in a USB cable for some illicit printing or break it with a hammer. Any damage is confined to the LAN.

Should users change default passwords? Yes. But manufacturers have a legal duty to ensure that people who don't are still protected.

I can now read all the passport information, including biometrics.

Background

The NFC chip in a passport is protected by a password. The password is printed on the inside of the physical passport. As well as needing to be physically close to the passport for NFC to work⁰, you also need to be able to see the password. The password is printed in the "Machine Readable Zone" (MRZ) - which is why some border guards will swipe your passport through a reader before scanning the chip; they need the password and don't want to type it in.

I had a small problem though. I'm using my old passport¹ which has been cancelled. Cancelling isn't just about revoking the document. It is also physically altered:

Cut off the bottom left hand corner of the personal details page, making sure you cut the MRZ on the corner opposite the photo.

So a chunk of the MRZ is missing! Oh no! Whatever can we do!?

Recreating the MRZ

The password is made up of three pieces of data:

1. Passport Number (Letters and Numbers)
2. Date of Birth (YYMMDD)
3. Expiry Date (YYMMDD)

Each piece also has a checksum. This calculation is defined in Appendix A to Part 3 of Document 9303.

Oh, and there's a checksum for the entire string. It's this final checksum which is cut off when the passport cover is snipped.

The final password is: Number Number-checksum DOB DOB-checksum Expiry Expiry-checkum checksum-of-previous-digits

Python code to generate an MRZ

If you know the passport number, date of birth, and expiry date, you can generate your own Machine Readable Zone - this acts as the password for the NFC chip.

def calculateChecksum( value ):
    weighting = [7,3,1]
    characterWeight = {
        '0': 0, '1': 1, '2': 2, '3': 3, '4': 4, '5': 5, '6': 6, '7': 7,  
        '8': 8, '9': 9, '<': 0, 'A':10, 'B':11, 'C':12, 'D':13, 'E':14, 
        'F':15, 'G':16, 'H':17, 'I':18, 'J':19, 'K':20, 'L':21, 'M':22, 
        'N':23, 'O':24, 'P':25, 'Q':26, 'R':27, 'S':28, 'T':29, 'U':30, 
        'V':31, 'W':32, 'X':33, 'Y':34, 'Z':35
    }
    counter = 0
    result = 0
    for x in value:
        result += characterWeight[str(x)] * weighting[counter%3]
        counter += 1
    return str(result%10)

def calculateMRZ( passportNumber, DOB, expiry ):
    """
    DOB and expiry are formatted as YYMMDD
    """
    passportCheck = calculateChecksum( passportNumber )
    DOBCheck      = calculateChecksum( DOB )
    expiryCheck   = calculateChecksum( expiry )
    mrzNumber  = passportNumber + passportCheck + DOB + DOBCheck + expiry + expiryCheck
    mrzCheck = calculateChecksum( mrzNumber ).zfill(2)
    mrz =  passportNumber + passportCheck + "XXX" + DOB + DOBCheck + "X" + expiry + expiryCheck + "<<<<<<<<<<<<<<" + mrzCheck
    return mrz

print( calculateMRZ("123456789", "841213", "220229") )

Can you read a cancelled passport?

I would have thought that cutting the cover of the passport would destroy the antenna inside it. But, going back to the UK guidance:

You must not cut the back cover on the ePassport

Ah! That's where the NFC chip is. I presume this is so that cancelled passports can still be verified for authenticity.

Cryptography and other security

The security is, thankfully, all fairly standard Public Key Cryptography - 9303 part 11 explains it in excruciating levels of detail.

One thing I found curious - because the chip has no timer, it cannot know how often it is being read. You could bombard it with thousands of password attempts and not get locked out. Indeed, the specification says:

the success probability of the attacker is given by the time the attacker has access to the IC, the duration of a single attempt to guess the password, and the entropy of the passport.

Can you brute-force a passport?

Wellllll… maybeeeee…?

Passports are generally valid for only 10 years. So that's 36,525 possible expiry dates.

Passport holders are generally under 100 years old. So that's 3,652,500 possible dates of birth.

That's already 133,407,562,500 attempts - and we haven't even got on to the 1E24 possible passport numbers!

In my experiments, sending an incorrect but valid MRZ results in the chip returning "Security status not satisfied (0x6982)" in a very short space of time. Usually less than a second.

But sending that incorrect attempt seemed to introduce a delay in the next response - by a few seconds. Sending the correct MRZ seemed to reset this and let the chip be read instantly.

So, if you knew the target's passport number and birthday, brute forcing the expiry date would take a couple of days. Not instant, but not impossible.

Most commercial NFC chips support 100,000 writes with no limit for the number of reads. Some also have a 24 bit read counter which increments after every read attempt. After 16 million reads, the counter doesn't increment. It could be possible for a chip to self-destruct after a specific number of reads - but I've no evidence that passport chips do that.

Is it worth brute-forcing a password?

If you were to brute-force the MRZ, you would discover the passport-holder's date of birth. You would also get:

• A digital copy of their photo,
• Their full name,
• Their sex²,
• The country which issued their passport, and
• Their nationality.

All of that is something which you can see from looking at the passport. So there's little value in attempting to read it electronically.

Installing

As mentioned, I'm using https://github.com/roeften/pypassport

The only library I needed to install was pyasn1 using pip3 install pyasn1 - your setup may vary.

Download PyPassport. In the same directory, you can create a test Python file to see if the passport can be read. Here's what it needs to contain:

from pypassport import epassport, reader

#   Replace this MRZ with the one from your passport
MRZ = "1234567897XXX8412139X2202299<<<<<<<<<<<<<<04"

def trace(name, msg):
    if name == "EPassport":
        print(name + ": " + msg)

r = reader.ReaderManager().waitForCard()

ep = epassport.EPassport(r, MRZ)
ep.register(trace)
ep.readPassport()

Plug in your NFC reader, place your passport on it, run the above code. If it works, it will spit out a lot of debug information, including all the data it can find on the passport.

Getting structured data

The structure of the passport data is a little convoluted. The specification puts data into different "Data Groups" - each with its own ID.

By running:

ep.keys()

You can see which Data Groups are available. In my case, ['60', '61', '75', '77']

• 60 is the common area which contains some metadata. Nothing interesting there.
• 61 is DG1 - the full MRZ. This contains the holder's name, sex, nationality, etc.
• 77 is the Document Security Object - this was empty for me.
• 75 is DG2 to DG4 Biometric Templates - this contains the image and other metadata.

Dumping the biometrics - print( ep["75"] ) - gives these interesting pieces of metadata:

'83': '20190311201345',
'meta': {   'Expression': 'Unspecified',
            'EyeColour' : 'Unspecified',
            'FaceImageBlockLength': 19286,
            'FaceImageType': 'Basic',
            'FeatureMask': '000000',
            'FeaturePoint': {0: {'FeaturePointCode': 'C1',
                                'FeatureType': '01',
                                'HorizontalPosition': 249,
                                'Reserved': '0000',
                                'VerticalPosition': 216},
                            1: {'FeaturePointCode': 'C2',
                                'FeatureType': '01',
                                'HorizontalPosition': 141,
                                'Reserved': '0000',
                                'VerticalPosition': 214}},
            'Features': {},
            'Gender': 'Unspecified',
            'HairColour': 'Unspecified',
            'ImageColourSpace': 'RGB24',
            'ImageDataType': 'JPEG',
            'ImageDeviceType': 0,
            'ImageHeight': 481,
            'ImageQuality': 'Unspecified',
            'ImageSourceType': 'Static Scan',
            'ImageWidth': 385,
            'LengthOfRecord': 19300,
            'NumberOfFacialImages': 1,
            'NumberOfFeaturePoint': 2,
            'PoseAngle': '0600B5',
            'PoseAngleUncertainty': '000000',
            'VersionNumber': b'010'
        }

If I understand the testing document - the "Feature Points" are the middle of the eyes. Interesting to see that gender (not sex!) and hair colour are also able to be recorded. The "PoseAngle" represents the pitch, yaw, and roll of the face.

Saving the image

Passport images are saved either with JPEG or with JPEG2000 encoding. Given the extremely limited memory available photos are small and highly compressed. Mine was a mere 19KB.

To save the image, grab the bytes and plonk them onto disk:

photo = ep["75"]["A1"]["5F2E"]
with open( "photo.jpg", "wb" ) as f:
   f.write( photo )

As expected, the "FeaturePoints" co-ordinates corresponded roughly to the centre of my eyes. Nifty!

What didn't work

I tried a few different tools. Listed here so you don't make the same mistakes as me!

mrtdreader

The venerable mrtdreader. My NFC device beeped, then mrtdreader said "No NFC device found."

I think this is because NFC Tools haven't been updated in ages.

Jean-Francois Houzard's and Olivier Roger's pyPassport

I looked at pyPassport but it is only available for Python 2.

beaujean's pyPassport

This pypassport only checks if a passport is resistant to specific security vulnerabilities.

d-Logic

Digital Logic's ePassport software only works with their hardware readers.

Android reader

tananaev's passport-reader - works perfectly on Android. So I knew my passport chip was readable - but the app won't run on Linux.

Is it worth it?

Yeah, I reckon so! Realistically, you aren't going to be able to crack the MRZ to read someone's passport. But if you need to gather personal information³, it's perfectly possible to do so quickly from a passport.

The MRZ is a Machine Readable Zone - so it is fairly simple to OCR the text and then pass that to your NFC reader.

And even if the MRZ is gone, you can reconstruct it from the data printed on the passport.

Of course, this won't be able to detect fraudulent passports. It doesn't check against a database to see if it has been revoked⁴. I don't think it will detect any cryptographic anomalies.

But if you just want to see what's on your travel documents, it works perfectly.

Stupid people use a password manager. They know they can't remember a hundred different passwords and so outsource the thinking to something reasonably secure. I'm a stupid person and am very happy to have BitWarden generate and save fiendishly complex unique passwords which are then protected by the app's MFA. Lovely!

But people who think they are clever decide to bypass that and use their own super-secret algorithm.

Every clever person's algorithm boils down to the same thing:

1. Have a single strong main password.
2. Add to it some information related to the service.

For example P@ssw0rd!_facebook and P@ssw0rd!_linkedin. On the surface, that's quite an attractive proposition. You remember one thing and you don't need to trust a password manager.

People who are extra clever use the same algorithm but wrap it in a command-line function which XORs both pieces of data, creates a SHA-512 hash, takes every prime numbered bit, converts to ASCII, and uses that to generate a password. Smart!

Either way, these algorithms suck! Let me explain why.

Password Leaking

One day, LinkedIn decides to LeakedOut its users' passwords. Anyone who can see P@ssw0rd!_linkedin can make a pretty good guess at your password for Facebook, banking, dating, and shopping etc. This means you now need to change every password that you have.

Even if you have used some amazing cryptographic powerhouse of an algorithm, there's still a chance you'll accidentally leak it or get so paranoid that you decide to invalidate it. Now you need to change your password on hundreds of sites.

Password Rotation

We all know that it is a bad idea to ask your users to regularly change their passwords - yet sites often persist in doing so.

How does your algorithm cope with this?

Do you have to remember that it is P@ssw0rd!_facebook_1 and P@ssw0rd!_linkedin_23?

Perhaps you'll write down all the suffixes and find a way to store them securely - like, say, a password manager?

Password Requirements

One site says "Your password must contain a special character and a number" another says "You can use any special character except % or ?" another refuses to let your password contain two consecutive identical characters, or it must start with a number, or it cannot be longer than 12 characters. Yes, I know password rules like this aren't sensible - but they are common.

How does your algorithm cope with that?

If you manually have to tweak a couple of dozen passwords generated by your algorithm, you are going to tie yourself in knots remembering the arcane requirements for each one.

Be Stupid - Use A Password Manager

Humans are stupid⁰. Humans get tired, forgetful, or sick. Our delicious meaty brains are not optimised to remember long strings of complex information or hundreds of rarely used combinations. Knowing that you know not is a super-power. It allows you to offload things that you don't understand to something more competent.

Pick a password manager. Secure it with a reasonably strong password and multi-factor authentication. Let it do the hard work of remembering.

For example, take this news story and this journalist's response to it:

100,000 taxpayers will be told shortly that their @HMRCgovuk accounts have been hacked and £47m stolen by thieves claiming fake tax repayments bit.ly/4mSDrMs extraordinary admission to MPs from top official who claims it wasn’t a cyberattack!

— Paul Lewis (@paullewismoney.bsky.social) 2025-06-05T06:33:24.098Z

I think it is pretty reasonable to say that having 100,000 accounts breached using a computer is a "cyberattack". So how do the UK tax authorities square that circle? Angela MacDonald, the deputy chief executive of HMRC, said:

MacDonald stressed that the breach was “not a cyberattack, we have not been hacked, we have not had data extracted from us”.

She later said: “The ability for somebody to breach your systems and to extract data, to hold you to ransomware and all of those things, that is a cyberattack. That is not what has happened here.”

…

“This was not a cyberattack — it involved criminals using personal information from phishing activity or data obtained elsewhere to try to claim money from HMRC. We’re writing to those customers affected to reassure them we’ve secured their accounts and that they haven’t lost any money.”

Criminals access 100,000 people’s tax records

Ah. I think that's pretty reasonable. Well, up to a point.

If you set your HMRC password to be "password" and someone guesses that - it is you who has been attacked; not the online service.

Here's what has probably happened in this case.

• You signed up to an online service.
• You used your regular email and password.
• The service got hacked and leaks everyone's details.
• A criminal went credential stuffing and tried all the usernames and password on lots of sites.
• One of those sites was HMRC and the criminal started filling their pockets.

Who is being "cyberattacked" here? HMRC say that no individual lost any money - although I suspect people will possibly feel various administrative repercussions. It is hard to feel that the individual is the victim.

HMRC didn't have any malware or ransomware installed. None of their computers were misused. Vast globs of data were not exfiltrated.

But were HMRC's digital defences breached? Maybe…

Let's suppose that the cybercriminal who did this was an idiot. Here's what they might have done:

• Used a single IP address
• From a "dangerous" country
• Trying 1,000 passwords per second

At which point, HMRC's systems should have started flashing red, sirens wailing, and countermeasures deployed. Any one or combination of the above should have been enough to trigger a "something fishy is going on here" alert. I think that scenario would be fair to describe it as looking like a cyberattack - although, depending on their risk tolerance it might be described as "not great, not terrible".

But if the attacker was smart, they'd have rotated through thousands of UK-based IP addresses and kept their stuffing volume below the noise threshold. Whereupon their attempts would likely have gone unnoticed.

Is a small and subtle attack still an attack? Yes.

Was this a cyberattack?

I don't think it matters. Sorting things into predefined buckets is often just a way to bypass responsibility and accountability. Concentrating on the name of the thing rather than the thing itself doesn't help victims and doesn't prevent the incident from happening again.

Every counter-measure which HMRC could deploy will negatively affect legitimate users. Getting bombarded with emails saying "did you just try to log in?" is an annoyance, mandating 2FA excludes less technical users, banning suspicious IP addresses inevitably leads to false positives, rate-limits hit legitimate users. And, ultimately, (whisper it) users bear some of the blame for their poor password practices.

I'm sure HMRC will tighten up their monitoring, I'm sure some individuals will have better password hygiene, and I'm sure criminals will find a way to bypass both.

As ontology is difficult, I'll leave you with this instructional video.

EE texted to say they had processed my sim activation request, and the new sim would be active in 24 hours. I was told to contact them if I hadn’t requested this. I hadn’t, so I did so immediately. Twenty-four hours later, my mobile stopped working and money was withdrawn from my bank account.

With their alien sim, the ­fraudster infiltrated my handset and stole details for every account I had. Passwords and logins had been changed for my finance, retail and some social media accounts.

(Emphasis added.)

I realise it is in the consumer rights section of the newspaper, not the technology section, and I dare-say some editorialising has gone on, but that's nonsense.

Here's how a SIM swap works.

1. Attacker convinces your phone company to reassign your telephone number to a new SIM.
2. Attacker goes to a website where you have an account, and initiates a password reset.
3. Website sends a verification code to your phone number, which is now in the hands of the attacker.
4. Attacker supplies verification code and gets into your account.

Do you notice the missing step there?

At no point does the attacker "infiltrate" your handset. Your handset is still in your possession. The SIM is dead, but that doesn't give the attacker access to the phone itself. There is simply no way for someone to put a new SIM into their phone and automatically get access to your device.

Try it now. Take your SIM out of your phone and put it into a new one. Do all of your apps suddenly appear? Are your usernames and passwords visible to you? No.

There are ways to transfer your data from an iPhone or Android - but they require a lot more work than swapping a SIM.

So how did the attacker know which websites to target and what username to use?

What (Probably) Happened

Let's assume the person in the article didn't have malware on their device and hadn't handed over all their details to a cold caller.

The most obvious answer is that the attacker already knew the victim's email address. Maybe the victim gave out their phone number and email to some dodgy site, or they're listed on their contact page, or something like that.

The attacker now has two routes.

First is "hit and hope". They try the email address on hundreds of popular sites' password reset page until they get a match. That's time-consuming given the vast volume of websites.

Second is targetting your email. If the attacker can get into your email, they can see which sites you use, who your bank is, and where you shop. They can target those specific sites, perform a password reset, and get your details.

I strongly suspect it is the latter which has happened. The swapped SIM was used to reset the victim's email password. Once in the email, all the accounts were easily found. At no point was the handset broken into.

What can I do to protect myself?

It is important to realise that there's nothing you can do to prevent a SIM-swap attack! Your phone company is probably incompetent and their staff can easily be bribed. You do not control your phone number. If you get hit by a SIM swap, it almost certainly isn't your fault.

So here are some practical steps anyone can take to reduce the likelihood and effectiveness of this class of attack:

• Remember that it's OK to lie to WiFi providers and other people who ask for your details. You don't need to give someone your email for a receipt. You don't need to hand over your real phone number on a survey. This is the most important thing you can do.
• Try to hack yourself. How easy would it be for an attacker who had stolen your phone number to also steal your email address? Open up a private browser window and try to reset your email password. What do you notice? How could you secure yourself better?
• Don't use SMS for two-factor authentication. If you are given a choice of 2FA methods, use a dedicated app. If the only option you're given is SMS - contact the company to complain, or leave for a different provider.
• Don't rely on a setting a PIN for your SIM. The PIN only protects the physical SIM from being moved to a new device; it does nothing to stop your number being ported to a new SIM.
• Finally, realise that professional criminals only need to be lucky once but you need to be lucky all the time.

Stay safe out there.

Security expert Bruce Schneier approved⁰ of this trade-off between security and usability - saying what we're all thinking:

Here’s a guy who has a webcam pointing at his SecurID token, so he doesn’t have to remember to carry it around. Here’s the strange thing: unless you know who the webpage belongs to, it’s still good security. Crypto-Gram - August 15, 2004

Nowadays, we have to carry dozens of these tokens with us. Although, unlike the poor schmucks of 2004, we have an app for that. But I don't always have access to my phone. Sometimes I'm in a secure location where I can't access my electronics. Sometimes my phone gets stolen, and I need to log into Facebook to whinge about it. Sometimes I just can't be bothered to remember which fingerprint unlocks my phone¹.

Using the Web Crypto API, it is easy to Generate TOTP Codes in JavaScript directly in the browser. So here are all my important MFA tokens. If I ever need to log in somewhere, I can just visit this page and grab the code I need².

All My Important Codes

What The Actual Fuck?

A 2007 paper called Lessons learned from the deployment of a smartphone-based access-control system looked at whether fobs met the needs of their users:

However, we observed that end users tend to be most concerned about how convenient [fobs] are to use. There are many examples of end users of widely used access-control technologies readily sacrificing security for convenience. For example, it is well known that users often write their passwords on post-it notes and stick them to their computer monitors. Other users are more inventive: a good example is the user who pointed a webcam at his fob and published the image online so he would not have to carry the fob around.

As for Schneier's suggestion that anonymity added protection, a contemporary report noted that the owner of the FobCam site was trivial to identify³.

Every security system involves trade-offs. I have a password manager, but with over a thousand passwords in it, the process of navigating and maintaining becomes a burden. The number of 2FA tokens I have is also rising. All of these security factors need backing up. Those back-ups need testing⁴. It is an endless cycle of drudgery.

What's a rational user supposed to do⁵? I suppose I could buy a couple of hardware keys, keep one in an off-site location, but somehow keep both in sync, and hope that a firmware-update doesn't brick them.

Should I just upload all of my passwords, tokens, secrets, recovery codes, passkeys, and biometrics⁶ into the cloud?

The cloud is just someone else's computer. This website is my computer. So I'm going to upload all my factors here. What's the worst that could happen⁷.

The pitch is simple. A website owner places a single new line in their HTML's <head> - something like this:

<link rel="monetization" href="https://wallet.example.com/edent" />

That address is a "Payment Pointer". As a user browses the web, their browser takes note of all the sites they've visited. At the end of the month, the funds in the user's digital wallet are split proportionally between the sites which have enabled WebMonetization. The user's budget is under their control and there are various technical measures to stop websites hijacking funds.

This could be revolutionary⁰.

But there are some interesting fraud angles to consider. Let me give you a couple of examples.

Pointer Hijacking

Suppose I hacked into a popular site like BBC.co.uk and surreptitiously included my link in their HTML. Even if I was successful for just a few minutes, I could syphon off a significant amount of money.

At the moment, the WebMonetization plugin only looks at the page's HTML to find payment pointers. There's no way to say "This site doesn't use WebMonetization" or an out-of-band way to signal which Payment Pointer is correct. Obviously there are lots of ways to profit from hacking a website - but most of them are ostentatious or require the user to interact. This is subtle and silent.

How long would it take you to notice that a single meta element had snuck into some complex markup? When you discover it, what can you do? Money sent to that wallet can be transferred out in an instant. You might be able to get the wallet provider to freeze the funds or suspend the account, but that may not get you any money back.

Similarly, a Web Extension like Honey could re-write the page's source code to remove or change an existing payment pointer.

Possible Solutions

Perhaps the username associated with a Payment Pointer should be that of the website it uses? something like href="https://wallet.example.com/shkspr.mobi"

That's superficially attractive, but comes with issues. I might have several domains - do I want to create a pointer for each of them?

There's also a legitimate use-case for having my pointer on someone else's site. Suppose I write a guest article for someone - their website might contain:

<link rel="monetization" href="https://wallet.example.com/edent" />
<link rel="monetization" href="https://wallet.coin_base.biz/BigSite" />

Which would allow us to split the revenue.

Similarly, a site like GitHub might let me use my Payment Pointer when people are visiting my specific page.

So, perhaps site owners should add a .well-known directive which lists acceptable Pointers? Well, if I have the ability to add arbitrary HTML to a site, I might also be able to upload files. So it isn't particularly robust protection.

Alright, what are other ways typically used to prove the legitimacy of data? DNS maybe? As the popular meme goes:

@atax1a@infosec.exchange

mx alex tax1a - 2020 (5)

@jwz @grumpybozo just one more public key in a TXT record, that'll fix email, just gotta add one more TXT record bro

---

Someone with the ability to publish on a website is less likely to have access to DNS records. So having (yet another) DNS record could provide some protection. But DNS is tricky to get right, annoying to update, and a pain to repeatedly configure if you're constantly adding and removing legitimate users.

Reputation Hijacking

Suppose the propaganda experts in The People's Republic of Blefuscu decide to launch a fake site for your favourite political cause. It contains all sorts of horrible lies about a political candidate and tarnishes the reputation of something you hold dear. The sneaky tricksters put in a Payment Pointer which is the same as the legitimate site.

"This must be an official site," people say. "Look! It even funnels money to the same wallet as the other official sites!"

There's no way to disclaim money sent to you. Perhaps a political opponent operates an illegal Bonsai Kitten farm - but puts your Payment Pointer on it.

"I don't squash kittens into jars!" You cry as they drag you away. The police are unconvinced "Then why are you profiting from it?"

Possible Solutions

A wallet provider needs to be able to list which sites are your sites.

You log in to your wallet provider and fill in a list of websites you want your Payment Pointer to work on. Add your blog, your recipe site, your homemade video forum etc. When a user browses a website, they see the Payment Pointer and ask it for a list of valid sites. If "BonsaiKitten.biz" isn't on there, no payment is sent.

Much like OAuth, there is an administrative hassle to this. You may need to regularly update the sites you use, and hope that your forgetfulness doesn't cost you in lost income.

Final Thoughts

I'm moderately excited about WebMonetization. If it lives up to its promises, it could unleash a new wave of sustainable creativity across the web. If it is easier to make micropayments or donations to sites you like, without being subject to the invasive tracking of adverts, that would be brilliant.

The problems I've identified above are (I hope) minor. Someone sending you money without your consent may be concerning, but there's not much of an economic incentive to enrich your foes.

Think I'm wrong? Reckon you've found another fraudulent avenue? Want to argue about whether this is a likely problem? Stick a comment in the box.

The three major implementations of the spec - Google, Apple, and Yubico - all subtly disagree on how it should be implemented. Every other MFA app has their own idiosyncratic variants. The official RFC is infuriatingly vague. That's no good for a security specification. Multiple implementations are great, multiple interpretations are not.

So I've built a nascent test suite - you can use it to see if your favourite app can correctly implement the TOTP standard.

Please do contribute tests and / or feedback.

Here's what the standard actually says - see if you can find apps which don't implement it correctly.

Background

Time-based One Time Passwords are based on HOTP - HMAC-Based One-Time Password.

HOTP uses counters; a new password is regularly generated. TOTP uses time as the counter. At the time of writing this post, there have been about 1,740,800,000 seconds since the UNIX Epoc. So a TOTP with an period of 30 seconds is on counter (1,740,800,000 ➗ 30) = 58,026,666. Every 30 seconds, that counter increments by one.

Number of digits

How many digits should your 2FA token have? Google says 6 or 8. YubiCo graciously allows 7. Why those limits? Who knows!?

The HOTP specification gives an example of 6 digits. The example generates a code of 0x50ef7f19 which, in decimal, is 1357872921. It then takes the last 6 digits to produce the code 872921.

The TOTP RFC says:

Basically, the output of the HMAC-SHA-1 calculation is truncated to obtain user-friendly values

1.2. Background

But doesn't say how far to truncate.

There's nothing I can see in the spec that prevents an implementer using all 10. The HOTP spec, however, does place a minimum requirement - but no maximum:

Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code. Depending on security requirements, Digit = 7 or more SHOULD be considered in order to extract a longer HOTP value. RFC 4226 - 5.3. Generating an HOTP Value

(As a minor point, the first digit is restricted to 0-2, so being 10 digits long isn't significantly stronger than 9 digits.)

Is a 4 digit code acceptable? The security might be weaker, but the usability is greater. Most apps will allow a one digit code to be returned. If no digits are specified, what should the default be?

Algorithm

The given algorithm in the HOTP spec is SHA-1.

In order to create the HOTP value, we will use the HMAC-SHA-1 algorithm RFC 4226 - 5.2. Description

As we now know, SHA-1 has some fundamental weaknesses. The spec comments (perhaps somewhat naïvely) about SHA-1:

The new attacks on SHA-1 have no impact on the security of HMAC-SHA-1. RFC 4226 - B.2. HMAC-SHA-1 Status

I daresay that's accurate. But the TOTP authors disagree and allow for some different algorithms to be used. The specification for HMAC says:

HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1 [Emphasis added] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication

So most TOTP implementation allow SHA-1, SHA-256, and SHA-512.

TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions […] instead of the HMAC-SHA-1 function that has been specified for the HOTP computation RFC 6238 - TOTP: Time-Based One-Time Password Algorithm

But the HOTP spec goes on to say:

Current candidates for such hash functions include SHA-1, MD5, RIPEMD-128/160. These different realizations of HMAC will be denoted by HMAC-SHA1, HMAC-MD5, HMAC-RIPEMD RFC 2104 - Introduction

So, should your TOTP app be able to handle an MD5 HMAC, or even SHA3-384? Will it? If no algorithm is specified, what should the default be?

Period

As discussed, this is what increments the counter for HOTP. The Google Spec says:

The period parameter defines a period that a TOTP code will be valid for, in seconds. The default value is 30.

The TOTP RFC says:

We RECOMMEND a default time-step size of 30 seconds 5.2. Validation and Time-Step Size

It doesn't make sense to have a negative number of second. But what about one second? What about a thousand? Lots of apps artificially restrict TOTP codes to 15, 30, or 60 seconds. But there's no specification to define a maximum or minimum value.

A user with mobility difficulties or on a high-latency connection probably wants a 5 minute validity period. Conversely, machine-to-machine communication can probably be done with a single-second (or lower) time period.

Secret

Google says the secret is

an arbitrary key value encoded in Base32 according to RFC 3548. The padding specified in RFC 3548 section 2.2 is not required and should be omitted.

Whereas Apple says it is:

An arbitrary key value encoded in Base32. Secrets should be at least 160 bits.

Can a shared secret be a single character? What about a thousand? Will padding characters cause a secret to be rejected or can they be safely stripped?

Label

The label allows you to have multiple codes for the same service. For example Big Bank:Personal Account and Big Bank:Family Savings. The Google spec is slightly confusing:

The issuer prefix and account name should be separated by a literal or url-encoded colon, and optional spaces may precede the account name. Neither issuer nor account name may themselves contain a colon.

What happens if they are not URl encoded? What about Matrix accounts which use a colon in their account name? Why are spaces allowed to precede the account name? Is there any practical limit to the length of these strings?

If no label is specified, what should the default be?

Issuer

Google says this parameter is:

Strongly Recommended The issuer parameter is a string value indicating the provider or service this account is associated with, URL-encoded according to RFC 3986. If the issuer parameter is absent, issuer information may be taken from the issuer prefix of the label. If both issuer parameter and issuer label prefix are present, they should be equal.

Apple merely says:

The domain of the site or app. The password manager uses this field to suggest credentials when setting up a new code generator.

Yubico equivocates with

The issuer parameter is recommended, but it can be absent. Also, the issuer parameter and issuer string in label should be equal.

If it isn't a domain, will Apple reject it? What happens if the issuer and the label don't match?

Next Steps

• If you're a user, please contribute tests or give feedback.
• If you're a developer, please check your app conforms to the specification.
• If you're from Google, Apple, Yubico, or another security company - wanna help me write up a proper RFC so this doesn't cause issues in the future?

So, is it possible to build a TOTP⁰ code generator without using any external JS libraries? Yes! And it is (relatively) simple.

Here's the code that I've written. It is slightly verbose and contains a lot of logging so you can see what it is doing. I've annotated it with links to the various specifications so you can see where some of the decisions come from. I've compared the output to several popular TOTP code generators and it appears to match. You probably shouldn't use this in production, and you should audit it thoroughly.

I'm sure there are bugs to be fixed and performance enhancements to be made. Feel free to leave a comment here or on the repo if you spot anything.

I consider this code to be trivial but, if it makes you happy, you may consider it licensed under MIT.

async function generateTOTP( 
    base32Secret = "QWERTY", 
    interval = 30, 
    length = 6, 
    algorithm = "SHA-1" ) {

    //  Are the interval and length valid?
    if ( interval <  1 ) throw new Error( "Interval is too short" );
    if ( length   <  1 ) throw new Error( "Length is too low"     );
    if ( length   > 10 ) throw new Error( "Length is too high"    );

    //  Is the algorithm valid?
    //  https://datatracker.ietf.org/doc/html/rfc6238#section-1.2
    algorithm = algorithm.toUpperCase();
    if ( algorithm.match( "SHA-1|SHA-256|SHA-384|SHA-512" ) == null ) throw new Error( "Algorithm not known" );

    //  Decode the secret
    //  The Base32 Alphabet is specified at https://datatracker.ietf.org/doc/html/rfc4648#section-6
    const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567";
    let bits = "";

    //  Some secrets are padded with the `=` character. Remove padding.
    //  https://datatracker.ietf.org/doc/html/rfc3548#section-2.2
    base32Secret = base32Secret.replace( /=+$/, "" )

    //  Loop through the trimmed secret
    for ( let char of base32Secret ) {
        //  Ensure the secret's characters are upper case
        const value = alphabet.indexOf( char.toUpperCase() );

        //  If the character doesn't appear in the alphabet.
        if (value === -1) throw new Error( "Invalid Base32 character" );

        //  Binary representation of where the character is in the alphabet
        bits += value.toString( 2 ).padStart( 5, "0" );
    }

    //  Turn the bits into bytes
    let bytes = [];
    //  Loop through the bits, eight at a time
    for ( let i = 0; i < bits.length; i += 8 ) {
        if ( bits.length - i >= 8 ) {
                bytes.push( parseInt( bits.substring( i, i + 8 ), 2 ) );
        }
    }

    //  Turn those bytes into an array
    const decodedSecret = new Uint8Array( bytes );
    console.log( "decodedSecret is " + decodedSecret )

    //  Number of seconds since Unix Epoch
    const timeStamp = Date.now() / 1000; 
    console.log( "timeStamp is " + timeStamp )

    //  Number of intervals since Unix Epoch
    //  https://datatracker.ietf.org/doc/html/rfc6238#section-4.2
    const timeCounter = Math.floor( timeStamp / interval );
    console.log( "timeCounter is " + timeCounter )

    //  Number of intervals in hexadecimal
    const timeHex = timeCounter.toString( 16 );
    console.log( "timeHex is " + timeHex )

    //  Left-Pad with 0
    paddedHex = timeHex.toString(2).padStart( 16, "0" );
    console.log( "paddedHex is " + paddedHex )

    //  Set up a buffer to hold the data
    const timeBuffer = new ArrayBuffer( 8 );
    const timeView   = new DataView( timeBuffer );

    //  Take the hex string, split it into 2-character chunks 
    const timeBytes = paddedHex.match( /.{1,2}/g ).map(
        //  Convert to bytes
        byte => parseInt( byte, 16 )
    );

    //  Write each byte into timeBuffer.
    for ( let i = 0; i < 8; i++ ) {
         timeView.setUint8(i, timeBytes[i]);
    }
    console.log( "timeView is ",  new Uint8Array( timeView   ) );
    console.log( "timeBuffer is", new Uint8Array( timeBuffer ) );

    //  Use Web Crypto API to generate the HMAC key
    //  https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/importKey
    const key = await crypto.subtle.importKey(
        "raw",
        decodedSecret,
        { 
            name: "HMAC", 
            hash: algorithm 
        },
        false,
        ["sign"]
    );

    //  Sign the timeBuffer with the generated HMAC key
    //  https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/sign
    const signature = await crypto.subtle.sign( "HMAC", key, timeBuffer );

    //  Get HMAC as bytes
    const hmac = new Uint8Array( signature );
    console.log( "hmac is ", hmac );

    //  https://datatracker.ietf.org/doc/html/rfc4226#section-5.4
    //  Use the last byte to generate the offset
    const offset = hmac[ hmac.length - 1 ] & 0x0f;
    console.log( "offset is " + offset )

    //  Bit Twiddling operations
    const binaryCode = 
        ( ( hmac[ offset     ] & 0x7f ) << 24 ) |
        ( ( hmac[ offset + 1 ] & 0xff ) << 16 ) |
        ( ( hmac[ offset + 2 ] & 0xff ) <<  8 ) |
        ( ( hmac[ offset + 3 ] & 0xff ) );

    //  Turn the binary code into a decimal string
    stringOTP = binaryCode.toString();
    console.log( "stringOTP is " + stringOTP );

    //  Count backwards from the last character for the length of the code
    otp = stringOTP.slice( -length) 
    console.log( "otp is " + otp );
    //  Pad with 0 to full length
    otp = otp.padStart( length, "0" );
    console.log( "padded otp is " + otp );

    //  All done!
    return otp;
}


// Generate a TOTP code
( async () => {
    console.log( await generateTOTP( "4FCDTLHR446DPFCKUA46UFIAYTQIDSZ2", 30, 6, "SHA-1" ) );
} )();

It works with the three specified algorithms, generating between 1 and 10 digits, and works with any positive integer interval. Not all combinations are sensible; a one digit code valid for two minutes would be silly. But it is up to you to use this responsibly.

I hope I've shown that you don't need to rely on 3rd party libraries to do your cryptography; you can do it all in the browser instead.

You can grab the code from Codeberg.

As I've moaned about before, TOTP has never been properly standardised. It's a mish-mash of half-finished proposals with no active development, no test suite, and no-one looking after it. Which is exactly what you want from a security specification, right?!

So let's try to find some edge-cases and see where things break down.

One Punch Man

This is possibly the least secure TOTP code I could create. Scan it and see whether your app will accept it.

What makes it so crap? There are three things which protect you when using TOTP.

1. The shared secret. In this case, it is abcdefghijklmno - OK, that's not the easiest thing to guess, but it isn't exactly complex.
2. The amount time the code is valid for before changing. Most TOTP codes last 30 seconds, this lasts 120.
3. The length of the code. Most codes are 6 digits long. In theory, the spec allows 8 digits. This is 1. Yup. A single digit.

If you were thick enough to use this¹, an attacker would have a 1/10 chance of simply guessing your MFA code. If they saw you type it in, they'd have a couple of minutes in which to reuse it.

Can modern TOTP apps add this code? I crowdsourced the answers.

Surprisingly, a few apps accept it! Aegis, 1password, and BitWarden will happily store it and show you a 1 digit code for 120 seconds.

A few reject it. Authy, Google Authenticator, and OpenOTP claim the code is broken and won't add it.

But, weirdly, a few interpret it incorrectly! The native iOS app, Microsoft Authenticator, and KeepassXC store the code, but treat it as a 6 digit, 30 second code.

Do The Right Thing

What is the right thing to do in this case? The code is outside the (very loosely defined) specification. Postel's Law tells us that we should try our best to interpret malformed data - which is what Aegis and BitWarden do.

But, in a security context, that could be dangerous. Perhaps rejecting a dodgy code makes more sense?

What is absolutely daft² is ignoring the bits of the code you don't like and substituting your own data! Luckily, in a normal TOTP enrolment, the user has to enter a code to prove they've saved it correctly. Entering in a 6 digit code where only 1 is expected is likely to fail.

We're Only Human

A one-digit code is ridiculous. But what about the other extreme? Would a 128-digit code be acceptable? For a human, no; it would be impossible to type in correctly. For a machine with a shared secret, it possibly makes sense.

On a high-latency connection or with users who may have mobility difficulties, a multi-minute timeframe could be sensible. For something of extremely high security, sub-30 seconds may be necessary.

But, again, the specification hasn't evolved to meet user needs. It is stagnant and decaying.

What's Next?

There's an draft proposal to tighten up to TOTP spec which has expired.

It would be nice if the major security players came together to work out a formal and complete specification for this vital piece of security architecture. But I bet it won't ever happen.

• Google have archived their work on authentication standards.
• Apple points to Google's outdated spec.
• YubiCo's incompatible spec hasn't been updated in 4 years.
• The otpauth registration lists a consortium called https://openauthentication.org who don't appear to published anything in a decade.
• Microsoft don't have any documentation whatsoever.

So there you have it. We're told to rely on TOTP for our MFA - yet the major apps all disagree on how the standard should be implemented. This is a recipe for an eventual security disaster.

How do we fix it?

But now, under pressure from Apple's incredible Find My network, Google has started rolling out a similar service to modern Android phones. In theory it should be much better; Android has a higher market share than iOS in most parts of the world I'm interested in visiting. But Apple's monoculture means they can quickly roll out the network to a much higher range of devices than Google.

The Pebblebee "Universal" range works with both Apple and Android's networks. But, crucially, not at the same time. You can reset the device and swap it between your iPhone and Galaxy - but it won't connect to both networks simultaneously.

Hey, remember when Google and Apple collaborated so that Covid tracing apps were interoperable no matter the device? Good times, man! But, y'know, this is just for protecting property, not life. So we'll give them a pass…

This is what the Pebblebee Clip looks like.

It's a fairly unobtrusive small disk. Clip it to a thing with the included clip, hide it in the lining, glue it to a device. The logo is a clickable button which is used for pairing the device, resetting, and checking the battery.

It also comes with a ridiculously short USB-C-to-C cable which can only be used for charging.

Dump it and grab a longer cable from your big box of cables. Total e-Waste, shouldn't have been included.

When you tell the app to make the PebbleBee identify itself, you're rewarded with this display of loud beeps and disco lasers.

The lights are bright and the sound is piercing - especially considering its size. It fits neatly in a hand and is small enough to tuck away in a pocket.

But what's it like to use?

Pros

• USB-C rechargable. No more faffing about trying to find a new battery. No e-Waste. No worrying if it'll last an entire trip. Shove it into to any USB power source and you're good to go.
• Loud beeper. One of the main reasons I got this was that it (reportedly) has the loudest speaker on the market. I can't compare it to others but it is certainly good enough for hearing in a crowded train carriage.
• Lights. The sides light up - handy for giving you a visual cue as to where it is.
• Small, light, and includes a keyring connector.
• You can share trackers between accounts. My wife and I each have a suitcase. We don't just want to know where our own bag is - we both want to know where both bags are.

Cons

The downsides of the device are minimal - depending on your use case.

• Not waterproof. Certainly water resistant - but the USB-C socket is an ingress point for fluids.
• No Ultra Wide Band. That means you don't get a precise direction when looking for something - just the distance. UWB isn't supported on Google's "Find My Device" network right now, so this isn't a great loss.
• No wireless charging.
• Cost. Even in bulk, with a discount, they were £25 each.

Security

Anyone who finds your tracker can factory reset it. I can't help but feel there should be a way to prevent that. But, to be honest, if a thief has found your token they can just throw it away or destroy it.

Firmware updates aren't available in the Google Find My app. So you'll need to use Pebblebee's own app.

The USB-C port is for power only. They don't show up as a device when connected to a computer.

Testing

I wasn't able to connect to the PebbleBee using GrapheneOS - one of the downsides of using a hyper-secure version of Android.

I used a separate phone, but couldn't get the device to pair. I kept getting this message:

I had to go to Setting → Google → Devices → Scan for nearby devices. Only then could I add it to Find My Device.

The FMD service lets you share devices with another Google account. Perfect for families and loved ones! When I tried to use it, I got this error message on the GrapheneOS phone.

That's probably a GrapheneOS issue. But it is dissapointing these sorts of things aren't standardised and baked into the OS.

In terms of tracking - a bit crap. In Gatwick airport - a pretty busy destination - they stayed tracked for a bit after we dropped off our bags. But in less busy destinations, they never pinged the network. They claim a 150m range which ought to several times better than an AirTag. But without a critical mass of Android users opted-in to the network, it is pointless.

Privacy

I'm a bit of a privacy nut. There's no doubt that these can be used to stalk people - but the Find My app is supposed to alert you if it detect a tag following you.

Is having Google and Apple know where all your stuff is a good thing? Well, probably not. But if it is a choice between seeing where a thief has taken my laptop bag and a multinational knowing what train I took, I guess I'm surprisingly OK with it.

Yes, it is a Devil's Bargain. Location is useful for surveillance (be it advertising or police) but it is also useful for personal security. It isn't nice living in a Panopticon but it also isn't nice to lose your expensive possessions.

Verdict

From a tech point of view - they sort of work! BLE is now an established technology and is well supported on all modern phones. Google's "Find My" app is basic, but works at tracking your devices when they're near you. The device is loud, bright, and is quickly recharged.

If you have a phone that support it, they're a reasonable device. At £25 each, they are optimistically priced. Especially given the coverage issues.

And that's the crux of the issue. As of yet, the network simply isn't as expansive as the Apple version. Apple have the ability to push out a service to millions of users, Google don't. While there are more Android users (certainly in my part of the world) there isn't a mechanism to bootstrap this network.

Back in the day when Google was ambitious, they would have stuck sensors all around the country or ran a massive campaign encouraging people to get involved or launched a cool API or given out a million trackers as freebies. But Google is now a timid and cautious shadow of its former self. Everyone in tech half-expects the Find My Device network to join the Google Graveyard like so many other interesting projects.

So, for now, these are great if you're within a few hundred metres of them. And they're barely adequate under any other circumstances.

No passwords. No magic links emailed to you. No FIDO tokens. No codes via SMS. Just a TOTP generated and displayed on your device.

Is that useful? Sensible? Practical?

It's certainly technically possible. Store the username, store the TOTP seed, done. Your users can now log in.

Is it useful? Well, it would force users to not reuse passwords they've used elsewhere. That prevents one class of security issue. If another service gets hacked, attackers can't use those credentials with your service. If you get hacked, there are no passwords stored.

As for practical? I already have 60 TOTP codes! (That's up from 30 a few years ago). Scrolling through those codes is no harder than scrolling through my password manager.

So, sensible? This all depends on your risk tolerance.

• A 6 digit TOTP code has a million combinations. If your service has no rate limiting, that's trivial for an attacker to brute-force.
• An attacker might get lucky and score a literal one-in-a-million hit.
• Shoulder surfing attacks are easier if the password is only 6 digits (although harder with a short time-window).

Should you build an authentication mechanism like this?

Ehhhh… I'm going to go with "mostly no, except in limited circumstances". It might make life slightly easier for some users. But I feel inherently icky about having such a short password, even if it does regularly rotate. If this is a low-value service without sensitive information, it might be useful. But for everything else, I think it is a silly ideas.

Further discussion on Mastodon.

This was the era of the iPhone 5 and Android KitKat. BlackBerry was trying to have (yet another) resurgence and Nokia was desperately trying to keep Windows Phone alive. What advice did I give then, and is it still relevant?

Stay Sceptical

In at number five is just stay sceptical. I mean, quite often, lots of mobile viruses and mobile scams spread by text message, by email, by Twitter. And these are all things that we get on our phone. But for some reason, because they seem to come from people we trust, all of our savvy just goes out the window. When you see a message from someone which purports to be your friend, just think, does this sound like them? Is what they're asking me to do a rational thing to do? And when you go and click on a link that someone has sent, check to see if it's actually taking you to where you expect to go.

Still entirely relevant, sadly. You've probably received an SMS saying "Mum, I've dropped my phone. This is my temporary number." Or accidentally clicked on an advert which prompts you to hand over your credentials.

Scams are everywhere. One of the best things you can do to protect yourself and your data is to be less trusting.

Browsers are getting better at sharing real-time blocklists. So clicking on an extremely dangerous website is likely to generate a scary warning. But these technologies aren't perfect.

Don't just change your password

So what can I do if I have ended up putting my password into a fake site?

The most important thing you have to do is, if it's something like Twitter, go to settings and you'll see all the applications which have authenticated against that. You just need to go and delete all of those and then change your password.

This is something that a lot of sites still get wrong. If a baddie has got your password, they can use OAuth to connect your account to their service. Changing your password doesn't sever the link!

2FA

If you want to be really security conscious, you can turn on something called two-factor authentication. This means you give your mobile number to the social network. When you try to log in, what will happen is you type in your username and your password and then Twitter will send you a text message and it says your one-time password is 12345. You type that code in and you're logged in. That way, if someone does manage to get your username and password, it doesn't matter because they don't have your phone as well.

I encouraged people to use SMS as their preferred way of enabling Multi-Factor Authentication. Back then, that was pretty much the only choice for normal people. Facebook wouldn't introduce non-SMS MFA until 2018.

Nowadays, I'd probably recommend using an authenticator app which generates TOTP codes. SMS is basically fine for normal people - yes, it can be spoofed or hacked at a network level, but that's unlikely unless you're specifically targetted.

Official App Channels

Don't download apps outside of the official app store. Now, the app stores aren't perfect. You can get dodgy apps in there, but there is some safety in numbers.

Reluctantly, I think I still agree with this. Back in the day, it was too easy to install dodgy apps. Drive-by downloads were common, and Android had a particularly poor model of security.

I value independent app stores like F-Droid and Aurora - but there's no doubt that they are generally for the more advanced users. And, yeah, app stores aren't perfect, but they're still less likely to completely infect your phone and send premium rate messages.

Virus Checkers

you can download apps which are virus checkers of a sort. I'm quite keen on Lookout, which is a great Android app. Whenever you install something, it will check it and it will look through the list of permissions, alert you, but it will also look at the app and see whether it's been reported that it's a scam or a virus.

These days, I think virus checking apps are less useful. The permissions model of Android and iOS are much improved, and it's harder for apps to do bad things in the background.

If you have a corporate device (or personal device with work mode) an app scanner is usually mandatory as part of your employer's Mobile Device Management policies. Again, I'm not totally convinced they're a brilliant idea. They can be useful for peace of mind, or to prevent certain classes of attacks.

Password Managers

Lots of people use really short passwords. Why? Because they're easy to remember and they want to be able to type them into their mobile phone. And this means that people quite often have the same password for Twitter as they've got for Facebook, as they've got for email, as they've got for everything else. This is a real security nightmare because it means that if your Twitter password gets hacked, those hackers have access to everything, all your accounts. So my top tip is use a password manager.

Yup! No notes. Get a password manager. I like BitWarden - but pick whichever meets your needs.

Physical Security

This is my number one tip for mobile security. Buy a wrist strap.

On your phone, you probably have a case. It's got a little hole and you can buy a lanyard, a bit of string or a bit of leather that you clip onto your phone and you wrap around your wrist while you're using it.

Recent reports said 10,000 phones are stolen in London every month, 120,000 a year. That's just in London. Across the UK, it's hundreds of thousands. If you're wearing a wrist strap, it is much more unlikely that someone will be able to yank the phone away from you, because if they do yank the phone away from you, chances are it's unlocked because you are making your call, you're looking at Google Maps and hey presto, they've got access to all of your email, all of your documents. They can start making premium rate phone calls straight away.

I still stand by this. In London, a phone is stolen every 6 minutes - only 2% of them are ever recovered.

Strap your phone to you. Don't leave it on the table when you're in a pub. If you need to check directions, turn away from the street and hold it in both hands.

Phones are now worth thousands of pounds. They are a high-value target. You probably have a banking app on your phone - or contactless payment set up. Treat your phone as though you were carrying a big wodge of notes.

Another part of physical security is:

The other thing that you need to do is set a PIN or a password on your phone. You can use facial recognition or a thumbprint scanner. Anything to stop a casual thief being able to get into your phone is of paramount importance.

If your phone is stolen while it is unlocked, you're shit out of luck. If it's locked, it is much harder for all but the most determined attacker to get in to it. Make sure all your banking apps have passwords on them.

Similarly, a SIM lock is essential. You don't want someone ejecting your SIM card and making expensive calls on it.

I also suggested:

Set up Find My Phone. If you're on Android, Android Device Manager, this means that if your phone is stolen, you can find out where it is. But much more importantly, you can click a button and have your phone be completely wiped

Again, solid advice. Perhaps all that will happen is you'll see your phone visit China. But at least you'll be able to prevent the thieves getting into your data.

VPNs

One of the hosts made this comment:

If you're not familiar, a VPN is when you make a secured connection back to a server and all the data through that pipe is encrypted. And the reason for doing that is that when I'm in a coffee shop or I'm on a public Wi-Fi network or something like that, it keeps my data secure because it doesn't matter whether the app does a good job of securing it or not. It gets it all encrypted as it goes over the network.

Nowadays a VPN is less useful than it was. Let's Encrypt launched later that year and with it brought a dramatic increase in the number of Internet services which used HTTPS. The popularity of HSTS increased, which means that most apps refuse to connect to non-secure versions of their site.

VPNs do protect you if unencrypted data is flowing through your device - but that is becoming rarer. I lean slightly towards the opinion that a VPN is usually a bad idea. They are, effectively, an untrusted connection between you and your destination. A malicious VPN - or one ordered to behave in such a way - is worse than no VPN.

What would I add to the list?

I think there are a few sensible additions.

0. Back up your data. Accept that, at some point, your phone will be compromised or stolen. Ensure you have safe backups of all your stuff.
   • Actually test your backups. For most people, that means regularly look inside them to make sure all your photos are still there.
1. Activate your phone's emergency features. Learn which buttons to press to automatically lock and/or disable your phone.
   • Practice using them. You may need to use them in an emergency.
2. Make sure your Password Manager and MFA tokens can be accessed from another device.
   • Once your phone has gone, you will still need to get into accounts to lock them down.
3. Install an ad-blocker. Not only will it protect your sanity; you're less likely to see dodgy content.
   • Do it on mobile and larger devices.

Stay safe out there!