In a continuation of the other $hotp bug report. $hotp decodes key strings in a way that doesn't appear to be documented. The /help page for $hotp describes 4 methods of presenting the key:

Hex strings of length 40/64/128
Base32 strings of length 16/24/32
Google Authenticator Format
plain text

It specifically says that it decodes Base32 strings of the 3 lengths 16/24/32, however I've found that as long as the key is a string that's *any* multiple of 8 characters greater than length 8, and contains only the 32 case-insensitive characters of the Base32 alphabet excluding the '=' padding character, $hotp is using the Base32 decoded string instead of the case-sensitive literal string. The exception is strings of length 40/64/128 containing only hexadecimal characters.

This means that someone using a key that contains the properties of a Base32 encoded string loses password strength because their password is being handled in a case-insensitive manner.

Code:
//var %i 2 | while (%i isnum 1-25) { var %a 5 * %i | var %b $regsubex($str(x,%a),/x/g,$r(!,~)) | echo -a $hotp(%b,123) $hotp($lower($encode(%b,a)),123) $hotp($upper($encode(%b,a)),123) - %a %b | inc %i }


Can you give an example of how Google Authentication format differs from the other 3 described methods of of presenting the key? Other than hex strings of lengths 40/64/128 or strings of length 16+ which could be mistaken for a Base32 encoded string which doesn't contain the Base32 padding character, all other key strings I've tested appear to handle the key as the literal text string.