Secret as plain text are chaned to base32 after saving

[ShlomiPorush]

Describe the bug New install To test this app i added a key (2fa Secret) that i saved when setting up 2fa to my plex account. (the key is 32 characters)

To Reproduce I added the key and save.. simple. BUT after checking the 2fa code is not the same as the one i have in Authy. (Screenshot 1) trying to login to plex dose NOT work.. with an error that the code is not correct.

Changeing the Secret to plain text manually (Screenshot 2) and clicking the test button it works!. the code is the same. (Screenshot 3) After saveing the account and edit again you can see the Secret as been changed to base32 and some ==== are been added to the secret (Screenshot 4)

Expected behavior the 2fa code should be the same. For some reason it changes to base32 instead of plain text.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome
• Version 104.0.5112.102

[ShlomiPorush]

So i did the same test with some test account (Not going to reveal the account info, so the code below will not really be a security risk. in any case the account is already destroyed... I just set it up to produce a code 2FA) use this key svswywdtwgx2vbty add it to any other 2fa app like Authy and check the code against the code in 2FAuth.

[Bubka]

Hi,

2FAuth uses the Spomky-Labs/otphp package that relies on the otpauth URI schema. This means that the secret should be provided as a base32 encoded string.

In the advanced form, if the secret is defined with the plain text format, 2FAuth will automatically encode it to a base32 upper-cased string. Furthermore, if a random string is provided with the Base32 format selected, 2FAuth will reject it if the string format does not match the base32 upper-cased format.

I've tried Authy and 2FAS, both accept any string for the secret, but none tells you the awaited format. After some testing I can tell you they expect for Base32.

Here is a testing process to illustrate the point:

1. In Authy, create a new account with the secret toto (which is NOT a base32 encoded string)
2. Save the 2FA
3. Get a fresh code, let's say 832 432

On the 2FAuth side:

1. Open the advanced form and select TOTP with a plain text secret set to toto
2. Click the preview button
3. The code is not 832 432 because 2FAuth has dynamically encoded toto to its Base32 equivalent string that is ORXXI3Y=
4. Close the preview and set the secret format to Base32 and keep toto as the secret value
5. Click the preview button >> the Secret field reject toto because it's not a Base32 upper-cased string
6. Keep the secret format to Base32 and set the secret value to TOTO==== (which is a Base32 upper-cased string)
7. Click the preview button >> You should get 832 432 because this time TOTO==== is a valid Base32 upper-cased string.

So what's happened? When you set the secret, Authy reformat the provided string to make it a valid Base32 string whereas 2FAuth encode plain text secret to Base32 format.

In fact you should rarely use the plain text format, most of the apps (all?) expect Base32 secrets. 2FAuth provides the Plain Text format as a power user feature but I'm not even sure someone really use it.

Is that makes the 2FAuth behavior more clear to you?

[ShlomiPorush]

Okay, I now understand the mechanics. So let's go back to my example, in order to add the code svswywdtwgx2vbty to 2FAuth, i need to set it as Base32 and in the secret field SVSWYWDTWGX2VBTY====. and Indeed it definitely works as you mentioned. Thank you.

Just one question, why doesn't 2FAuth do this conversion like Authy...

BTW, You said that most of the appa issue a Base32 secrets, it's a TOTP that I took from my Office365 account not from some bizarre unknown service..