Authenticator-Extension
QR Code is defective in particular circumstances
Describe the issue
In particular circumstances, the QR Code «export» for a TOTP credential is defective/invalid. This QR Code cannot be imported in TOTP app (Google Authenticator, FreeOTP…).
After analysis the problem is at the beginning of the otpauth URL.
A normal otpauth URL starts with otpauth://totp/... The invalid URL used to create the invalid QR Code in Authenticator-Extension starts with otpauth://1/...
How to reproduce:
- set up Authenticator-Extension
- set up a master password in Authenticator-Extension
- enrol a TOTP token
- display the corresponding QR Code in Authenticator-Extension
- try to enrol this QR Code in any other app
How to work around:
- remove password protection from Authenticator-Extension before enrolling a new token
- set up password protection again after enrolment
Browser
Firefox
Browser Version
135.x
Extension Version
8.0.2
It is completely broken. In Firefox 136's Add-ons two-step verification, the QR code that appears does not trigger the scanning frame when clicking "Scan QR Code."
this is totally irrelevant to the issue I describe. Please open a dedicated issue for the problem you describe.
Okay, this was annoying me as well! After a bit of debugging, the problem is connected to HOW the totp was added. If you add a totp via manual or import methods, then the type of the entry is set to the numerical value of the OTPType enumerator (OTPType.totp). However, if you scan a QR code to add the totp, the type is getting the parsed string value of totp (instead of 1).
Then later when generating the QR code (eg, to export into another auth), it uses OTPType[entry.type] and since the value of type is totp it then translates that to a '1' and you get the otpauth://1/ instead of the proper otpauth://totp/ prefix.
This inconsistency in how the type is getting stored also causes a problem when attempting to export totp codes to a file because the type of those entries are not matching OTPType.totp and thus they get skipped. I haven't looked to see if the same problem exists in the encrypted backup, but I suspect it maybe similar.
At this point, I am unsure of the best way to address this. I can attempt to add code to examine the type and coerce to the proper form on export and when generating the QR code, but feel that is a bit of a bandaid fix. Of course, if the data is stored wrong, there would need to be a cleanup process to fixup the incorrect type's in storage. Also, I haven't yet identified where the type is not appropriately getting converted on import (eg, probably on QR scan). I can also only assume the intention is for the internal type to be the enum value representation, not the string representation.
