パスワード盗難防止ガイド(5)
パスワード盗難防止ガイド(1)「暗号」というモノを具体的に見つめていくと、「パスワード盗難を防ぐ」という話において重要なのは「その暗号化関数に代入されているのが『正しいパスワード』だけなのかどうか」というポイントである、というのが分かると思います。
パスワード盗難防止ガイド(2)
パスワード盗難防止ガイド(3)
パスワード盗難防止ガイド(4)
上記のような分類にはあまり意味がない、と。
- パスワードを平文で記録するアプリ
→設定ファイル（orレジストリ）を見られただけでパスワードを盗まれてしまう- パスワードを平文以外で記録するアプリ
→設定ファイル（orレジストリ）を見られても「暗号化されたパスワード」しか見えず、それを解読されない限り「平文のパスワード」は漏れない
→現実的には、設定ファイル（orレジストリ）を見られても正しいパスワードは分からない
「意味がある分類」というのは
- 平文のパスワードないし一方向関数への代入結果を記録するアプリ
→設定ファイル（orレジストリ）を抜かれただけでパスワードを盗まれてしまう - パスワードと固有値の複数入力関数への代入結果を記録するアプリ
→設定ファイル（orレジストリ）を抜かれただけではパスワードを盗まれない
設定ファイル（orレジストリ）を抜かれただけではパスワードを盗まれない当然、それが「正しいパスワード」と「固有の値」を複数入力関数に代入した結果であったとしても、「固有の値」さえ分かれば「代入結果」から「正しいパスワード」を求めることは出来ます。
x: 正しいパスワード
a: 固有の値
y: 設定ファイル（orレジストリ）内の文字列
y=f（x,a）=ax
x=g（y,a）=y/a
※
この「固有の値」のように、ある文字列（=「正しいパスワード」）に対する暗号化を強固にするために用いられる補助的な入力（・・・というのもかなり乱暴な説明ですが）は「鍵」と呼ばれます。
つまりa: 固有の値
y: 設定ファイル（orレジストリ）内の文字列
y=f（x,a）=ax
x=g（y,a）=y/a
※
この「固有の値」のように、ある文字列（=「正しいパスワード」）に対する暗号化を強固にするために用いられる補助的な入力（・・・というのもかなり乱暴な説明ですが）は「鍵」と呼ばれます。
パスワードの複数入力関数への代入結果を記録するアプリ
→設定ファイル（orレジストリ）と固有値を抜かれたらパスワードを盗まれてしまう
さて。■2から執拗に「設定ファイルを抜かれる」と「パスワードを盗まれる」の関係について書いてきました。
「『設定ファイルを抜かれる』が『パスワードを盗まれる』に繋がるのは仕方のないことじゃないのか？」と思いながら読んでいた人もいると思います。「複数入力関数とかを使って『設定ファイルを抜かれる』から『パスワードを盗まれる』までの工程を難しくすることは出来ても、根本的に設定ファイルを盗まれたらパスワードは盗まれるだろ」と。
- パスワードを平文で記録するアプリ
→設定ファイル（orレジストリ）を見られただけでパスワードを盗まれてしまう
一方向関数にパスワードを代入した結果を記録するアプリ
→設定ファイル（orレジストリ）を抜かれただけでパスワードを盗まれてしまう- パスワードの複数入力関数への代入結果を記録するアプリ
→設定ファイル（orレジストリ）と固有値を抜かれたらパスワードを盗まれてしまう
上記は一定条件下で正しいです。
- ユーザーによって「abcde」というパスワードが登録される
- FFFTPは「abcde」に暗号化を施し得られた「AFcBFCFBaIYZL」を設定ファイルに記録する
- 次回起動時、FFFTPは設定ファイルから「AFcBFCFBaIYZL」を読み込む
- FFFTPは「AFcBFCFBaIYZL」を解読し得られた「abcde」をFTPサーバーに送信する
FFFTPは「AFcBFCFBaIYZL」を解読し得られた「abcde」をFTPサーバーに送信するFFFTPといったクライアントプログラムは、どんなに複雑な暗号化処理を経ていたとしても、最終的には平文のパスワード（=「abcde」）をサーバーに送信する。「サーバーに送信する」ということは「プログラム内部で認識している」。
そうでなければFFFTPは「abcde」をFTPサーバーに送信することが出来ないのだからまぁFFFTPに限って言えば「設定ファイル内の文字列」は「正しいパスワードを一入力関数に代入した値」な訳ですが、これが「正しいパスワードを複数入力関数に代入した値」であったとしても、その「鍵」がどんなに他人には入手困難な値であっても、その「関数」がどんなに複雑な代物であったとしても、最終的に「正しいパスワードをプログラムが得ている」ならば「必要な全ての値（『設定ファイル内の文字列』や『鍵』）を手に入れた他人は正しいパスワードを解読しうる」。
FFFTPがパスワードを送信すると、FTPサーバーは「その文字列がサーバー内部のユーザーデータファイル内に記述されたパスワードと一致するか」という判定を行います。一致していれば「ログイン成功」で不一致ならば「ログイン失敗」。「一致」「不一致」を判定する際に、FTPサーバーはどのような処理を行っているのか。
・・・コレは最早「クライアントサイドでのパスワード盗難防止」という話から外れているのでここでは扱いませんが、ここまでの話を理解していればすぐに理解できると思います。この連載で三回に渡り書いてきた内容は、実のところいわゆる「（サーバーに対する）パスワードクラック」への入り口でもあったりします。
参考：パスワードクラック概論
※
上記を読んだ人向けに以下の追記をしておきます。先に書いたとおり「クライアントサイドでのパスワード盗難防止」からは外れてますし、次回以降話を戻すので読み飛ばしても構いません。
「自分が抜いた設定ファイル内の文字列が『パスワードを双方向関数に代入した値』なのか『パスワードを一方向関数に代入した値』なのか」というのは大きな差です。前者なら「解読」が可能ですし、後者なら「総当たり」しかない。それを見分けるためのキーワードは、
・・・と、まぁ、せっかくここまで三回をかけて書いてきたので追記しておきます。
で、次回から二回に分け、話を戻しつつ今回のテーマに関する「まとめ」を書きます。上記を読んだ人向けに以下の追記をしておきます。先に書いたとおり「クライアントサイドでのパスワード盗難防止」からは外れてますし、次回以降話を戻すので読み飛ばしても構いません。
「自分が抜いた設定ファイル内の文字列が『パスワードを双方向関数に代入した値』なのか『パスワードを一方向関数に代入した値』なのか」というのは大きな差です。前者なら「解読」が可能ですし、後者なら「総当たり」しかない。それを見分けるためのキーワードは、
そうでなければFFFTPは「abcde」をFTPサーバーに送信することが出来ないのだからです。プログラムが「正しいパスワード」を認識する必要があるなら、設定ファイル内の文字列は必ず「パスワードを双方向関数に代入した値」ですし、必要がないなら「パスワードを一方向関数に代入した値」である可能性が高い。
・・・と、まぁ、せっかくここまで三回をかけて書いてきたので追記しておきます。
今回の結論:
FFFTPのようなクライアントサイドプログラムは必ず「正しいパスワードをプログラム内部で認識している」。故に、究極的には、必ず設定ファイル(orレジストリ)内の文字列は解読可能である。たとえその文字列が「複数入力関数に代入した結果」だったとしても、「設定ファイル」「鍵」の両方を抜かれればパスワードを盗まれてしまう訳で。
FFFTPのようなクライアントサイドプログラムは必ず「正しいパスワードをプログラム内部で認識している」。故に、究極的には、必ず設定ファイル(orレジストリ)内の文字列は解読可能である。たとえその文字列が「複数入力関数に代入した結果」だったとしても、「設定ファイル」「鍵」の両方を抜かれればパスワードを盗まれてしまう訳で。
パスワード盗難防止ガイド(6)
パスワード盗難防止ガイド(7)
TrackBack
この記事へのトラックバック