Googleが2FA Google Authenticator PAMモジュールを無効にするのはなぜですか？
Google Appsで2FAを有効にする場合、共有秘密は160ビットです。 google_authenticator一方、PAMモジュールは共有秘密に80ビットを使用しているようです。
RFC 4226 によると：
R6-アルゴリズムは強力な共有シークレットを使用する必要があります。長さ
共有シークレットは少なくとも128ビットである必要があります。このドキュメント
160ビットの共有秘密の長さを推奨します。
「必須」ではなく「必須」であることに注意してください。そのため、Google認証システムは非準拠になります。
これを行う理由は何ですか？
このコードの initial commit には、すでに「80ビット」の秘密鍵の長さが含まれています。その後は変わりませんでした。
次に、物事をより批判的に分析しましょう。 HOTPは RFC 4226 で指定されます。認証では、「共有シークレット」を使用します。これは、私たちが話している価値です。 RFC 4226はそれについて何と言っていますか？基本的に、 セクション4 に要件があります：
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.
そして セクション7.5 は、共有秘密を生成するためのさまざまな方法を詳しく説明しています。
これで、google_authenticatorコードは/dev/urandomで80ビットの共有シークレットを生成し、次にこのシークレットをencodeに進みます Base32 でこのシークレット：このエンコーディングは、5ビットの各グループを印刷可能な文字にマップします。したがって、結果の文字列は、16文字で構成され、ASCIIエンコーディング、つまりファイル内でとなる共有シークレットの長さは... 16bytes、つまり128ビットです。したがって、最初の混乱はそれから可能です：保存される長さは、ある意味で、RFC 4226の要件R6に準拠するように見える長さを持っています。
もちろん、RFCは セクション5.1 で「[〜＃〜] k [〜＃〜]」と呼んで「共有シークレット」について話します。次に、それをHMACのキーとして使用します（ セクション5. 、ステップ1）。 google_authenticatorのコマンドラインツールで生成された共有シークレットにより、HMACに入るのは実際には128ビットではなく80ビットのシーケンスですが、これらの80ビットはたまたまエンコードされています保存時は128ビット（ただし、使用時に80ビットにデコードされます）。したがって、この80ビットの秘密は、法的にはRFC 4226の要件R6に実際には準拠できません。ただし、「長さ」の混乱（エンコード後またはエンコード前）によって、google_authenticatorのこの機能が説明される場合があります。
ただし、これは、最初のステップとしてシークレットを生成するために使用できるコマンドラインツール専用です。残りのコードは、より長い秘密の値をサポートしています。
（別の理論では、作者は自分のコードをテストし、特にQRコードがない状況をテストしたいと考えていました。その場合、ユーザーはtypeコードと80ビットのシークレットは、128ビットまたは160ビットのシークレットよりも入力が簡単です。おそらく、最初に短いシークレットを使用して開発を容易にし、その後、公称長に戻すのを忘れていました。一種の事故はかなり頻繁に起こります。
それは重要ですか？私の暗号学者の帽子で、私は答えなければなりません：いいえ。 80ビットの秘密鍵は、ブルートフォースに対して非常に強力です。これは、GPUが多くても2であるためです。79HMAC/SHA-1の評価にはまだかなりの時間がかかります（80ビットのキーでは、ブルートフォースの平均コストは、可能なキーの半分を試すことです（つまり、2）。79評価）。実際、HMAC/SHA-1は「暗号的に強力」であると見なされています。これは、最もよく知られている攻撃が、キーに対するブルートフォースであることを意味します。それに数字を入れましょう：
HMAC/SHA-1は2つのSHA-1呼び出しを使用します。したがって、攻撃コストは、平均して、SHA-12を呼び出すことによるコストです80回。 このページ は、良好なGPUの1秒あたり25億のSHA-1呼び出しのベンチマークを示しています。クラッキングファームをマウントする場合、通常は一流のモデルではなく「ミドルレンジ」のGPUを使用します。 2を実行できる100 $ GPUを使用するとします311秒あたりのSHA-1（20億ビットを少し超えます）。 10億ドルの予算があれば、そのようなGPUを1,000万個持つことができ、平均して652日で攻撃が実行されます。
もちろん、1千万のGPUはかなりのスペースを取り、さらに重要なことに、かなりの量の電力を使用します。各GPUが50W（かなり楽観的な数値）で実行できると仮定すると、各攻撃の実行に必要な時間は8 TW.h（テラワット時）より少し少なくなります。私はケベック州のカナダに住んでいます。巨大なダムと政府による大幅な補助金により電力が非常に安いことが知られており、1 kWあたり約0.05ドルの価格になります（ 価格 を参照）。 。この価格では、1回の攻撃の実行ごとに、電力だけで約4億ドルのコストがかかります。このエネルギーはすべて熱になり、放散する必要があるため、これには冷却価格は含まれません（ある程度、カナダの冬が役立つ可能性があります）。また、すべてのGPUが合計で500 MWを消費することにも注意してください。
これは、次のことを意味します。実際には、80ビットのキーは十分強力です。 80ビットのキーが核ミサイルの発射コードを保護するなら、私は緊張するでしょう。しかし、もし戦略的議論がGoogleの2FAによって保護されていたら、他の理由で私もかなり緊張します。
したがって、この80ビットの秘密は非準拠であり、学問的には「少し短い」ものですが、それでもかなり強力であり、即時かつ徹底的な行動を義務付けていません。コードが修正されればすばらしいでしょう。そうでない場合、世界は回転を停止しません。
コメントで述べたように、Google Authenticatorリポジトリで issue をすでに開いています。ただし、開発者からの正式な返信はありません。リポジトリのアクティビティはかなり停滞しているようです。
GoogleがRFCで推奨されている160ビットではなく80ビットを選択した理由については、おそらく良い説明はありませんが、これが重要な問題である場合は、かなり簡単に修正できます。
私が知る限り、秘密のサイズはlibpam/google-authenticator.c 39行目。
#define SECRET_BITS 80 // Must be divisible by eight
値を80から160に変更しても機能し、私の知る限り何も壊れません。これは、本当にPAMモジュールをRFCに準拠させたい場合に有効です。