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.

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⁷.

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?

Nowadays, thieves are not only snatching phones, but forcing their owners to transfer money to the thieves. This is not an isolated incident¹.

How can you protect yourself from such a situation²?

Broadly speaking, there are four ways to protect your sensitive apps. Relying on the regular lockscreen, hiding the apps, using a Private Space, or placing the apps in different profile. Let's look at the advantages and disadvantages of each approach.

Regular Lockscreen

Android's lockscreen controls are pretty good - if you turn them on.

Perhaps you have a super-long and complicated password. Maybe a 10 digit PIN that only you know. Biometrics like facial recognition and fingerprints are reasonably strong and fairly convenient.

But that relies on your phone being locked when it is snatched. If you're using your phone when it is taken from you, the lockscreen might detect it and lock automatically, but you need a modern device and to have specifically enabled the setting.

If a thief has shoulder-surfed your 4 digit PIN, that will be enough to let them enter your phone.

But here we are concerned with someone threatening you. Basically, if someone has a knife pointed at you, you're probably going to unlock the phone for them³. So, let's assume we want to protect our banking apps from someone who has access to your unlocked device.

Launcher Hiding

Some Android phones let you hide apps. When an attacker is scrolling through the list of installed apps, they won't be able to see any apps which are hidden.

This, I think, is a reasonable way to hide your banking apps. You can show the thug that there aren't any installed. That may or may not be enough to mollify them. They might still nick your device, but you won't be forced to transfer your savings elsewhere.

This, of course, presents a problem for the regular user. How do you launch your apps if you can't find them? Most launchers will let you type in the name of the app to find it - the app is merely hidden from the default list.

So an attacker would have to try typing "HSBC" or "Barclays" or "Chase" or a dozen different names until they find your app. Will they be angry if you've lied to them? Is that a risk you want to take?

Some launchers will let you change the name and icon of your sensitive apps. You can rename "Midland Bank" to "Calculator" and change its icon. Not every launcher supports this sort of hiding though. It also places a cognitive load on you that you need to remember what you've hidden your apps as. Will you remember than Bank 1 is calendar and Bank 2 is Bumble?

Private Space

Android 15 has introduced the concept of a Private Space. It is like a digital lock-box for your apps. If someone has your unlocked phone, they need to pass through authentication in order to use apps which are locked.

There are two main drawbacks with this approach.

Firstly, locked apps don't run in the background. That means you won't get alerts from them. If you rely on push notifications to tell you if someone is using your card fraudulently, this could be a problem.

Secondly, the Private Space shows up at the bottom of your app list like this:

So an attacker can easily see it and demand that you open it up. You can set the Private Space to be hidden. But then you're in the same position as above - typing in "private space" will show it in your launcher.

Work Profile

Android has the concept of "Work Profiles". They're designed to segregate your work apps and your personal apps. Your work admin can wipe your work profile without touching your personal stuff, and you can't copy confidential emails to your personal area. Nifty!

If you don't have work apps on your phone, you can use an app like Shelter to make your own Work Profile.

You can stick your banking apps in the Work Profile and have them locked away from prying eyes.

The Work Profile button is more subtle than the Private Space.

But it still has the disadvantage that, once locked, the apps are suspended and won't receive any alerts.

Secondary Profile

Finally, modern versions of Android support multiple profiles. They're generally designed so that multiple people can use your device - but there's nothing stopping you from putting your banking apps in there.

The immediate advantages of multi-user profiles are:

• The profile can be protected by a separate password.
• The profile switcher is generally more subtle than the Work Profile switcher or Private Space toggle.
• Apps can run in the background while in a separate profile.

The disadvantage is that, because it is a completely separate profile, you'll need to sign in again using your Google account in order to install apps from the Play store. If you use a password manager and MFA app, you may need to install them in both your main and secondary profile.

Because the apps can run in the background, there may be some (minor) impact on battery life - you're effectively running Google's Notifications Service twice.

If you are being held at knifepoint and a notification from your bank comes through - you may find it socially awkward to explain.

Which is right for me?

It is complicated. I think I can distil it down to the following:

• If you need alerts from your banking apps - put them in a secondary profile.
• There are some reports of banking apps not working in secondary profiles - if yours don't work in a profile then hiding apps is your best defence.
• If you're not using Work Mode and don't need alerts - put them in Work Mode.
• If you're using Work Mode and don't need alerts - put them in a Private Space and set the space to be hidden.

Remember, you can't fling technical solutions at social problems and expect them to solve everything. In general, crime in England and Wales is at its lowest level but certain crimes, like phone theft, are on the rise. Despite all the technology thrown at the problem, people are still walking around holding machines worth hundreds of pounds. Each of those machines is a gateway to potentially thousands of pounds. Phones and banking apps are incredibly lucrative targets.

The aim of this exercise isn't to solve the problem of crime. It isn't even to make you a less attractive target. It is to allow you to hand over your phone safe in the knowledge that your banking apps are somewhat protected from miscreants while still being useful to you.

If you have any tips on how to keep banking apps hidden, please leave a comment.

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!

"Yeah, right!" You think. Obvious scam, isn't it? You tell the caller to do unmentionable things to a goat. They sigh.

"I can assure you I'm calling from Chase bank. I understand you're sceptical. I'll send a push notification through the app so you can see this is a genuine call."

Your phone buzzes. You tap the notification and this pops up on screen:

This is obviously a genuine caller! This is a genuine pop-up, from the genuine app, which is protected by your genuine fingerprint. You tap the "Yes" button.

Why wouldn't you? The caller knows your name and bank and they have sent you an in-app notification. Surely that can only be done by the bank. Right?

Right!

This is a genuine notification. It was sent by the bank.

You proceed to do as the fraud department asks. You give them more details. You move your money into a safe account. You're told you'll hear from them in the morning.

Congratulations. You just got played. Scammers have stolen your life savings.

How the scam works

This is reasonably sophisticated, and it is easy to see why people fall for it.

1. The scammer calls you up. They keep you on the phone while...
2. The scammer's accomplice calls your bank. They pretend to be you. So...
3. The bank sends you an in-app alert.
4. You confirm the alert.
5. The scammer on the phone to your bank now has control of your account.

Look closer at what that pop is actually asking you to confirm.

We need to check it is you on the phone to us.

It isn't saying "This is us calling you - it is quite the opposite!

This pop-up is a security disaster. It should say something like:

Did you call us?

If someone has called you claiming to be from us hang up now

Yes, I am calling Chase - No, someone called me

I dare say most people would fall for this. Oh, not you! You're far too clever and sceptical. You'd hang up and call the number on your card. You'd spend a terrifying 30 minute wait on hold to the fraud department, while hoping fraudsters haven't already drained your account.

But even if you were constantly packet sniffing the Internet connection on your phone, you'd see that this was a genuine pop-up from your genuine app. Would that bypass your defences? I reckon so.

Criminals are getting increasingly good at this. Banks are letting down customers by having vaguely worded security pop-up which they know their customers don't read properly.

And, yes, customers can sometimes be a little gullible. But it is hard to be constantly on the defensive.

Further reading

You can read the original story from the victim on Reddit. See more comments on Mastodon.

I went to type in my 2FA code on a website - but no numbers appeared on screen. Obviously, I was an idiot and had forgotten to press the NumLock button. D'oh! I toggled it on and typed again. No numbers appeared. I switched to another tab, my numbers appeared when I typed them. So I was reasonably confident that my keyboard was working.

I swapped back to the 2FA entry and tried again. Still nothing. Then I tried typing the numbers using the number row on my keyboard. My 2FA code appeared.

WHAT IN THE SAINTED NAME OF ALPHONSE CHAPANIS IS GOING ON?!?!?

Developers often use JavaScript to "improve" the standard features of HTML. For example, using <input type="number"> has some accessibility concerns and using inputmode="numeric" is great for showing a number key board on mobile, but not much else.

So a developer wants a reliable way to make sure a user can only type numbers. Fair enough.

There are two ways to do this - a right way and a wrong way - using KeyboardEvent.

One way is to listen for the character being sent from the keyboard - known as the key.

The other is to listen for the button being pressed on the keyboard - known as the code.

A good demo of this is at keyjs.dev - play around with it to see what keyboard buttons your browser can detect.

When I press 7 on the top row of my keyboard, the key is 7 and the code is Digit7.

But when I press 7 on my number pad, the key is 7 but the code is Numpad7.

The JavaScript on the website was rejecting any key code which wasn't a "Digit"!

Perhaps I am a weirdo for insisting on both having and using my numpad? Perhaps developers need to test on something other than MacBooks? Perhaps JavaScript was a mistake and the Web would be better without it?

Either way, don't be like that website. Let users type in using whatever keys they like.

I was trying to explain why link shortners like bit.ly and ow.ly weren't sensible for Government use. They didn't seem to particularly care about the privacy implications or the risk of phishing. I needed to take a different tack.

"So, you know how .uk is the UK and .de is Germany, right?"
"Yes."
"What country do you think .ly is for?"

There was some consulting of ISO 3166-1 alpha-2 whereupon the blood drained from their face and they stepped outside to make a phone call.

A little while later, the National Cyber Security Centre published an explainer about why they weren't using bit.ly any more.

Throughout my time in the Civil Service I advocated for the use of .gov.uk URls everywhere. They're a trusted destination for users, they're under Government control so are less likely to be hijacked, and they don't require users to give their data to third parties.

I helped the Government Communication Service write "Link shorteners: the long and short of why you shouldn’t use them."

Today, in the post, I received six QR codes for Government services. Let's take a look at them.

The Good

Policing Surrey have a QR code which points to surrey-pcc.gov.uk/...

Excellent! 10/10! No notes.

Woking Council send out this code which use qr.woking.gov.uk

Brilliant! The use of the qr. subdomain means they can easily track how many people follow the link from the code.

The Bad

Childcare Choices is a leaflet which is, I assume, shoved through everyone's letterbox. All the URls in the leaflet say gov.uk² - but what happens when you scan?

Our old friend enemy Bitly. A user scanning this has no idea where that code will take them. They cannot access the content without giving their data away to Bitly.

Surrey also sent me a leaflet with two different QR codes.

There are many reasons not to use .io. Of particular interest is the scnv.io privacy policy which, if you click that link, you will see is missing from their website! What does this company do with the data of people who scan that code? No one knows!

The Ugly

Surrey police started so well, but the back of their leaflet is a major disappointment.

Aside from using an unintelligible Bitly link, the QR code is inverted. The QR standard is very clear that the codes should be black-on-white. Some scanners will have difficulty scanning these white-on-dark codes. They may look æsthetically pleasing, but it's a pretty rubbish experience if you can't scan them.

Now What?

I've been writing about QR codes for 17 years! I'm thrilled that they've finally caught on. But, like any piece of technology, they need to be used sensibly. The rules are pretty straightforward - mostly boiling down to testing your codes and keeping them simple.

Is there a risk risk of QR hijacking? Possibly. The best defence is to train users to look for a trusted URl.

In this case, using link shorteners is training users to be phished. If they are used to official Government QR codes going to weird locations, they won't notice when a scammer tries to send them to a dodgy site.

Please practice safe QR generation!

HTTP Message Signatures are hard⁰. There are lots of complex parts and getting any aspect wrong means certain death¹.

In a previous post, I wrote A simple(ish) guide to verifying HTTP Message Signatures in PHP. It turns out that it was too simple. And far too trusting.

An HTTP Message Signature is a header which is separate to the message it signs. You might receive a JSON message like this:

{
   "actor":   "https://example.com/user/Alice",
   "message": "We strike at dawn!"
}

How do you know that really came from Alice? You look at the header of the message. It will be something like:

Signature: 
   keyId="https://example.org/user/Alice#main-key",
   algorithm="rsa-sha256",
   headers="(request-target) host date digest",
   signature="/AJ4Dv/wSL3XE1dLjFHCYVc7AF4f3+Q10G/r8+6cPsooiUh2K3YX3z++Nclo4qKHYr61yu+T4OMqUry1T6ZHmZqmNkg1RpVg=="

We want to check that Alice signed this message with her private key. So we grab her public key given by the keyId. From there, we do some fancy maths using RSA-SHA256 and conclude that, when you put together the (request-target) host date digest content-type and compare them to the public key, they can only have be signed by the private key. Hurrah!

Did you spot the mistake I made? It wasn't in the maths, or the complex ordering of the data, or the algorithm choice, or some weird Unicode problem.

I made an error in trust.

Take a look at the Signature again.

The keyId is from example.org. But the actor is from example.com.

This message is signed correctly. It is cryptographically valid. But it wasn't signed by the actor in the message!

In this case, the fix is simple. Get the public key from keyId. Then independently get the named actor's public key. If they match, all is well. If not, skulduggery is afoot.

I'm almost tempted to say that you should ignore the provided keyId entirely; the source of truth is the actor's key - and the best way to get that is directly from the actor's profile.

Please explain why I'm wrong in the comments.

I put in a random number, and it refused to let me in.

Putting in a genuine O2 number let me through. So what is it doing to validate numbers?

It is making an API call to this URl:

https://www.o2.co.uk/o/customer/mods/lookup/447700900123

After a bit of testing, this is how I think it works.

If you give it an O2 phone number, it replies with:

{"type":"ONE"}

If you give it a number which isn't on O2, it gives:

{"type":"ZERO"}

A number it doesn't recognise gives:

{"message":"Unable to find the requested resource."}

A malformed or incomplete phone number gives:

{"message":"Something's wrong. Please try again later."}

Responsible Disclosure?

As far as I can tell, O2 no longer have a Bug Bounty or Responsible Disclosure offering. So I'm publishing it here to let people know.

It is possible that someone could use this API to disclose a (minor) piece of personal information about you - namely whether your phone number is on O2 or not. I don't think that's particularly sensitive, but it is probably worth knowing.

This is a quick example to show how to verify these signatures using PHP. I don't claim that it covers every use-case, and it is no-doubt missing some weird edge cases. But it successfully verifies messages sent by multiple Fediverse servers.

Let's step through it with an example of a message sent from Mastodon to my server.

Headers

The HTTP request starts with these headers:

User-Agent:  http.rb/5.1.1 (Mastodon/4.3.0-nightly.2024-02-23; +https://mastodon.social/)
Host:  example.com
Date:  Sun, 25 Feb 2024 10:48:22 GMT
Accept-Encoding:  gzip
Digest:  SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=
Content-Type:  application/activity+json
Signature:  keyId="https://mastodon.social/users/Edent#main-key",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="
Connection:  Keep-Alive
Content-Length:  2857

Some of those you may be familiar with, some not. The first thing we'll do is a sanity check; was this message sent recently? Because clocks drift in and out of synchronisation, we'll check if the message was within ±30 seconds.

$headers = getallheaders();
if ( !isset( $headers["Date"] ) ) { return null; }  //  No date set
$dateHeader = $headers["Date"];
$headerDatetime  = DateTime::createFromFormat('D, d M Y H:i:s T', $dateHeader);
$currentDatetime = new DateTime();

// Calculate the time difference in seconds
$timeDifference = abs( $currentDatetime->getTimestamp() - $headerDatetime->getTimestamp() );
return ( $timeDifference < 30 );

That was easy! On to the next bit.

Digest

A message posted to the server usually has a body. In this case it is a long string of JSON data. To ensure the message hasn't been altered in transit, one of the headers is:

Digest:  SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=

That says, if you do a SHA-256 hash of the JSON you received, and convert that hash to Base64, it should match the digest in the header.

$digestString = $headers["Digest"];
//  Usually in the form `SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=`
//  The Base64 encoding may have multiple `=` at the end. So split this at the first `=`
$digestData = explode( "=", $digestString, 2 );
$digestAlgorithm = $digestData[0];
$digestHash = $digestData[1];

//  There might be many different hashing algorithms
//  TODO: Find a way to transform these automatically
if ( "SHA-256" == $digestAlgorithm ) {
    $digestAlgorithm = "sha256";
} else if ( "SHA-512" == $digestAlgorithm ) {
    $digestAlgorithm = "sha512";
}

$json = file_get_contents( "php://input" );

//  Manually calculate the digest based on the data sent
$digestCalculated = base64_encode( hash( $digestAlgorithm, $json, true ) );

return ( $digestCalculated == $digestHash );

But, of course, if someone has manipulated the JSON, they may also have manipulated the digest. So it is time to look at the signature.

The Signature

Let's take a look at the signature header:

Signature:
  keyId="https://mastodon.social/users/Edent#main-key",
  algorithm="rsa-sha256",
  headers="(request-target) host date digest content-type",
  signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="

This contains 4 pieces of information.

1. keyID - a link to the user's public key.
2. algorithm - the algorithm used by this signature.
3. headers - the headers which make up the string to be signed.
4. signature - the signature string.

Let's split them up so they can be used:

//  Examine the signature
$signatureHeader = $headers["Signature"];

// Extract key information from the Signature header
$signatureParts = [];
//  Converts 'a=b,c=d e f' into ["a"=>"b", "c"=>"d e f"]
               // word="text"
preg_match_all('/(\w+)="([^"]+)"/', $signatureHeader, $matches);
foreach ($matches[1] as $index => $key) {
    $signatureParts[$key] = $matches[2][$index];
}

Let's tackle each part in order.

Get the user's public key

You might think you can just get https://mastodon.social/users/Edent#main-key - but you would be wrong.

Firstly, you need to tell the key server that you want the JSON representation of the URl - otherwise you'll end up with HTML.

$publicKeyURL = $signatureParts["keyId"];
$context   = stream_context_create(
    [ "http" => [ "header" => "Accept: application/activity+json" ] ] 
);
$userJSON  = file_get_contents( $publicKeyURL, false, $context );

That gets you the JSON representation of the user. On Mastodon, the key can be found at:

I don't know how to automatically find the key, so I've hard-coded its location.

$userData  = json_decode( $userJSON, true );
$publicKey = $userData["publicKey"]["publicKeyPem"];

Get the algorithm

This is rather straightforward. It's just the text in the signature header:

$algorithm = $signatureParts["algorithm"];

Reconstruct the signing header

Let's take a look at the third piece of the puzzle:

headers="(request-target) host date digest content-type"

This says "The signature is based on the following parts in order". So we only care about the headers which make up the request, the host, the date, the digest, and the content type. Other servers may require different parts of the headers.

Again, let's tackle them in order.

(request-target)

This means the method of the request and the target it was sent to. In our example, this is a POST sent to the path /inbox.

host

This is the HTTP host the message was sent to. This should be retrieved from the server, not taken from the sent headers.

date digest content-type

These are the values from the headers which were sent with the request.

Putting it all together

Annoyingly, the HTTP headers are written in Title-Case whereas the headers in the Signature are in lower-case. So some conversion is necessary:

//  Manually reconstruct the header string
$signatureHeaders = explode(" ", $signatureParts["headers"] );
$signatureString = "";
foreach ($signatureHeaders as $signatureHeader) {
    if ( "(request-target)" == $signatureHeader ) {
        $method = strtolower( $_SERVER["REQUEST_METHOD"] );
        $target = strtolower( $_SERVER["REQUEST_URI"] );
        $signatureString .= "(request-target): {$method} {$target}\n";
    } else if ( "host" == $signatureHeader ) {
        $host = strtolower( $_SERVER["HTTP_HOST"] );    
        $signatureString .= "host: {$host}\n";
    } else {
        //  In the HTTP header, the keys use Title Case
        $signatureString .= "{$signatureHeader}: " . $headers[ ucwords( $signatureHeader, "-" ) ] . "\n";
    }
}

//  Remove trailing newline
$signatureString = trim( $signatureString );

This results in a string like this:

(request-target): post /inbox
host: example.com
date: Sun, 25 Feb 2024 10:48:22 GMT
digest: SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=
content-type: application/activity+json

Get the signature

The signature that we are sent is in Base64.

signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="

It needs to be decoded before we can use it.

$signature = base64_decode( $signatureParts["signature"] );

Verify the signature

We're nearly there! Luckily, we don't have to do any crazy cryptography by hand. We use PHP's openssl_verify():

//  Finally! Calculate whether the signature is valid
$verified = openssl_verify(
    $signatureString, 
    $signature, 
    $publicKey, 
    $algorithm
);

That takes the reconstructed string based on the headers, the signature which was sent, the public key we retrieved, and the algorithm.

If it all matches, it will return true. If not... time for some debugging!

But what about...?

This is not a complete solution. My code almost certainly contains bugs, unforeseen edge-cases, memory leaks, black holes, and poisonous frogs. This is intended to step you through the practical process of verifying an HTTP Message Signature.

Then you should get a properly tested and validated library and use that instead.

A few weeks ago, we were discussing the need for better cybersecurity in their architecture. We spoke about several aspects of security, then they asked an outstanding question.

"What should I buy to be secure?"

It took a few moments to tease out exactly what they thought they were asking. In their mental model they could just buy a box which did what they needed. Want to print from any workstation? Buy a big HP network printer. Want to get WiFi in the office? Buy a bunch of access points. Want a website? Buy a WordPress. Want security? Buy a [fill in the blank]?

Their notion is that most things are products. This is a common belief. I've had clients ask "What do I buy to make this accessible?" or "What can I buy to improve usability?"

In all these cases there are unscrupulous people who will sell you a magic cure-all - but the real answer is that these things are a process; not a product.

Yes, you can buy tools which will help improve your security / accessibility / usability etc. But unless you put processes in place to get people to use them effectively, the tools are useless.

People need to understand why something is important. They need processes which support best practices. The business needs a holistic understanding of how these processes improve the business. And that is all underpinned by tools which make it possible.

There's no magic box which can both protect you from your CEO accidentally CCing confidential data to a competitor and stop DDoS attacks. An accessibility overlay won't help you if your staff refuse to incorporate alt text into their workflow. Automated code testing can't stop you building things without testing them with users.

Security is a verb - it is a doing word. Accessibility is a verb - it is a doing word. Usability is a verb - it is a doing word.

Buy nouns which support your verbs.

The answer is... A big list. The HTTP Strict Transport Security (HSTS) list is a list of domain names which have told Google that they always want their website served over https. If the user tries to manually request the insecure version, the browser won't let them. This means that a user's connection to, for example, their bank cannot be hijacked. A dodgy WiFi network cannot force the user to visit an insecure and fraudulent version of a site.

After about a decade of use, the list is now 14MB in size, with around 130,000 entries in it. You can view the list online or download it.

The format is relatively straightforward:

{
 "name": "example.com",
 "policy": "bulk-1-year",
 "mode": "force-https",
 "include_subdomains": true 
},

When the list is updated, Chrome creates a trie with Huffman coding compression - so it doesn't have to parse that monster file each time.

A rummage inside

The most popular (over 1,000 entries) TLDs / Public Suffixes are:

After .com, the free .tk domain names absolutely dominate. I wonder how many of them are fraudulent?

There are 2,676 .uk domain names - only 537 of which aren't on .co.uk.

Going a bit further, there are 418 IDNs (which start with xn--).

And about 187 have "porn" in the domain.

You can't really extrapolate much from this as a data set. Lots of the domains seem to have expired or otherwise no longer work. Reading around https://hstspreload.org it notes that because this list is hard-coded into Chrome it can take months before a site is added. Similarly, removal can take a long time as well.

I can't help feeling that there should be a better way to manage all this though.

What do you think happens if you visit: https://mastodon.social/@PasswordReset/111285045683598517/admin?

If you aren't logged in to that instance, it will redirect you to a 3rd party site. Try opening it in a private browser window.

Here's another, less convincing, demo:

https://mastodon.social/@mastodonopenredirect.wordpress.com@mastodonopenredirect.wordpress.com (You will need to not be logged in to Mastodon.Social for this to work.

It is possible to craft a URl which will redirect any visitor who isn't logged in. Attackers can use this as an open redirect for phishing, spam, and other attacks.

Remediation

This will likely be fixed by #26917. But, in the meantime, administrators of Mastodon instances should be aware that their site could be used as an open redirect.

If you do spot any accounts which appear to be dodgy, admins can either block the account or the entire domain.

Background

Here's how it works - which involves some necessary background detail.

I am user @edent on Mastodon.social. I can send you a URl of https://Mastodon.Social/@edent and you will see my profile. Nice!

But there are lots of Fediverse servers out there. For example, I run a little bot called @colours on the BotsIn.Space instance. Its URl is https://BotsIn.Space/@colours - simple.

But what happens if I am viewing the Colours bot while on Mastodon.Social?

The interface shows https://Mastodon.Social/@colours@BotsIn.Space - if you are logged in to Mastodon.Social, you will see the colours account, you can follow it, reply to it, and interact with it as though it were a user on your home instance.

But what if you're not logged in?

If you visit https://Mastodon.Social/@colours@BotsIn.Space you will be immediately redirected to https://BotsIn.Space/@colours

In theory, this is a good thing! You get taken to their home server and you can see their latest updates etc.

Unfortunately, this can be abused.

Try and visit https://botsin.space/@blog@shkspr.mobi - if you are not logged in to BotsIn.Space, you will be automatically redirected to my blog.

In addition, Mastodon ignores the @username when it sees a local status ID which references an external status. For example, both of these URls will go to the same place:

• https://mastodon.social/@colours@botsin.space/111323978746693908
• https://mastodon.social/@RandomLettersAnd1234/111323978746693908

Impact

A malicious user could do a few things.

The first is spam evasion. Email out a link to mastodon.social/@user@buy_illegal_puppies.com and it might skip spam filters, or confuse the user about the true destination.

The second is phishing. Is a user going to notice that they've been silently redirected to nnast0d0n.social? Stick up a convincing "Please log in again" page and you can steal their credentials.

Why This Works

ActivityPub uses the Well-Known / WebFinger specification. Mastodon will use this to find data on anything which looks like a username.

For example, here's what my blog's account looks like in WebFinger: https://shkspr.mobi/blog/.well-known/webfinger?resource=acct:blog@shkspr.mobi:

{
  "subject": "acct:blog@shkspr.mobi",
  "aliases": [
    "https://shkspr.mobi/blog/@blog"
  ],
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://shkspr.mobi/blog/@blog"
    },
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://shkspr.mobi/blog/@blog"
    }
  ]
}

Mastodon will check that account exists, and then redirect a non-logged-in user to the "profile-page" of an account that it finds.

So a malicious user can create a WebFinger at evil.com, then send out links to mastodon.example/@SexyFunTimes@evil.com, and have users instantly redirected to their site.

Most ActivityPub instances won't do this unless they've already seen the user being referenced. This can be achieved by sending a private message to a user on that server which mentions the redirection account.

Remediation

Given that it is sensible to redirect users to an account's home instance, I think there's really only one way to solve this. An annoying interstitial.

You are leaving XYZ.social. We do not control the page Illegal_Ivory_Smuggling.com. If you are sure you want to proceed, click here. Do not share your username and password with 3rd party sites etc etc etc.

I reported this to Mastodon on 2023-09-20. Apparently a number of other people have also reported it. While they work on how to fix the problem, I thought it was sensible to let people know that this attack was possible.

Timeline

• 2023-09-20 Disclosed on GitHub
• 2023-10-22 Added more details and sought agreement to publish
• 2023-10-29 Checked with various independent Mastodon server admins to see if they were aware of this behaviour - most were not
• 2023-10-30 Published

I started to panic. All my apes money gone!

No. Wait. The other thing. I knew it was a scam from the moment "James from your bank's fraud team" started his patter.

You see, I have multiple phone numbers. And "James" called me on a number which isn't tied to my bank. So I strung him along for half an hour or so pretending to move my money into a safe account, taking ages to wait for an SMS confirmation code, accidentally reading out the wrong one, before cursing him and his lineage even unto the seventh generation. He, in return, introduced me to a whole new range of swearwords from his native tongue and hung up on me. Charming!

Here's how it works, and how you can use this trick.

The easiest way is to get a dual SIM phone. I have my main SIM which holds my primary phone number. That's the number used by my family, my banks, and anyone vaguely trustworthy. My second SIM contains a free disposable PAYG SIM.

That phone number gets given out to retailers, couriers, Gumtree & Freecycle users, pizza delivery, and anyone else who doesn't need my number permanently.

My Android phone tells me which line is being called. And once I start getting too much spam to that number I throw the SIM away and get a new one with a new number.

If you have an eSIM, you can do the same thing. Find a cheap eSIM provider, sign up to a PAYG or monthly plan, then ditch the number whenever you like.

Or, you can set up a SIP calling plan. Install an app and have calls automatically routed to you.

About a dozen years ago, I worked with a UK mobile network to develop "disposable" phone numbers. The idea was that we would partner with, say, a dating app and generate a new phone number for you. Your date could call and text you without you having to reveal your real number. If they turned out to be a jerk, you could revoke the phone number immediately.

The same tech could work for hiring a plumber, getting a takeaway, or a hundred different use cases. The plan was to have an app which displayed a push-notification telling you which number was being called - so you knew if it was from your temporary lover or the person picking up your old sofa.

Sadly, the demo never went anywhere. It's a pity. I'd love to have a SIM with multiple disposable numbers.

But, for now, give out your temporary number to people who don't need a way to permanently contact you. Better safe than sorry!

WTF? This would give them complete access to my app's Twitter account, the ability to send and receive messages, and anything else that my API key allows.

Giving them - or anyone - the entire set of credentials would be a very bad idea.

What's going on?

Twitter's slow-motion collapse and hostility to developers is causing a whole bunch of second-order effects.

Lots of services let people log in to them using Twitter. It is (was?!) a quick way to do identity management without having to bother the user with a separate username and password. Once someone has logged in, it's nice to be able to show their user avatar.

Annoyingly, Twitter never had a simple solution for that. You couldn't take my username - edent - and then grab twitter.com/edent/avatar.jpg. Instead, you had to perform an API call to get the image.

So a whole bunch of services started up which would retrieve Twitter avatars based on username. And they also did the same for Facebook, GitHub, Google, and lots of other OAuth providers.

I was using Cloudinary's Social Media Profile Pictures feature. But with Twitter's complete inability to serve API users, that functionality is going away.

Last week Cloudinary said that they could keep the functionality going if I was willing to provide my API keys. I (somewhat impolitely) complained to Cloudinary that them asking for all the API keys was a security nightmare. They responded (politely) to my points:

I completely understand your concerns. Twitter's recent limitations to their API have made it so that we are unable to continue to use our own API credentials to allow customers to fetch Twitter assets, and so we must implement customer credentials instead. We were working on a long-term resolution, but they cut off our API access without warning, and so the temporary solution to minimise disruption was to request your credentials so our backend team can add in a rule to run your Twitter API requests with your own credentials. As such, we require both the API key and secret, along with the access token and secret.

...

As mentioned, this is just a temporary measure in order to ensure continued delivery of your assets. If you prefer to wait until we have a customer-facing portal to enter your Twitter account credentials, then you are certainly welcome to do so. Unfortunately I don't have an ETA on when such a solution might be available, however we will do our best to keep you updated.

I understand that they don't want users to have a degraded experience. And I understand that Twitter have screwed them over. And I'm sure that they're a thoroughly trustworthy company who will never get hacked. But asking customers to fatally compromise their own security like that is not acceptable.

Can't you just...?

Twitter doesn't offer a stable avatar service. Users can change their profile picture at any time, and the URl to the old image stops working. So caching the profile picture URl often leads to a broken image. Caching an old image can mean showing something outdated.

The API rate limits are pretty small for any service with heavy traffic.

Not showing a user image - or just the Twitter icon - could work. But it makes for a pretty crappy experience.

Telling everyone to leave Twitter and join Mastodon would be nice.

Creating a bespoke read-only API key could work - but Twitter now limits the number of apps a develop can have unless they pay stupid money.

It is entirely understandable that people would panic and hand over the keys to their (digital) kingdom. Fear makes people do dangerous things.

Anyway, this Mastodon post sums it up the best:

Post by @RickiTarr@beige.party

View on Mastodon

HOWTO

This uses Luca Dentella's TOTP-Arduino library.

You will need a pre-shared secret which is then converted into a Hex array. Use the OTP Tool for Arduino TOTP Library to get the Hex array, Base32 Encoded Key, and a QR Code to scan into your normal TOTP generator.

Add the Hex array into the code below.

To check that it is functioning correctly, either scan the QR code from the OTP Tool above, or use the Base32 Encoded Key with an online TOTP generator.

Here's how the code interfaces with the Watchy:

#include <Watchy.h> //include the Watchy library
#include "settings.h"
#include "sha1.h"
#include "TOTP.h"

class MyFirstWatchFace : public Watchy{ //inherit and extend Watchy class
    public:
        MyFirstWatchFace(const watchySettings& s) : Watchy(s) {}
        void drawWatchFace(){

          ...

          RTC.read(currentTime);
          time_t epoch = makeTime(currentTime) - 3600; // BST offset


          // The shared secret - convert at https://www.lucadentella.it/OTP/
          uint8_t hmacKey[] = {}; // e.g. {0x4d, 0x79, 0x4c, 0x65, 0x67, 0x6f, 0x44, 0x6f, 0x6f, 0x72};
          int hmacKeyLength = sizeof(hmacKey) / sizeof(hmacKey[0]);

          TOTP totp = TOTP(hmacKey, hmacKeyLength);
          char* epochCode = totp.getCode( epoch );

          display.print(  "TOTP Code Twitter: ");
          display.println( epochCode );

          ...

You can grab the full code from GitLab.

I'm not very good at C++ - so please let me know what terrible mistakes I've made.

Is this a good idea?

Well... Yes and no.

TOTP is a strong-ish form of Multi-Factor Authentication. It helps prevent attacks where someone already knows your username and password. Having a convenient way to get your TOTP codes may make you more likely to use them. It also prevents you from getting locked out of your accounts if your phone dies or is stolen.

Convenient security is good security.

But... Having them on your wrist for everyone to see? I've deliberately made the font as small as I can so it is only readable up close. However, if someone is shoulder-surfing your details, they may well see your wrist. The watch isn't encrypted - so even if you hid the codes behind a button press, anyone who steals your watch will have your codes. If they steal your phone, they need to get through your PIN / biometrics.

Who are your adversaries? If you are trying to evade state-level actors, thieves specifically targeting you for your crypto-holdings, or an untrustworthy spouse - this probably isn't a great idea. If you don't use 2FA because you don't keep your phone with you - this will probably increase your security posture.

Ultimately, all security measures are a trade-off between convenience and control.