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?

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

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

Please do contribute tests and / or feedback.

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

Background

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

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

Number of digits

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

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

The TOTP RFC says:

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

1.2. Background

But doesn't say how far to truncate.

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

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

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

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

Algorithm

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

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

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

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

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

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

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

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

But the HOTP spec goes on to say:

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

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

Period

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

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

The TOTP RFC says:

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

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

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

Secret

Google says the secret is

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

Whereas Apple says it is:

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

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

Label

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

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

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

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

Issuer

Google says this parameter is:

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

Apple merely says:

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

Yubico equivocates with

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

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

Next Steps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    //  All done!
    return otp;
}


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

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

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

You can grab the code from Codeberg.

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

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

One Punch Man

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

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

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

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

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

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

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

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

Do The Right Thing

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

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

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

We're Only Human

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

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

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

What's Next?

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

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

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

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

How do we fix it?

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.

The TOTP algorithm uses a Hash-based Message Authentication Code (HMAC). The hash is calculated from a shared key and a time-based component.

The key is a short string of characters. The time-based component is calculated as the number of seconds between now and the Unix Epoch. When is the Unix Epoch? 00:00:00 UTC on Thursday, 1 January 1970⁰. It has been roughly 1.7 billion seconds since then. 64 bit computer systems can count up for another 290 billion years¹. So chrononauts journeying to the future should be fine.

But what about people travelling backwards? You and your friends want to go and see The Beatles perform in 1966. That's before 1970. So the time-based component will be a negative number.

I've tried a bunch of different TOTP generators and fed them a variety of negative numbers. They all crashed.

So, no. TOTP doesn't work for anyone travelling backwards in the 4th dimension. Pity.

Is there a serious point to this? Well, sort of.

Negative time is an unexpected input and leads to unusual behaviours. Could a crash in HMAC generation lead to an exploit?

Standards get used in all sorts of places - including retrospectively. Should standards writers specifically account for inputs which occur in the past?

How should computers deal with "preposterous" times?

What other common security tools fail if they're subjected to time-travel?

Which Beatles concert would you go to in 1966?

But is that just my stupid meaty brain noticing patterns where none exist?

The TOTP algorithm uses HMAC, which in turn uses SHA-1. My aforementioned brain is not clever enough to understand how that works. Although bigger, meatier brains have assured me it is fine.

What happens if I sample, say, the next 10 TOTP codes and plot how often digits appear?

HOLY SHIT! CONSPIRACY CONFIRMED! WTAF?!?!?

Don't believe me? Here's the code:

import pyotp
import numpy as np
import matplotlib.pyplot as plt

totp = pyotp.TOTP('')

#   How many times to run this?
runs = 10

#   Initialize a NumPy array with shape to store the digits
digits_array = np.zeros( ( runs, 6), dtype=int)

#   Generate the digits
for i in range( runs ):
    number_str = totp.at( i * 30 )
    for j in range(6):
        digits_array[i, j] = int(number_str[j])

#   Analyse the entire array
all_digits = digits_array.flatten()

# Plot histogram for all digits
plt.figure()
plt.hist(all_digits, bins=np.arange(11) - 0.5, edgecolor='black', density=True)
plt.xticks(range(10))
plt.title('Digit Distribution for All Digits (' + f"{runs:,}" + ' runs)')
plt.xlabel('Digit')
plt.ylabel('Frequency')
plt.show()

OK, so maybe that's a coincidence. What happens if we check 100 generations?

Quite a lot of noise in there - but lucky number 8 isn't quite as prominent.

After 10,000 generations, the variation is all but gone.

There are about 30 million seconds in a year. TOTP codes change every 30 seconds. Which means, in a year, you'll see about a million of them:

Is it possible that a TOTP code could be formed which shows a clear bias to a specific number? Probably not.

I love being able to check the source code - but sometimes it's just as reassuring to measure the output.

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!

As I've mentioned before, the TOTP specification is a stagnant wasteland. But it does have this to say about the secret:

The secret parameter is an arbitrary key value encoded in Base32 according to RFC 3548.

The Base32 alphabet is pretty simple. The upper-case letters A - Z, and the numbers 3 - 7.

But that's only half the problem.

How long should the secret be?

This is an area where the official spec is silent. Around the web, you'll find people saying things like:

The length in bytes of generated shared secrets. The minimum is 20 (or 160 bits), and the default is 32 (or 256 bits). In most use cases 32 is sufficient. Though some authenticators may have issues with more than the minimum. Our minimum is the recommended value in RFC4226, though technically according to the specification 16 bytes (or 128 bits) is the minimum. Authelia

Although that's for the HOTP algorithm, rather than TOTP.

Looking through my 49(!) different TOTP codes, the shared secret ranges from 16 characters to 52 characters. No consistency whatsoever.

The Code

Run this on your command line.

cat /dev/urandom | LC_ALL=C tr -dc 'A-Z3-7' | fold -w 24 | head -n 1

That generates a random-enough⁰ string using the correct alphabet and truncated to a sensible length.

Let's go through each part of it.

cat /dev/urandom spits out random data from your machine. You may wish to use /dev/random if you feel like it.

LC_ALL=C sets the Locale to by ANSI bytes.

tr is "Translate, squeeze, and/or delete characters.".

-dc 'A-Z3-7' is delete the complement (i.e. delete anything which isn't in the following string).

fold -w 24 is wrap the input text with a line length of 24.

head -n 1 displays the first line of the file.

Next Steps

Now... How do I locally generate a QR code without anything else being installed...?

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.