Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 40 subscribers
  • Views 5276 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

BUG: (v16.05.01 MR 1) The otpauth:// URI encoded in the QR code (image) is incorrectly undergoing URI encoding

Valdemar Jakobsen

When configuring TOTP logins for users, the otpauth:// URI encoded in the displayed QR code is incorrectly URI encoding the payload data causing software TOTP token applications to generate the wrong tokens.

  • QR code image
  • Account: someuser%40C020053HBCDGM1A
  • Secret (HEX): [...]
  • Secret (BASE32): PQYV3KY5D374GGKAKC3CSHBXHZ======

The ====== in this example is incorrectly being URI encoded and presented as %3D%3D%3D%3D%3D%3D.

Here is an example of the output read from the QR code image:

  • otpauth://totp/someuser%40C020053HBCDGM1A?secret=PQYV3KY5D374GGKAKC3CSHBXHZ%3D%3D%3D%3D%3D%3D&issuer=Sophos%20SFOS&period=30

which should actually be:

  • otpauth://totp/someuser%40C020053HBCDGM1A?secret=PQYV3KY5D374GGKAKC3CSHBXHZ======&issuer=Sophos%20SFOS&period=30

Either manually entering the (BASE32) secret into the token generator or editing the otpauth:// URI after scanning resolves this issue.

The behaviour above affected both Authy and 1Password, but will likely affect all QR code reading authenticator applications.



This thread was automatically locked due to age.
  • 0

    Thanks for the hint. I will try to reproduce this and will open a ticket if required.

    Have you tried to use Sophos Authenticator app?

    At a first glance it looks reasonable to do URI encoding on the padding characters =, otherwise the padded = chars cannot be distinguished from the =

    as assignment operator.

Unfiltered HTML