Token is invalid! Token is unsafe!

[ninernet]

Hi there,

I encountered (and am still embroiled in, after over three weeks) a situation with two different providers of three different accounts, one a domain registry and the other a bank. I commented on this on 16 January in the issue "Please add more details on 'Token is unsafe!' message #287". I wasn't expecting a direct reply to an issue that someone already seemed to have brought up and which seemed to be getting attention, but considering FreeOTP was updated yesterday (27 January) to version 2.0.1 (42) with no change in how it reacts to the QR codes I've tried to scan, I've decided I need to open my own issue to try to determine whether the issue is with the two different providers or if the issue is with FreeOTP.

I spent just under an hour on the phone with my bank yesterday (much of which was hold time, of course) to try and resolve this issue, but the attempt resulted in a new issue. They asked me to use the option that didn't involve scanning a QR code, instead entering an alphanumeric code. However, when I do that I get this error:

Token is invalid!

The token you are attempting to add is invalid. Please alert your token provider.

The code was 16 characters long. I tried two different codes four times, three times for the first and once for the second. I could not copy and paste the code, partly because the bank's web page prevented me from copying it to my clipboard, and partly because the code was presented to me on my laptop and the app is, of course, installed on my phone. (I could have worked around that, of course, if I could have copied the code on the bank's website.) However, we'll just have to assume that I was careful enough not to make a transcription error four times in a row.

I won't bore you with the arguments I've had with my bank over their claims that they don't support phones made by a particular manufacturer (Motorola) and that they only support authenticator apps that are "compatible" with their system ... which, of course, means "Google Authenticator". But it shouldn't surprise anyone here that I don't want to use Google products unless I'm forced to (as I am with Android itself, obviously), and I also prefer to support open source and in particular Red Hat, considering I use RHEL.

I'll be frank: Given the issues that others have had with the "Token is unsafe!" error I very strongly suspect a bug in FreeOTP, which bug is described in the issue in which I first reported a problem. So I was stunned when yesterday's update didn't seem to fix that problem. But, FreeOTP worked perfectly for me for the year or so I've been using it and I am loath to spend my time researching and selecting a different authenticator and even more loath to use Google Authenticator.

Should I do the latter, or is this indeed a FreeOTP bug and I should just be patient and not worry about the fact that I can't access my bank accounts online or renew domains that are on the verge of expiry?

Craig

[justin-stephenson]

Hi,

Sorry for the issues you are experiencing. If you can provide the otpauth URI of the QR code (similar to https://github.com/freeotp/freeotp-android/issues/301#issue-1550513339), then we can quickly determine the reason for the 'Token is invalid' message. In a browser you may be able to right click the QR code image to save of copy the OTP URI string/value.

Most likely the QR code being provided to you is violating the URI format of https://github.com/google/google-authenticator/wiki/Key-Uri-Format or violating the https://www.ietf.org/rfc/rfc4226.txt requirements.

We fixed similar issues in the latest release but it appears to be something different than with your bank OTP token.

[ninernet]

Hi Justin,

Thanks in advance for your help, but sorry, I'm pretty sure this isn't what you need though:

https://ok12static.oktacdn.com/assets/js/sdk/okta-signin-widget/5.16.1/img/ui/indicators/scanerror.png

I get that from right-clicking the QR code and selecting "Copy Image Link" i the pop-up menu. This is Firefox. That link isn't anything like the "otpauth://" link in the issue you pointed to, and the image there is just an "X", not the QR code. I checked the source and the "accessibility properties" as well but can't find anything similar.

Considering this is the QR code generated by my bank -- I'm not the party generating the QR code -- is it even possible for me to get the "otpauth://" link?

Craig

[justin-stephenson]

Hi Justin,

Thanks in advance for your help, but sorry, I'm pretty sure this isn't what you need though:

https://ok12static.oktacdn.com/assets/js/sdk/okta-signin-widget/5.16.1/img/ui/indicators/scanerror.png

I get that from right-clicking the QR code and selecting "Copy Image Link" i the pop-up menu. This is Firefox. That link isn't anything like the "otpauth://" link in the issue you pointed to, and the image there is just an "X", not the QR code. I checked the source and the "accessibility properties" as well but can't find anything similar.

Considering this is the QR code generated by my bank -- I'm not the party generating the QR code -- is it even possible for me to get the "otpauth://" link?

Craig

Hi, you should still be able to view the OTP URI even when you are not the one generating the QR code image. You could try some suggestions in https://www.qrcode-tiger.com/read-a-qr-code-from-an-image ?

[ninernet]

I hope this is what you need:

Call me paranoid, but I'm not au fait with OTP URIs, so in order to avoid the possible pitfalls of possibly exposing myself to some sort of automated harvesting, I've *removed* the first letter of the "secret" parameter. It is the capital first letter of the word "romeo". I've also changed the first letter of the bank's root domain (in two places) from the first letter of the word "victor" to the first letter of the word "bravo".

[ninernet]

Oh, and as I was posting my last message, the bank called me back (because Friday's phone call wasn't properly completed) and they will not spend any more time "supporting" this "third-party" (i.e., non-Google) authenticator app. I told them I had opened this ticket and said that I planned to try to work through it with you, but that I understood their business decision not to spend time supporting an app when other apps seem to work just fine.

[justin-stephenson]

Hi, I edited your comment to remove the sensitive secret data from this ticket.

The reason for the Token is unsafe message is the same as described in https://github.com/freeotp/freeotp-android/issues/287#issuecomment-1405094971

You can check section 4, R6 of RFC4226 to see the following HOTP requirement:

   R6 - The algorithm MUST use a strong shared secret.  The length of
   the shared secret MUST be at least 128 bits.  This document
   RECOMMENDs a shared secret length of 160 bits.

This is enforced on the FreeOTP side. You can decide for yourself if you want to accept the risk or not, the top answer may be worthwhile reading for your knowledge - https://security.stackexchange.com/questions/45053/why-does-google-cripple-the-2fa-google-authenticator-pam-module

Most likely the OTP vendor will not be making any changes to their secret generation implementation, this is why the Add anyway option is available to ignore this Token is unsafe message. Hope this helps.

[ninernet]

Thanks. I've read that SE answer and this is what I get out of it, as a reasonably technical user but without the cryptography education:

• My bank (and apparently the domain registry where I'm getting the same errors) is generating QR codes that are not fully and technically compliant with RFC4226.
• But the second part of the answer seems to suggest that both organisations are doing "good enough" jobs ... as long as I'm not a multi-gazillionaire (umm, I'm not) and I don't have nukes (I don't).

Which leads me to wonder out loud if, therefore, FreeOTP is forcing pedantry on its users, and we should either use a different authenticator app or just choose the "Add anyway" option. (I don't mean that to sound like hostility against a free app.) Perhaps the latter choice is the focus of some of the other issues open here -- i.e., asking that you provide more information about how FreeOTP is technically correct, but you (the user) might not want to be so pedantic and just "add [the token] anyway".

Considering all of what I've written so far (in this and previous messages), it seems to me that my best choice is to go against all of my self-training where "good enough" is never really good enough and choose that "add anyway" option. That seems to be what you're saying in your last sentence. Am I right?

[justin-stephenson]

As I mentioned in the other ticket we need to include more detail in FreeOTP to clearly state why the Token is unsafe message is shown, this is important for keeping users informed and aware of security concerns.

Ideally, all OTP vendors will generate secrets which are fully RFC compliant but unfortunately that is not the case. FreeOTP strives to be RFC compliant, in some cases we may fully restrict access to using a token which has true security consequences. However, as you've seen here there may be cases where FreeOTP should allow to use a RFC-noncompliant token (less than 128 bits).

In general I would recommend opening a ticket with your OTP vendor explaining this issue, and continue using this token in the meantime.

[ninernet]

Thanks Justin, I appreciate your forthrightness. Yes, some detail (perhaps along the lines of what I suggested above) in the warning/error message would likely help people make reasonably intelligent decisions on how to proceed, or not, and may even have resulted in my not coming here to seek advice.

I intend to bring this Github issue to the attention of both of the vendors I've mentioned but, like you, I have little hope that it will have any results, not until quantum computing makes 80 bits trivial. I note that the SE answer to which you linked is pretty much a decade old!

Feel free to close this issue. I'm not very active on Github so I'm not really sure what the etiquette is around my closing it.

[justin-stephenson]

Thank you Craig for the discussion and understanding.