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!

It's a cheap and light plastic box with a short USB cord. When you plug it in, there's a flashing light which can't be disabled. When it is powered up, or it detects and NFC chip, it makes this weird and scratchy beep:

On Linux, it shows up as: 072f:223b Advanced Card Systems, Ltd ACR1252 Dual Reader

To get it working, install PCSC Tools and the PCSC Daemon:

sudo apt install pcsc-tools pcscd

To start the daemon:

service pcscd start

Running pcsc_scan detected the reader as two readers - PICC and SAM

Using reader plug'n play mechanism
Scanning present readers...
0: ACS ACR1252 1S CL Reader [ACR1252 Dual Reader PICC] 00 00
1: ACS ACR1252 1S CL Reader [ACR1252 Dual Reader SAM] 01 00

Putting tokens on and off the reader showed them being detected and removed.

Despite my best efforts, I was unable to get this working with libnfc.

nfc-list uses libnfc 1.8.0
No NFC device found.

For reading and writing basic NDEF tags, I used Wakdev's NFC tools, I was also able to use various Python scripts like PCSC NDEF

It also worked with a FIDO2 / HID Bridge so I could use an MFA token.

There's lots of documentation about the reader and its API as well as some official ACS Linux tools. In theory it supports firmware update - although none have been released.

It's a cheap and cheerful device. It would be nice if there were a way to stop the flashing LED and crappy buzzer.

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.