ハッシュの salt はメッセージの前?後?
SMD5 (Salted MD5) についての日記で、以下のように書いた。
tDiary 用フォーム認証プラグインでも、パスワードに salt を付ける実装にしていた。saltがplainの前にあるので、今見るとあまりよくない実装だけど。
これに対して、id:kazuhookuさんから、以下のようなコメントをいただいた。
saltを攻撃側が指定できないから順番は関係ないんじゃないかな。どのみち1ブロック内に収まるだろうしと思うんですがkwsk plz
メッセージとそれに付与する salt はどっちが先がいいんだろう。結論から言うと、「よくない実装」と書いたのは僕の勘違いだったみたい。 先日の日記を書いているときに思ったのは、はてな認証APIに対する奥さんの指摘 (参考、独自MACの危険性)だった。
「ある値」と「秘密鍵+ある値」のハッシュ値が入手できれば、秘密鍵を知らなくても MAC を作ることができる
この例では、秘密鍵がメッセージの前にあることが問題になっていた。
今回の例(パスワードの保存方法)との違い
指摘されて気が付いたけど、メッセージ認証 (MAC) のためにハッシュを使うのと、パスワードを保存するためにハッシュを使うのには違いがあった。
メッセージ認証 (MAC) | パスワード保存 | |
メッセージ | 公開 (認証結果など) | 非公開 (パスワード) |
付与するランダムデータ | メッセージで共通 (秘密鍵) | メッセージごとにバラバラ (salt) |
ランダムデータの目的 | メッセージの作成者の特定 | 辞書を用いた事前計算の防止 |
攻撃者の目的 | 偽MACの生成 | ハッシュ値からのパスワードの解読 |
独自MACの危険性で書いたような危険性 (extension attack) があるのは、 salt が固定の場合でかつ生成されるハッシュ値を偽造する必要がある場合だった。 今回は kazuho さんも指摘されているように、 salt は毎回変わる。 それに出力されたハッシュ値を公開する訳でもない。
今回のケースでは extension attack が成立しないから、 salt とplain の関係はどちらが先でもOKなのかな。