I think its time to update the feature set for TOTP  associated with SmarterMail. Presently the Base32 Secret used by SmarterMail is too small as defined by RFC6238 and may 2FA Apps like FreeOTP from Red Hat complain about the short secret length.

Here is my strawman proposal...

Please keep in mind that the RFC6238 Secret Size is referenced as bit strength not as string length. Thus a 160 bits (20 bytes) for SHA1, 256 bits (32 bytes) for SHA256 and 512 bits (64 bytes) for SHA512. Thus when you Base32 Encode the binary Secret of value you get 32, 52, 103 Byte String respectively.

So where does Base32 use come from? Base32 is used by Google's Android Authenticator Application and was likely adopted because the Google choose a URI string to express the authentication values in the QR Code. At this point Google's Android Authenticator Application has become the de facto reference application and is outside the RFC.

In Domain Defaults we should have a Card for TOTP RFC 6238 and in that card I suggest we have the following settings:

-- Issuer (in this was I can customize this field; example "Your MSP")
-- Option for Account not to include the domain name, however, the username plus at sign is in the string
-- HMAC Crypto: select SHA1, SHA256 (recommend default) and SHA512

-- Time Step: 30 seconds (default)

-- Code Size: 8  Digits (with a max value of 10)

-- Secret Size: any number from 20 to 64 Bytes (not Base32 Encoded String Length), however, the Crypto default initially sets this size to 20, 32 and 64 bytes size respectively. In the SmarterMail UI warnings should be shown next to the "Secret Size" when it does not comply with RFC 6238 standards. "Secret Size" compliance is when the value is equal or greater compared to the recommend byte size for the selected HMAC Crypto.

Again, we have normal Domain Level TOTP Card settings and Domain level Override-ability set by the Administrators. We should strive to step up the SmarterMail new defaults with better the TOTP Crypto and Secret Size!

To meet these ideas, SmarterTools' code will need to store into the user settings for TOTP the values of Crypto, Time Step, Code Size, and Secrete Size such that if the Domain Admin or the SmarterMail Administrator changes these settings an existing user's TOTP settings continue to function. For myself in my PHP / PowerShell code I'm writing I use JSON to store all the values:

{

    "otp": {

        "scheme": "otpauth",

        "type": "totp",

        "label": "<LABEL>",

        "account": <OPTION>",

        "secret": "<BASE32>",

        "issuer": "<ISSUER>",

        "algorithm": "<ALGO>",

        "digits": "<DIGITS>",

        "period": "<PERIOD>"

    }

}

Finally, just like the password report TOTP Report to Identify any users that don't match the Domain Level Settings and specially call out Secret Sizes that don't meet the RFC 6238 standard. In this way we have a method to upgrade users security over time. Just like for "Password Requirements" we should have "Skip enforcement of existing TOTP settings" which would lockout users who are not compliant and MUST use the 2FA recovery feature.

What about the idea of QR Code Regeneration for Admins or Users? I have a lot of cases where a user losses their phone and can't regenerate their QR Code. The only way to resolve this is to user the recovery 2FA feature but many users are unsure of this process then have to disable 2FA and re-enable. That's a lot for a typical user. I have an out-of-bound secure method for doing this but I able to see a users QR Code on demand would be helpful for everyone.