2FAS Peculiarity for Namecheap Token Creation

[britechguy]

I mentioned this in passing yesterday, and the folks at Namecheap stated they have no control over the issue, and that I needed to contact the developers of 2FAS, which I have done. There's now a ticket in on their GitHub site reporting this. In case this should occur for anyone else, for any token, the ticket is: Token for Namecheap being created with "Heap" as identifier

For reasons unknown, scanning the QR code from Namecheap for setting up MFA, resulted in a token branded "Heap" in 2FAS. This occurred twice. I deleted the initial token and tried again in hopes it was a "burp," but it wasn't. My guess is that "Heap" is the generic that gets used when the connection between the site and the database 2FAS uses to identify it somehow goes haywire and there's no match.

Here's a screenshot from 2FAS with the Heap entry at the bottom:

 

[Sky-Knight]

The QR code just contains a URI, and that URI has some sort of formatting. Not all authenticators are tolerant of all URI formats, and sometimes you have to configure the secret manually to fix it.

The part that confuses me? If it's enrolling improperly, a correct TOTP token system will TEST the token. IE after scanning you have to input the six digits to verify it's working as expected before the MFA requirement is enabled. If that test works, then the token works... regardless of what it's named. If that test didn't happen, the service enrolling the token should be slapped, because that's really... really bad. It's very much akin to accepting a password on a single input. It's a poor design that results in problems.

 

[britechguy]

If that test didn't happen, the service enrolling the token should be slapped, because that's really... really bad.

It did happen. But for your average end user it would be confusing for a token not to be identified by the exact same name, and icon, as the site it corresponds with.

It threw me for a loop, and it threw Namecheap tech support for a loop. It was a first-time experience with all this not working "automagically" as expected with regard to proper branding and icon selection.

My main point in posting is so that people know that this is possible, and probably not only in 2FAS. Be prepared and don't freak out.

 

[Sky-Knight]

It did happen. But for your average end user it would be confusing for a token not to be identified by the exact same name, and icon, as the site it corresponds with.

It threw me for a loop, and it threw Namecheap tech support for a loop. It was a first-time experience with all this not working "automagically" as expected with regard to proper branding and icon selection.

My main point in posting is so that people know that this is possible, and probably not only in 2FAS. Be prepared and don't freak out.

OHHH so it does work? It just got the label wrong?

 

[britechguy]

OHHH so it does work? It just got the label wrong?

Yes and yes. I could have sworn that I mentioned that, somewhere, on this forum, but I can't find it now, and I certainly didn't in this topic, so I'll own that omission.

It worked just fine to get in using the 6-digit code that was being generated. But it was being generated under the "branding" of "Heap," not Namecheap, which is just not typical of how this stuff typically works or is supposed to work.

And when it comes to MFA, peculiarities in the usual way things work is very unsettling indeed.

 

[Sky-Knight]

Yes and yes. I could have sworn that I mentioned that, somewhere, on this forum, but I can't find it now, and I certainly didn't in this topic, so I'll own that omission.

It worked just fine to get in using the 6-digit code that was being generated. But it was being generated under the "branding" of "Heap," not Namecheap, which is just not typical of how this stuff typically works or is supposed to work.

And when it comes to MFA, peculiarities in the usual way things work is very unsettling indeed.

That is very odd!

The URI format for this is : otpauth://TYPE/LABEL?PARAMETERS

So it could be something like this: otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example

The bit that really matters is that secret section. and the "name" is the Example:alice@google.com bit.

So it's quite strange for the URI parsing engine to goof up the description, and then get the secret correct. Usually when you're mucking around with text strings errors up front, continue to be errors to the end.

 

[John Kennedy]

Something odd happened with my 2FAS a while back along similar lines. A bunch of tokens that had previously had their own branding all switched to Ting for branding instead. This happened with Datto, SentinelOne, Pax8, Acronis, and others. No idea why. It did coincide with when 2FAS changed their default non-branded icon.

I strongly suspect it's a bug with their own system. I still love the app because of the backup options and the browser extension for automagically inputting the OTP. I rarely recommend it to clients unless they are techy enough to understand the benefits. Most only need one for Google or Microsoft accounts and use text messages for everything else (banks are the worst offenders of making it the only option anyway). I understand why (users are stupid).

 

[britechguy]

use text messages for everything else (banks are the worst offenders of making it the only option anyway). I understand why (users are stupid).

They don't need to be stupid, either (though heaven knows many are). If you work with enough senior citizens, and I do, even text messaging can be a big barrier, but at least it's one they can get over. And the fact that codes sent don't expire in 30 seconds, and require you pay attention to where you are in that 30 seconds, is a big deal.

It also comes back to what is the cost-benefit analysis. Banks are notoriously risk averse, and have folks doing statistical analyses regarding losses, and how those occur, constantly. If the cost of NOT adopting non-SMS MFA were higher than the benefit, it would have been adopted a long while back.

There is such a thing as "secure enough" and "good enough" for intended purposes. There is no perfect, and the pursuit of some utopian "perfect security" is always the enemy of the "good enough." And good enough is just that.