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?

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 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?

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.

Multi-Factor Authentication (MFA, 2FA, TOTP, whatever you want to call it) is pretty nifty. You scan a QR code and your phone will continually generate a set of one-time passwords which are synchronised with a remote server.

There's nothing stopping multiple people from scanning that QR code! They will each have the same password displayed at the same time.

I've found this to be useful in a few situations.

If my wife and I have access to the same account, and it doesn't allow individual sign-ins, then we share a username, password, and MFA code. That only works in a high trust environment. If your marriage is not high trust, you may need a different solution.

For a Big Work Project™ we had several people on-call. In case of emergency, someone would ring a "group hunt" number. Any one of the team could pick up. In order to authenticate both the caller and the answerer, all participants had the same TOTP code stored on their phones. That was more sensible than having a dozen different passwords.

There are risks, of course.

• Giving multiple people access to a system increases the risk one of them will be hacked, phished, or attacked.
• Having a secret on multiple devices means multiple chances for it to be leaked.
• Revoking and reissuing keys is more difficult with multiple people.
• It feels icky.

There's nothing which technically stops you backing up or sharing your MFA secrets. But you need to be really sure you understand the risks.

WordPress mandated that I change my password. But was that really necessary?

Firstly, the password was uniquely generated by my password manager⁰. It isn't re-used anywhere else. So there is no chance of hackers breaking in to my email, bank, or OnlyFans account¹.

Secondly, and more importantly, I have 2FA app which provides me with a TOTP code every time I want to log in. Even if the evil ne'erdowells have my username and password, they can't get in without the MFA code².

So, should I change my password?

To understand this, it's worth considering the risks - both of action and inaction.

Changing a password isn't without risk.

• Perhaps some long-forgotten app or service relies on that password. If I change it, what will break?
• Do I trust my password manager to give me a strong password?
• What if the original email is a phishing attempt and I end up giving the baddies my credentials?
• Can I be bothered spending the time maintaining this old account?

As for the risk of inaction.

• Using my details, a miscreant might convince WordPress to disable MFA on my account.
• If there was a breach, my MFA seed secret might also have been stolen.

On balance… yeah, obviously I should change my password. It is a 30 second job with a decent password manager. But, I might argue, there isn't much urgency in doing so.

• A strong and unique password means there is no risk of collateral damage to other accounts.
• The use of MFA adds an extra layer of protection which buys you time.

Thankfully, we've moved on from the outdated advice to regularly change your password. Now we only have to change them when there's been a breach. Which, coincidentally, is every 30 days…

The future ain't what it used to be!

I'm also not a fan of PassKeys⁰. It feels weird to me that my computer is the password. I get the theoretical way it works - but it rubs me up the wrong way.

So, Yubikeys? I find them an annoyance. I never have my keys to hand - which sort of defeats the purpose of them.

A little while ago, I wondered "Where are the U2F Rings?" If I could have a wearable MFA token, that would solve many of my issues¹.

Enter the Cybernetic Z1 Encrypter Ring. It is a US$300 zirconia ring with a built-in range of JavaCard-based NFC apps - including the ability to unlock your Tesla². It is powered by the VivoKey Apex chip (NXP JCOP 4 P71) which provides all the security and functionality. Your money also gets you an NFC reader/writer which connects to your computer via USB. The team have sent me a demo version of the ring to review on the proviso that I give them feedback.

Demo

Here's a quick video showing how it works:

The Good

It works! Seriously, in a world of vapourware and vaguely-worded Kickstarters, it is refreshing to have a product which actually delivers. I was able to enrol it on my BitWarden account and then use it to log in - all via my Android phone. Similarly, I tested it working with Amazon, BitWarden, CodeBerg, Discord, Gandi, GitLab, GoDaddy, Google, PorkBun, Proton, WordPress and a few others.

It's a good looking, plainly designed, unibody ring. It is waterproof and survived the daily abuse I give my hands. It was washed with soap and blasted with a hand-dryer and it kept on chugging. No need to recharge it either - NFC runs off the power of radio waves like magic.

It is completely smooth, no built in scanners or LEDs or power-ports. The antenna appears to be all the way around the ring - so you can use either side of your finger on a scanner.

There is an Android app which you can use to send information to the ring. That's designed for being able to share contact details and has a generous 4KB of storage³.

But, the nice thing is, you don't need the app! By default the ring will work as a FIDO2 token suitable for logging in to a variety of services.

The code on the Ring is (somewhat) Open Source. You can write your own JavaCard applets and load them on to the ring.

The Bad

It works well... until it doesn't. Mostly this is a criticism of FIDO2. I initially was unable to use the ring with GitHub: I tried both Firefox and Chrome but got the same error. Similarly, CoinBase wouldn't register the key and didn't tell me why.

I contacted the Ring's manufacturer and they sent me details of a firmware update which claimed to fixed the issue.

Google worked - but gave me this rather weird default name and icon: I was able to rename it, but the icon can't be changed.

Amazon had the same issue, but with no way to rename.

Both LinkedIn and WhatsApp would only let me create a phone-based PassKey. They didn't give me a prompt to scan my NFC ring.

NFC only is also a bit of a limitation. Until every laptop comes with built-in NFC, you'll need to use a dongle / reader if you want to use the ring. For a phone or tablet with NFC, you're fine. Well, as long as you know where your phone's NFC reader is!

The Android app isn't open source, which feels like a bit of a missed opportunity. It is pretty bare-bones, only providing the ability to add contact details and see how much free storage and RAM there is. In the future, the app promises to offer "Smart PGP" and a few other services.

The contact card stuff is a bit underwhelming. Rather than embed a VCARD, it takes users to a separate website which has your contact details on it.

Weirdly, it zips the content of your contact details and uses them to populate the website with data. Because there's only a limited amount of space available, contact images end up very pixellated. The website also uses external JavaScript without using SRI - which isn't what I'd expect from a security focussed company.

If you use a 3rd party NFC app, you can change the NDEF share to be any URl you want. I think that's probably a sensible thing to do.

Obviously, $300 is a chunk of change. You can buy a basic U2F USB/NFC key for £20 - £50. So, with this, you're paying a higher price for a small-run product with a niche form-factor.

The Ugly?

Do you want to wear jewellery? The Z1 is plain black and unobtrusive - unlike the garish designs of some fashion rings - but perhaps a few different styles and colours would be nice?

I already wear a wedding ring, so having another to wear wasn't too much of an adjustment. The ring comes in a number of US ring sizes, so you may need to compensate if you're used to a different sizing system. However, it is a bit of a chunky beast. You will certainly notice it while wearing it.

Would an attacker rip it off your finger or even chop your finger off? It is a niche risk - but if you're using this to digitally safeguard your billions of crypto-riches, worth thinking about.

Updates

The Z1 Encrypter runs JavaCard applets so, in theory, you can load any compatible app onto it. By default, it runs Bryan Jacobs' FIDO2Applet. It recently received an update which should make it work with GitHub.

To install or update apps, you'll need the Fidesmo Android app or iOS app.

WARNING! Before installing a new app, you have to destroy the old one. This will wipe all your previous registrations.

However, I just couldn't get this to work. I tried using the Fidesmo app to uninstall the Tesla applet - but it failed.

Despite it asking me to uninstall again, there was no option to do so.

I find it a bit weird that the Ring relies on a 3rd party app to do this. I'd much rather see it built into the same app which controls the ring.

Security

By default, the ring has no password set on its internal memory. That means you can write whatever content you want to the NDEF share. Of course, this means someone sat next to you can also change your saved URl! If you use the Fidesmo app, you can lock the contents of the share. Once locked it cannot be overwritten unless you destroy the applet.

So I was able to change the default URl to one I controlled, and I was able to lock it.

But anyone with the Fidesmo app can delete any applet on your ring. Simply open the app, tap the phone against the ring to read the data, select the app you want to delete, and hold the phone against the ring for a few seconds.

It isn't unobtrusive. You'd probably notice someone clutching your hand for a several seconds. But you probably wouldn't notice if you were asleep.

The only damage is rendering your PassKey inoperable. So you would have to revert back to using a different 2FA method. An attacker couldn't steal your data, but they could provide a denial of service attack on you.

It would be great if the ring came with a password. However, there is the risk that if you lost your own password, you'd be unable to write data to it.

I am unqualified to audit the hardware security. If an attacker had physical access to the Ring, could they crack it open and extract the keys from hardware? I don't know.

Linux Support & Open Source

The Cybernetic website says the Z1 supports "iOS, Android, Windows. MacOS coming June 2024." But how well does it work with Linux?

There are several open source tools repositories available from VivoKey - although none specifically related to the ring.

I took a look at a bunch of compatible readers and got the ACR1252u-MF (full review later). There are a couple of Linux utilities which claim to work as NFC U2F readers - but the only one I could get working was Bryan Jacob's FIDO2 HID Bridge. Installing was a bit of a faff (yay various Python incompatibilities) and using it means invoking an obscure command on the terminal. But... it worked!

I registered the ring on a service using my Android device, then I was able to sign in to the same service using Firefox on Linux!

Even better - I was finally able to register the ring with GitHub! And, once I'd registered it using Linux, I could sign on with Android. HASHTAG INTEROPERABILITY!

The Broken

And then I kinda broke it. Somehow, the Fidesmo app ended up locking the entire card. Everything still worked - both NDEF and WebAuthN - but I couldn't update the firmware or applets. On the one hand, no one can wipe my OS! But on the other, I can't load new software or fix any bugs.

NFC is fragile technology. Send the wrong obscure command to the device and it will behave unpredictably.

Final Verdict

For a certain type of nerd, this is awesome. It doesn't have aggressive "geek-chic" branding - it just quietly lets you augment your body with a useful bit of tech. Now I don't need to search for my key-ring every time I want to log into a secure service.

The flaws with this product are mostly to do with the ecosystem. Mostly.

U2F / FIDO2 / Whatever is pretty nifty technology. When it works, it is just like magic. Wave your hand near your phone and you are authenticated.

When it doesn't work, you might get stuck in a loop trying to work out why things are going wrong. It's terrifyingly easy to accidentally break something.

FIDO2 is still a pain. Do you know the difference between CTAP1 and U2F, or how they relate to WebAuthn? Does your favourite service support 2FA at all? Are you happy running a Python script on the CLI if you want to log in?

But that's not the ring's fault. It is early days for the tech and there are teething troubles.

The built-in contact-card portion of the ring is a bit daft. Pointing users to a 3rd party site doesn't seem like the right call for the type of people who'll buy this. I'm glad it could be pointed to a site that I control - albeit by using a different app to write the data.

I got used to wearing the ring after a few days, and it was the exact size that I requested. Although it is chunky, it is a subtle piece of jewellery and unlikely to draw unwanted attention. There are no LEDs or batteries to worry about.

Despite the teething issues and the price, I'm rather keen on this. Waving my hand next to my phone to exchange cryptographic information makes me feel part-way to being a cyborg-wizard. Is this the future of wearable technology? I don't know - but it is rather fun. I'm happy to be an early-adopter and to bash out the bugs in the tech.

If you want, VivoKey will also sell you an NFC Implant which you can inject under your skin and use as an MFA token. Personally, I think I'll stick with the ring!

You can buy the ring directly from Cybernetic.

A few days ago I had a bit of a rant on Mastodon about how PayPal was encouraging browsers to remember 2FA codes.

I'd tried to log in to PayPal, went to enter my 2FA code and was presented with this:

But, this isn't PayPal's fault! Let's take a look at the code behind each input:

<input name="otpCode-0" 
       id="ci-otpCode-0" 
       aria-invalid="false" 
       placeholder=" " 
       aria-label="1-6" 
       role="textbox" 
       aria-describedby="otpCode" pattern="[0-9]*" 
       for="securityCodeInput" 
       autocomplete="one-time-code" 
       type="number" 
       value="">

It's correctly using autocomplete="one-time-code" which means that browsers shouldn't remember any entered codes. Indeed, Firefox has support this for nearly a year.

So why was I seeing the remnants of old codes?

I was set straight by Asif Youssuff who knows a heck of a lot about Firefox. He pointed out that the values might have been saved from prior to the fix. And, he was right!

Firefox doesn't remember new codes - but it will regurgitate old codes it had previously remembered.

I'm not sure if that's desirable or sensible. But it isn't the bug I thought it was!

I went through and manually deleted the old codes - they haven't since re-appeared.

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.

I'll admit, this weirded me out. Surely 4 is just far too short. Right? I think almost every 2FA code I've seen has been 6 digits long. Even back in the days of carrying one of those physical RSA fobs, 6 has been the magic number.

But why?

A 2FA code is meant to prevent a specific class of problem. If an attacker has got hold of something you are (your username⁰) and something you know (your password), you are still protected by something you have (your phone). Whether your second-factor is an app generating unique codes, a SIM card receiving SMS¹, or a cryptographic enclave producing signed transactions - it doesn't matter. The attacker can use your password but won't get the unique second code.

Suppose you received a 2FA code that was a single digit. Is that secure enough?

I think most reasonable people would say that wasn't secure. An attacker has a 10% chance of guessing the 2FA. If the system allows for a couple of retries before locking them out, they've got a 30% chance of getting in.

Similarly a 2 or 3 digit code probably doesn't provide sufficient protection.

A typical bank card PIN is 4 digits. So an attacker has a 1 in 10,000 chance of guessing. That might be slightly better as bank PINs usually don't allow repeated digits, palindromes, and a few other combinations.

I suppose that if an attacker had compromised tens of thousands of credentials, and the service allowed for a few incorrect entries, it is statistically likely that they might be able to compromise a few accounts if they were only protected by 4 digits.

As 2FA codes get longer, they begin to reach the limits of what humans can remember. Yes, I know you have an excellent memory - but not everyone does. And I know your fancy 2FA app automatically copies and pastes the codes - but not everyone does. We have to work to what the average user is capable of at a minimum.

I think most people would find it annoying - if not impossible - to remember a 10 digit one-time password.

If you're copying a code from your phone to type into your laptop, there's probably an upper limit on what people will be prepared to do. No one is going to manually transcribe 128 digits. And, if they did, they'd likely introduce several errors.

So the industry has seemingly settled on 6 digits. I've ranted before about the lack of standardisation in the OTP specification. But all of them seem to allow 6 - 8 digits.

I suspect 6 is the standard because that's what the original RSA SecurID tokens used by default.

An attacker would have to be incredibly lucky to randomly guess a 6 digit code - literally a one-in-a-million chance². Even if they had multiple retries, it's still statistically unlikely.

Once I logged in using my 4 digit code, I had full access to my account. But if I wanted to make any changes, I had to wait for another 2FA code to be sent. So I guess the effective length of code was actually 8 digits. Which seems excessive 🤣

Thoughts from the community

I asked my Twitter buddies for their wisdom:

Alex Hudson

@ealexhudson

@edent Depends on retry/lockout policy? 4 digits is enough for a bank card, but there is a physical token involved there - is the account as valuable as that, though?

Gut feeling is 6 digits is right for most circumstances though...

---

Rob Styles

@mmmmmrob

Replying to @mmmmmrob@edent 10,000 combinations is plenty to prevent guessing, and making the code longer doesn't add any additional protection if the message/device is compromised.

Making the code longer makes the usability exponentially worse when the code has to be re-keyed.

---

Ryan Cullen

@artesea

@edent Assuming just three retries before the code expires, 3 in 10,000 doesn't sound too bad. Also easy to remember whilst switching between the messaging app/notification shade and the app/website wanting it. I find with 6 I need to go back and forth. Worse with alphanumeric.

---

James Seconde

@SecondeJ

Replying to @mmmmmrob@mmmmmrob @edent For these sorts of reasons, this is why @VonageDev 2FA (Verify) lets you choose between 4 and 6 digits

---

Rhidian Bramley

@RhidianB

@edent Zero digits. More user friendly and secure to send a hyperlink with a single use time limited encryption key. No heed to compromise usability vs security. Win win.

---

Chris Hill-Scott

@quis

@edent Design System says 5 digits: design-system.service.gov.uk/patterns/confi…

On Notify 2% of attempts are miskeyed – people with dyslexia probably disproportionately affected.

4 would be better – used by Airbnb and Uber – but you need stronger technical measures in place to prevent automated attacks.

---

What do you think?

Last night, lightning struck our house and burned it down. I escaped wearing only my nightclothes.

In an instant, everything was vaporised. Laptop? Cinders. Phone? Ashes. Home server? A smouldering wreck. Yubikey? A charred chunk of gristle.

This presents something of a problem.

In order to recover my digital life, I need to be able to log in to things. This means I need to know my usernames (easy) and my passwords (hard). All my passwords are stored in a Password Manager. I can remember the password to that. But logging in to the manager also requires a 2FA code. Which is generated by my phone.

The phone which now looks like this:

Oh.

Backups

I'm relatively smart and sensible. I regularly exported my TOTP secrets and saved them in an encrypted file on my cloud storage - ready to be loaded onto a new phone.

But to get into my cloud, I need my password and 2FA. And even if I could convince the cloud provider to bypass that and let me in, the backup is secured with a password which is stored in - you guessed it - my Password Manager.

I am in cyclic dependency hell. To get my passwords, I need my 2FA. To get my 2FA, I need my passwords.

Perhaps I can use my MFA FIDO2 Key?

Oh.

Emergency Contacts

Various services allow a user to designate an "emergency contact". Someone who can access your account in extremis. Who do you trust enough with the keys to your digital life?

I chose my wife.

The wife who lives with me in the same house. And, obviously, has just lost all her worldly possessions in a freak lightning strike.

Oh.

Recovery Codes

Most online services which have Multi-Factor Authentication, also provide "recovery codes". They are, in effect, one-time override passwords. A group of random characters which will bypass any security. Each can only be used once, and then is immediately revoked.

I was clever. I hand-wrote the codes on a piece of paper (so they can't be recovered from my printer's memory!) and stored them in a fire-proof safe, secured with a key hidden under the cat's litter-box.

Sadly, the fire-proof safe wasn't lightning-strike safe and is now obliterated. Along with the cat's litter-box. The cat is fine.

I know… I know… I should have kept them in a lock-box in my local bank. The only problem is, virtually no banks offer safe deposit boxes in the UK. The one that does charges £240 per year. A small price to pay, for some, to avoid irreversible loss. But it adds up to a significant ongoing cost.

But, suppose I had stored everything off-site. All I'd need to do is walk up to the bank and show some ID which proved that I was the authorised user of that box.

The ID which has just been sacrificed in tribute to mighty Thor and now looks like a melted waxwork.

Oh.

Friendly Neighbourhood Storage

Perhaps what I should have done is stored all my backup codes and recovery keys on a USB stick and then given them to a friend?

There are a few problems with that.

1. Every time I sign up to a new service, I would need to add it to the USB stick. How many times can I pop round with a fresh stick before it becomes an imposition?
2. What if my friend (or their kid) accidentally wipes the drive?
3. If a freak lightning storms hits both our houses at the same time, I still lose everything.
4. Even if I did all that, I would have to give the USB stick a strong password to make sure my friend didn't betray me. So I either need to remember that, or I'm stuck in the password-manager-paradox.

Perhaps I could split the USB sticks between multiple friends using Shamir's Secret Sharing? That solves some problems - mostly the accidental losses and remembering a strong password - but creates even more issues. Now I have to do a lot more admin and worry about all my friends conspiring against me!

Phone Home

One of the weakest forms of identity is the humble phone number. Several of my accounts use my mobile number to text me authorisation codes. SMS isn't the most secure way to deliver passwords - it can be intercepted or the SIM can be swapped to one controlled by an attacker. But, if I can get my phone number back, I stand a chance of getting in to my email and perhaps some other services.

That's a weakness in my security posture. But one I may need to take advantage of.

The only question is - how do I prove to the staff at my local phone shop that I am the rightful owner of a SIM card which is now little more than soot? Perhaps I can just rock up and say "Don't you know who I am?!?!"

I know, I'll show them my passport!

Oh.

Bootstrapping of trust

I am lucky. I have a nice middle-class life and know lots of professionals - doctors, lawyers, teachers - who I hope would be happy to vouch for me. I could use one of my friends to confirm my identity for a replacement passport. Once I have a passport, I should be able to get a SIM card with my phone number. And, I hope, some online services.

I would, however, need to use a credit or debit card to apply for a replacement passport. But all of my cards are melted to slag - and I can't prove to the bank that I am who I say I am because I don't know my account number, password, or mother's maiden name.

You see, I was "clever" and took some idiot's advice about setting your mother's maiden name to being a random string of characters. Those details are, of course, stored in my inaccessible password manager!

Hopefully one of my friends will be prepared to lend me the £75.50 to get a new passport.

I'll just call up one of my friends. Hmmm… now, where did I store their phone number?

Oh.

Starting over

Again, I'm lucky. I live relatively close to some friends and family. And I'm confident that they'd be gracious enough to pay an emergency cab fare if I started hammering on their door at silly o'clock in the morning.

With their help, I think I could probably call up enough insurance companies to figure out which one covered the property. I would hope the insurance company would have some way of validating with the emergency services that the house is, indeed, a smoking crater. I don't know if that would get me emergency cash, or if I'd have to rely on friends until I get access to my bank account.

I assume my credit card companies can probably be convinced to send out replacement cards. But will they also be willing to change my address - or will the card go to the pile of ashes which was formerly my home?

I don't know whether my insurance policy covers me for access to digital files. Even if it did, I'm not sure how they can force a company like - say - Google to give me access to my account. It isn't like Google went through a KYC (Know Your Customer) process when I signed up.

Code Is Law

This is where we reach the limits of the "Code Is Law" movement.

In the boring analogue world - I am pretty sure that I'd be able to convince a human that I am who I say I am. And, thus, get access to my accounts. I may have to go to court to force a company to give me access back, but it is possible.

But when things are secured by an unassailable algorithm - I am out of luck. No amount of pleading will let me without the correct credentials. The company which provides my password manager simply doesn't have access to my passwords. There is no-one to convince. Code is law.

Of course, if I can wangle my way past security, an evil-doer could also do so.

So which is the bigger risk:

• An impersonator who convinces a service provider that they are me?
• A malicious insider who works for a service provider?
• Me permanently losing access to all of my identifiers?

I don't know the answer to that. If you have a strong opinion, please let me know in the comment section.

In the meantime, please rest assured that my home is still standing. But, if you can, please donate generously to the DEC's Ukraine Humanitarian Appeal

I want to play around with 2FA codes. So, I started looking for the specification. Turns out, there isn't one. Not really.

IANA has a provisional registration - but no spec.

It links to an archived Google Wiki which, as we'll come on to, isn't sufficient.

There's some documentation from Yubico which is mostly a copy of the Google wiki with some incompatible tweaks.

The Internet Initiative Japan has a subtly different spec which includes an icon parameter not seen in any other.

Hidden halfway down the IETF tracker for Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication is yet another specification which is incompatible with the others!

Oh, and IBM has yet another one!

Of course, Apple have their own special Apple-specific version. It is identical to Google's, but uses the apple-otpauth: scheme. Because.

Here's a quick table comparing them:

I tried creating a variety of codes on the fringes of the specification - more than 8 digits, lower than 15 second periods, weird issuers - to see what would happen if my trusting friends scanned them with their TOTP apps.

Sam Nalty

@samnalty

Replying to @kerguio@kerguio @edent Weird, worked for me on 1password for android

---

Sam Nalty

@samnalty

Replying to @samnalty@kerguio @edent Even weirder, in the Android app it is a 10 digit OTP but on the windows app it's a normal 6 digit one.

---

Ben Nuttall

@ben_nuttall

Replying to @edent@edent Seems to work as my others do (in Google Authenticator), apart from the name is emojis and some RTL text

---

Serge

@kerguio

Replying to @edent@edent Keychain in iOS seemed to ingest it, but not sure where it went...

---

John

@Johninnit

Replying to @edent@edent Authy says "Token format invalid"

---

Why is this a problem?

Formally standardised specifications are a good thing. They mean that everyone is on a level playing-field and innovation can happen without actors enclosing the commons.

More prosaically, it means that users can be confident that any app will work with any code from any provider. And implementers can have a forum where they can propose enhancements to the spec which won't break users' devices.

Where are the specifications deficient?

The URI encoding trips up a number of publishers - more on that in a later blog post.

Should there be a maximum or minimum length to the secret? Why? Why not?

Is it a wise idea to fix those algorithms? Does it matter if a weaker one is in there? Can they be deprecated?

Why just 6 or 8 digits? What's wrong with an arbitrary number of digits? What about using letters or other symbols?

The period is in seconds. Does that mean whole seconds? Can users reliably type in 8 digit codes which change every 15 seconds?

"Issuer" is in there twice. What if they don't match each other?

Do users want an "icon"? Should it be a Base64 encoded graphic? If so, what format? If not, is a URL sufficient?

I'm sure there are half-a-dozen more gripes you could come up with.

The future kinda sucks

I am so tired of Google getting bored halfway through designing something - and then expecting the rest of us to just figure out what they meant.

We're now in a situation where everyone is (rightly) pushing TOTP for 2FA, but there's no formal specification for how users can scan those codes into their apps. There's no way to propose changes. And there's no guarantee that a user will be able to reliably scan the codes they are given.

Bad times.

It launched an entertaining discussion about the risks of taking a potentially fake FIDO token.

We all know the risks of taking a free USB drive and shoving it in our computer, right?

USB sticks can install software, act as a keylogger, transmit data over WiFi, and even physically damage the electronics!

So a USB Yubikey could do all those things - but could it do anything malicious as an MFA token?

And - at the risk of invoking Cunningham's law - I think the answer is a cautious "no".

Other than the risks inherent in any USB device, what's the worst that could happen? A cloned device might let an attacker have a duplicate key. But that's useless unless they also have your username and password.

A device with a built in transmitter might send an OTP to an attacker but, again, useless without the other authentication factors.

The devices could be set up to deliberately fail - or be revoked. That could work as a denial of service attack against users. But most services allow you to have a backup authentication method.

There may be some sites which only use a token for login - eschewing passwords - but that's rare, I would hope.

A Yubikey can be hacked to send arbitrary keystrokes - but that's of limited usefulness. I guess an attacker could force open a browser window to download malicious software, but that would be fairly obvious to a user.

So, go on then, prove me wrong. What's the worst thing that can be done with a compromised Yubikey?

The HTML autocomplete attribute is available on <input> elements that take a text or numeric value as input, <textarea> elements, <select> elements, and <form> elements. autocomplete lets web developers specify what if any permission the user agent has to provide automated assistance in filling out form field values, as well as guidance to the browser as to the type of information expected in the field. https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete

In plain English - your browser remembers your email address and presents it in a drop-down box when you try to log in to a service.

That's pretty cool, right? It's useful for accessibility. And there are a bunch of "hints" to help the browser know what data to fill in - so it doesn't accidentally put your postal address where your email address should go.

One of these hints is one-time-code. The theory is, your browser can auto-fill the <input> with a two-factor-authentication code. A phone's browser might automatically grab the 2FA when it receives an SMS. Or a desktop browser might see the code in the user's clipboard. Clever, huh?

But...

The thing about one-time codes is that they're designed to be used once. A code is typically valid for around 60 seconds. After that, it's useless. The service will refuse you entry and ask for another code. So there is no point having the browser remember the code to let you re-use it later.

And yet...

Firefox and Chrome both remember 2FA codes and "helpfully" show them in a dropdown. Why?

There is no world where a user would want to re-enter the same 2FA code. If they mistyped the code the first time, showing it again isn't helpful. There is close to zero chance of a previous 2FA code being the same as my current 2FA code. Remembering 2FA codes is a bug, not a feature.

I'm not the first to notice this:

Kai Hendry

@kaihendry

Is whatwg.org/html some sort of lost skill? @github pic.x.com/9WJD1FbOzx

---

Dave Marshall

@davedevelopment

This irritates me far more than it should. If you're coding up a 2FA form, autocomplete=off please 👍 pic.x.com/jXBRithoH5

---

UX Opportunities 🟠 User Experience Advice

@UXOpportunities

Auto-complete on OTP fields shouldn't show past codes, @ChromiumDev, surely?
Do other #browsers do this?

#ux #userexperience #uxfail #wtfux

This #UXOpportunity courtesy of @github's #2FA page, which correctly uses `autocomplete="one-time-code"` pic.x.com/fyci5H63ze

---

Lynn (finally free)

@chordbug

As a…
→ user with 2FA enabled

I want…
→ the 6-digit password field to have autocomplete

So that I can…
→ save time whenever I win the 2FA lottery

---

In fact, I've been ranting about this since 2014.

Please - browser manufacturers and spec writers - do some user research to see if the feature you're developing is useful to real-life users.

Tess Rinearson

@_tessr

Is this a phishing attempt? Goes to "githubverification.com" and asks for username and pw

(if so, it nearly got me!)

/cc @github pic.x.com/jgt4oNvjF2

---

In the replies, you’ll see lots of techbros saying “this is why you should switch on 2FA people!!!”

Except, and I hate to bring accuracy to a technical discussion, that’s not how 2FA works!

A second factor allows a site to better authenticate you. It does not help you identify the site.

If you log on to fake-bank.com, the scammers will immediately take your username and password and send it to real-bank.com – the fake bank will then ask you for your 2FA token. That could come via SMS, email, an authenticator app, or even post. Then the fake site uses your real token and logs in as you.

Game Over.

There is almost nothing you can do to authenticate that a site is legitimate.

• Any information that you can request from the real site can be proxied to the fake site.
• The green SSL padlock means nothing for validity. Anyone can get one.
• The top result on Google is invariably an advert for a scam site.

Realistically the only thing you can do is look for “out of band” verification. What’s the URL stamped on your credit card? What’s written on the welcome letter sent by snail mail?

None of these are infallible – and they can all be manipulated by a suitably determined attacker.

The best defence is to use a password manager. I recommend the open source Bit Warden.

A password manager stores your passwords. But it also stores the web address of site’s login page. If you visit githud, the password manager won’t prompt you to use the login details for github.

Defence in depth. Use 2FA to prevent attackers masquerading as you. And use a password manager to prevent fake sites masquerading as real sites.

What About YubiKeys?

No. I'm not a big fan of YubiKeys. In theory, a hardware token can help with this. You register the token with the device and it spits out a code only to the correct site.

But it has significant downsides.

• Cost. The average YubiKey is £50. There are a few around the £30 price point. That’s a huge expense given the small number of sites that support them.
• Usability. Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time. Take 10 minutes to watch a normal user try to set one up - then tell me if you think this is a good solution.
• Convenience. My YubiKey is on my keyring. My keys are in my coat. My laptop is not near my coat. Given how often I need to log into things, it means adopting a significant change of habit. Or leaving my YubiKey plugged in all the time. Which leads to…
• Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.
• Support. WebAuthn is a great standard – but only a few sites support it. While it is good at protecting a handful of sites, I encounter it so infrequently that I regularly forget how it works.

While a WebAuthn request can't be proxied - there's nothing stopping a fake site from asking for your token, then rejecting it and asking for a separate factor.

If fake-github.com said "Hmmm we're having problems with our WebAuthn backend - please use a one-time code from your authenticator app for added security" would you be fooled?

WebAuthn and hardware tokens are probably the future. And they’re probably the best way we have to verify site legitimacy. But they’re also currently a poorly supported usability disaster.

Stay safe out there.

I tried going through them, removing long-dead websites, closing old accounts, and deleting anything incriminating. I now have 891 accounts.

Arse.

I also went through my 31 different 2FA accounts. Getting rid of old employers' email tokens, failed crypto wallet providers, Club Penguin etc. I now have 40 different TOTP tokens.

So, about 4% of my accounts have 2FA security.

I don't know if that's good or not. It feels like it ought to be more, but I'm not sure if I want the administrative burden. Even with a password manager and OTP manager, it's a headache.

I do have a Yubikey (which I hate) but so few services support it. And, frankly, it's pain trying to find it and shove it in a USB socket.

A few services, like Steam, use their own special 2FA app. And some only offer 2FA via email or SMS. Yeuch! Google has a fancy set of push notifications on Android - but that only works with Google accounts.

Is this a problem?

Any of my accounts which handle payments are tied to my credit cards or PayPal - so I don't care too much if someone cracks my password to Pizza Planet; there's limited damage they can do.

But there has to be a better solution. Things like WebAuthN look interesting - but I worry that they're too complicated for mere mortals to understand. And I'm worried about how fragile it is to have all your credentials tied up on one physical token. And I'm worried that credentials are tied to your browser.

So what's the solution?

A standard TOTP code is normally 6 digits long. There are a million combinations, from 000000 to 999999.

A million isn't a particularly big number. A million seconds is about 12 days. A TOTP code changes every 30 seconds. Assuming the codes are evenly distributed (a big assumption!) we should see every combination in half-a-million minutes. Rather pleasingly, that's about a year.

If, like me, you have far too many 2FA tokens, and you use them most days, then it shouldn't be surprising if you occasionally see "weird" codes.

Million-to-one chances crop up nine times out of ten

This comes down to how humans perceive randomness. Famously, Apple had to make its shuffle algorithm less random - people were complaining that it would sometimes consecutively play songs by the same artist. Sure, it is random, but it doesn't feel random.

What a human thinks of as perfect randomness is not the same as actual randomness.

In the novel Cryptonomicon - the perils of human-biases are made clear. A captured spy explains how their cover was blown:

"The one-time pads for Detachment 2702 are being created by Mrs. Tenney, a vicars wife. She uses a bingo machine, a cage filled with wooden balls with a letter stamped on each ball. She is supposed to close her eyes before reaching into the cage. But suppose she has become sloppy and no longer closes her eyes when she reaches into it."

Does this have consequences?

Assuming a user takes any notice of their 2FA codes, do they feel more secure if they regularly receive codes which look significant?

How freaked out would you be if your 2FA Code displayed your date of birth? Your phone number? Your employee ID? Your credit card PIN?

But if we try removing all possible "special" numbers, we end up fatally weakening security.

So, the next time you get a 2FA code which feels a bit weird, don't panic. Everything is fine. Trust the algorithm.

I now want to talk about 2FA - Two-Factor Authentication - the random codes you have to type in every time you log in somewhere secure.

This week, I've moved all my 2FA tokens from Authy, to the open source andOTP app. It was mostly painless exporting the Authy keys - but took a while to manually check each one. Do I really need this many 2FA tokens?

It's good that my webhost uses 2FA - but annoying that they have two separate ones for my account and my control panel.

I've got a bunch of Gmail accounts - it is frustrating scrolling through remembering which G-icon goes with which G-service.

There's a few different Microsoft ones because I'm not sure of the collateral damage if I try to link my Xbox, Skype, and Outlook accounts.

And the usual smattering of hardly-used services which offered 2FA, so I set it up.

Oh, and a few services which don't use standard TOTP - and insist on using their own app or hardware token.

Is This Secure?

I don't know any more.

In security, we usually talk about the benefits of having your security split between something you know (a password) and something you have (a token). But I've effectively combined them. My phone stores passwords and tokens. If someone steals it and can break through my biometrics & PINs - they've got the keys to my kingdom.

If a crappy service has leaked a passwords, which I've reused elsewhere, then this 2FA set-up provides extra security. But fewer than 5% of my online accounts support 2FA - so that's a minor benefit.

The Alternative?

I tried using a YubiKey - and I just couldn't get on with it. The software was too flaky, hardly any services support it, and my keyring is rarely to hand.

So I'd have to keep an easy-to-lose physical token - as well as a phone for every service which doesn't support it.

Text For Details

As well as the codes in my app, I have a bunch of services which will only use insecure SMS for 2FA:

• LinkedIn
• PayPal
• American Express

Quite why these services are stuck in the dark-ages is beyond me. Possibly they just want my phone number for marketing purposes?

What's Next?

The username / password / token pattern is becoming increasingly unsustainable for me. Having a multitude of security apps is marginally more convenient than carrying around a big bunch of keys. But it is frustrating find the right app, searching through for the right icon, typing things in before the timer expires, and proving my identity multiple times daily.

I could turn off 2FA and re-use the same username/password everywhere. That would be a hell of a lot easier for me. But I don't want to reduce my security that much!

I could sign in to everything using Facebook. But even if that weren't ethically dubious, not every service supports that.

Both Google and Authy have a useful service whereby they send a push notification to your phone and ask you to confirm your login. Cool, and easy to use. But, again, limited support and the same risk of my phone being the single point of failure.

What's the alternative? If you know - please leave me a message in the comments.

The Process

There's no direct link to 2FA settings. So the process is slightly convoluted. Assuming you are signed in to your Amazon account, you need to

• Go to https://www.amazon.co.uk/your-account
• Click on "Login & Security Settings"
• Then "Advanced Security Settings"

You can now start to add 2FA to your account.

There are two ways you can get your 2FA code. The most secure way is by using an authenticator app like Authy or FreeOTP.

If you can't install apps - or just don't like them - you can get your code delivered to you via SMS.

Let's ignore the American number formatting (555!) - is an SMS code sensible?

• SMS works everywhere, even on the dumbest phone.
• No app needed.
• Swap your SIM to a new phone and have instant access.

That last one is the biggest weakness. It is terrifyingly easy for a scammer to ring up your phone company and get your number swapped to a new SIM. If a scammer wants the codes off your app they have to physically steal your phone and then unlock it (you do have a secure password, right?). With SMS, all they have to do is convince some hapless call centre worker that you need your number transferred.

There's also the little matter that SMS isn't encrypted - but if the security services desperately want access to your Amazon account, I'm sure they have their own means.

2FA Problems

Far from being a scrappy start-up, Amazon is now a maze of interconnected legacy systems. There are several ancient services with Amazon can't or won't update. This means they don't get 2FA support.

This is a problem which I recently encountered with PayPal. Old apps don't support new security - weakening the usefulness of security for everyone.

Of course, there's no mention of which apps don't support 2FA. Their proposed solution of sticking your 2FA code to the end of your password is... interesting. It implies that if the system doesn't recognise your password decrypted password, it will split it in two and try it again. I wonder if that leaves them open to subtle timing attacks, or any other issues?

The point of 2FA is that you use it everywhere - otherwise you're introducing a weak point in your security. Amazon will happily let you turn off 2FA on specific devices.

I can kinda see their reasoning. It is annoying to be forced into using the 2FA on your regular handset. But that's also the point. Making it slightly harder for us makes it extraordinarily hard for an attacker.

Despite these shortcomings, I urge you to switch on 2FA. Amazon holds a surprising amount of your personal data - and the consequences of your Amazon account being hacked can be dire.

There are hundreds of sites which support 2FA. You should make sure you use it wherever possible.