"Token is unsafe" message for GitHub token

[roman-khazanskii]

Recently github desided to force me to use 2FA (I have only 6 days left) however when I tried adding github token to FreeOTP it showed me said message.

I'm not sure where should I report this since message doesn't show a lot of details about why token is unsafe and what is going on.

[justin-stephenson]

Please see https://github.com/freeotp/freeotp-android/issues/287

[roman-khazanskii]

Please see #287

Thanks! Having this message for github seems to me a) very surprising b) kinda hard to spot by a github user who probably already added the token a long time ago.

Can I do anything about it (like, report to github team somehow) apart from ignoring it?

[justin-stephenson]

Yes, I would encourage you to open an issue against github stating the RFC compliance requirements mentioned in the #287

[hpsin]

:wave: GitHub PM for Identity here. We use an 80 bit secret for compatibility with Google Authenticator, which had a bug for a very long time around longer secrets. It's unclear if they've since fixed it since it was abandonware for so long - now that they've updated it to support sync, maybe they fixed that too. Right now we have no plans to update the key length.

[dbkeitel]

👋 GitHub PM for Identity here. We use an 80 bit secret for compatibility with Google Authenticator, which had a bug for a very long time around longer secrets. It's unclear if they've since fixed it since it was abandonware for so long - now that they've updated it to support sync, maybe they fixed that too. Right now we have no plans to update the key length.

It's great to see someone from GitHub answer here, but the reply is rather disappointing. You are one of the biggest and most important IT organisations in the world, so when you introduce a supposedly "more secure" authentication method as mandatory, then you should make sure to follow the standards and best practices for that method. If the Google app is outdated in this regard, then you should use your considerable importance as leverage to talk to Google and get them to fix it. Or if they've "maybe" already fixed it, surely there is someone on GitHub staff who can take 5 minutes to test that.

Thanks for your time, but here's hoping for a more serious approach to user security and support.

[orgcontrib]

👋 GitHub PM for Identity here. We use an 80 bit secret for compatibility with Google Authenticator, which had a bug for a very long time around longer secrets. It's unclear if they've since fixed it since it was abandonware for so long - now that they've updated it to support sync, maybe they fixed that too. Right now we have no plans to update the key length.

Bard Question (Prompt): I need help finding out some implementation details about Google Authenticator Android app (https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2). The HOTP algorithm is based on an increasing counter value and a static symmetric key (shared secret). What is the default key size (length) in bits for the shared secret that Google Authenticator uses and what is the maximum supported?

Bard Answer (PaLM2): The default key size (length) in bits for the shared secret that Google Authenticator uses is 80 bits. This is significantly lower than the recommended 160 bits by the RFC 4226, which defines the HMAC-Time-based One-Time Password (HOTP) protocol. The reason for using an 80-bit key is likely to reduce the QR code size and the storage requirements of the Authenticator app. However, using a shorter key also reduces the security of the authentication mechanism. While Google Authenticator supports longer key sizes, it does not automatically use them. Users must specifically request a longer key when they are setting up the authentication for a service. This is typically done by selecting an option in the app's settings. The maximum supported key size is 160 bits. This is the maximum size recommended by the RFC 4226 and is generally considered to be sufficient for most security needs.

[genodeftest]

Github's help also answers this question: I guess this issue can be closed, there is nothing FreeOTP can do here except for showing more details (#287)