アカウント名:
パスワード:
元々ハッシュでパスワードを保存しているとしたらハッシュを生成するタイミングで8文字に切り捨てられてるわけですよね?
で、改修前の認証では、入力文字を8文字までしか認識しないハッシュ生成ロジックを使っていたかもしくは8文字までに切って処理してたかだけど、新しい認証ロジックに切り替える時にハッシュ生成に8文字より長い文字列を利用するロジックが使えるようになったんじゃないですか?
この時の以降の手順としては、過去のデータも使えないといけないけどパスワードそのものが残っているわけじゃないからデータを使い回しできないと大変。なので・昔のデータはそのまま旧タイプのハッシュデータを移行・8文字以下のパスワードを登録するときは旧タイプのハッシュで登録・8文字より長いのパスワードを登録するときには、新タイプのハッシュを使って登録こうしとけば、入力されたパスワードの長さによってハッシュを切り替えることで長いパスワードも使えるようになる。
こうした時に出てくる弊害が、今回の問題だよね。つまり、入力した長さが8文字より長い場合は強制的に新ロジックでチェックされてしまう。8文字に詰められてしまうというのはわかりやすく表現した結果じゃないかなと思うんです。
どうしたもんですかね?この場合。パスワード9文字以上の時は、まず9文字以上のハッシュでチェックして一致しなかったら8文字にカットして認証チェックしてみるべきでしょうか?それ、何だか間違ってるきがするんですよねぇ……まぁ、昔からやってたことだから別にありっちゃありなので改修を入れるとしたらこの方向?
たれこみちゃんと読めよ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
8文字まで詰めたワケじゃないんでは? (スコア:1)
元々ハッシュでパスワードを保存しているとしたら
ハッシュを生成するタイミングで8文字に切り捨てられてるわけですよね?
で、改修前の認証では、入力文字を8文字までしか認識しないハッシュ生成ロジックを使っていたか
もしくは8文字までに切って処理してたかだけど、新しい認証ロジックに切り替える時に
ハッシュ生成に8文字より長い文字列を利用するロジックが使えるようになったんじゃないですか?
この時の以降の手順としては、過去のデータも使えないといけないけど
パスワードそのものが残っているわけじゃないからデータを使い回しできないと大変。
なので
・昔のデータはそのまま旧タイプのハッシュデータを移行
・8文字以下のパスワードを登録するときは旧タイプのハッシュで登録
・8文字より長いのパスワードを登録するときには、新タイプのハッシュを使って登録
こうしとけば、入力されたパスワードの長さによってハッシュを切り替えることで長いパスワードも使えるようになる。
こうした時に出てくる弊害が、今回の問題だよね。
つまり、入力した長さが8文字より長い場合は強制的に新ロジックでチェックされてしまう。
8文字に詰められてしまうというのはわかりやすく表現した結果じゃないかなと思うんです。
どうしたもんですかね?この場合。
パスワード9文字以上の時は、まず9文字以上のハッシュでチェックして一致しなかったら
8文字にカットして認証チェックしてみるべきでしょうか?
それ、何だか間違ってるきがするんですよねぇ……
まぁ、昔からやってたことだから別にありっちゃありなので改修を入れるとしたらこの方向?
Re: (スコア:0)
たれこみちゃんと読めよ