Panel: 2FA QR code is invalid when company name contains emoji

[SamusAranX]

Background:

• Panel or Daemon: Panel
• Version of Panel/Daemon: 0.7.15
• Server's OS: Debian 10
• Your Computer's OS & Browser: macOS 10.14.6, Safari 1.12.2

Describe the bug
I set the company name to a single emoji (it was 👾, but for the purpose of this question it's irrelevant which emoji it was) and then made 2FA mandatory for all users.
Now I'm stuck on the Account Security screen because the QR code Pterodactyl generates (or more specifically, the URL encoded in the QR code) is invalid.
In my case, the URL would be otpauth://totp/👾:[email protected]?secret=SECRET_GOES_HERE. Since that's not a valid URL, my authenticator apps refuse to accept it.

I noticed a similar issue here: https://github.com/pterodactyl/panel/issues/1624, but merely replacing spaces won't cut it. You need to make sure the final OTP URL is still 100% ASCII.
I reckon just URL encoding all user-supplied parts would be the easiest fix for this.

To Reproduce
Steps to reproduce the behavior:

1. Set company name to anything non-ASCII
2. Enforce 2FA for all users, specifically yourself
3. Get locked out of the panel due to an invalid OTP URL

Expected behavior
My authenticator app registers the QR code and lets me log in.

[DaneEveritt]

This is so stupid... :|

[DomiiBunn]

Use it's Unicode equivalent and it works fine.

[lancepioch]

urlencode

[MatthewSH]

Why would you want to use an emoji in the company name? What...

[parkervcp]

to use the poop emoji of course.

[MatthewSH]

poop.host

[SamusAranX]

What I want to use in the company name is my choice. Maybe I just like how it looks, maybe I want to use three paragraphs of zalgo'd text. The authors of the URL specs recognized this and provided a way to escape non-ASCII characters in a way that still allowed an URL to be read and processed by any spec-compliant program. As it stands, this is not spec-compliant.

[MatthewSH]

Unless there's some central documentation somewhere on the specifics of 2FA, it really just comes down to the app. On Authy it comes up saying it's not a supported format. The company name, although you'd think differently, actually doesn't matter all that much. It's really the secret that's needed because it's TOTP which every authentication app supports.

It's not really on the panel or any of us to force these apps to support those kind of unicode characters for a feature that's mainly used for display purposes.

[SamusAranX]

A 2FA QR code just contains a regular URL using the otpauth:// protocol, and as such, it has to follow the URL specs. There's zero force involved, it's literally just a matter of "Are the user-defined parts of this URL correctly encoded or not".

Additionally, here's Google explaining the 2FA URI format: https://github.com/google/google-authenticator/wiki/Key-Uri-Format

Emphasis mine:

The label is used to identify which account a key is associated with. It contains an account name, which is a URI-encoded string, optionally prefixed by an issuer string identifying the provider or service managing that account.

[MatthewSH]

...like I said and we found out with spaces, even with properly encoded links, it really comes down to the apps implementation and if it will want to support it or not.

But even with that guide you posted, it breaks on their own apps. Their own properly formatted example...doesn’t even work on some devices.

[lancepioch]

We will accept a pull request to fix this issue. However my thought is that the changes required would invalidate any current 2FA codes too, so these changes would not be BC.

Because of such an easy and reasonable workaround (not using emoji in your company's name), we won't be actively seeking to resolve this issue.

[arcdigital]

It wouldn't invalidate existing codes, as the label isn't used to generate the codes.

[DaneEveritt]

Regardless of how weird the use case, this is a bug that came up as a result of the changes to 2FA. It should be fixed, there are no BC breaks by fixing this.