"Token is unsafe" error when I try to enable 2FA

[IngridT1]

Select Topic Area

Bug

Body

I get the following error when I try to enable 2FA on my GitHub ID. My 2FA application is FreeOTP. I am reluctant to add the GitHub token to FreeOTP, until this problem is cleared up. Is there a better place to report a bug than here?

Token is unsafe!
The token you are attempting to add contains weak cryptographic parameters. Use of this token is strongly discourage! Please alert your token provide.

Cancel | Add anyway

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[luc-x41]

The FreeOTP source code distinguishes between four "unsafe token" exception types:

• Unsafe URI
• Unsafe Secret
• Unsafe Digits
• Unsafe Algorithm

But then makes the latter three subclasses of UnsafeUriException and shows the same message for all of them: https://github.com/freeotp/freeotp-android/blob/59a6efea10112360b494e0e03650a69ccd20513c/mobile/src/main/java/org/fedorahosted/freeotp/main/Activity.java#L653-L656

So we can't tell which error is being thrown here, but my first guess would be that the token is fewer than 16 bytes "encoded". Github can't find see a definition for getEncoded() in the repository but based a call elsewhere in the file, where the "encoded" value is passed to a Base32 encoder (ub.appendQueryParameter("secret", base32.encodeAsString(key.getEncoded()));), I am assuming this is the raw byte representation and not the Base32-encoded version. The token that Github provides is 16 bytes in Base32 encoding, corresponding to log(32^16)/log(2)= 80 bits of entropy, whereas 16 raw bytes (256^16), as required, would correspond to 128 bits of entropy.

The code mentions that this minimum is defined in RFC 4226, section 4, requirement 6. Indeed, it says:

The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits.

Github is not complaint with the RFC for HTOPs, but Github specifies that it's a TOTP instead. Its RFC is 6 years newer (2011 instead of 2005) but has no such requirement:

R6: The keys SHOULD be randomly generated or derived using key derivation algorithms.

Which is a bit of an oversight if you ask me. 4 is not a safe secret when chosen by fair dice roll!

However, it does say:

R3: The algorithm MUST use HOTP [RFC4226] as a key building block.

Maybe that means Github is noncompliant with the TOTP RFC after all, because it references following the HOTP RFC as one of its requirements?

Either way, Github should upgrade. If I remember correctly, NIST and AIVD recommend that the industry starts implementing quantum-safe algorithms where possible, which an 80-bit hash probably isn't (per my rudimentary understanding of Grover's algorithm). Using 160 bits, as the RFC recommended as of 2005, sounds much more likely to be safe. If 256-bit tokens are compatible in most implementations, I would personally go for that because there is no downside. Increasing the tokens beyond that is pointless (128-bit-equivalent strength (on a quantum computer) is universally considered safe), but 256 bits of storage is negligible if you're already storing a salted password.

For the time being, though, I think it is safe: validation is an online attack by default, unless someone captures one or more OTPs that you generated, performs a (currently theoretical) brute-force attack on a quantum computer to see which underlying secrets would result in that OTP value, and then tries out which one it is. They also still need your password. An advanced (individualised, not scalable) attack, and that's when presuming the availability of a stable quantum computer.

Conclusion

I would use the provided token for the time being, but Github should start issuing stronger tokens as soon as possible as it may become insecure in the future and there is no practical downside to using at least the token length that the authors recommended in 2005.