10周年のSPコンテンツ!
17
flat/京山和将@昼夢堂 @flat_ff
パスワードハッシュ値のsaltって低品質の乱数由来でもいいんだろうか?ユーザーごとに分けろって話はあるけど、精度はあまり問題にならない?見つけた範囲では、/dev/urandomつかってるものから、平文パスのmd5を使ってるものまでさまざま。
徳丸 浩 @ockeghem
@flat_ff そもそも乱数である必要がないと思います。平文パスのmd5は良くないと思いますが
flat/京山和将@昼夢堂 @flat_ff
@ockeghem 今のところの要件は、「ユーザーごとに異なる」ことと「推測できないこと」で合ってますか?それに合致させるのに乱数が使いやすいというだけってことですよね。
flat/京山和将@昼夢堂 @flat_ff
@ockeghem 安全なsaltの作り方というほどの基準はないにしろ、危険な(やってはいけない)saltの作り方ってありそうですね。どんな例があるでしょうか?何らかのユーザー情報を元にしたり、時刻を元にした例も見ました。
徳丸 浩 @ockeghem
@flat_ff Saltを乱数にした場合データベースに保存しないといけないので、予測不可能性をSaltに求めても意味がありません。ということで、乱数にする必要もありません。最低限の要件は、短くないことと、ユーザ毎に違うことです。パスワードを元にしたSaltは後者を満たしません
flat/京山和将@昼夢堂 @flat_ff
@ockeghem 乱数については了解です。細かい違いですが、同じユーザーがパスワードを変えるときに、saltは同じでいいのでしょうか?変えても同じsaltなら、一度変えて戻したときにハッシュ値も同じになりますよね。これは問題ないですか?
徳丸 浩 @ockeghem
@flat_ff 特に気にしなくてもよいと思っています。というか、変える根拠が見あたりません。そういう、なんとなく○○すると良い、××するべきだ、という主張が多くてイライラしますね
flat/京山和将@昼夢堂 @flat_ff
@ockeghem ちょっとひっかかったのは、IDとsaltのペアがわかっていれば、事前にハッシュテーブルを用意できるかなと思いました。人数分用意する必要はありますが、ターゲットが絞れるなら充分脅威かも、と。
flat/京山和将@昼夢堂 @flat_ff
@ockeghem 「○○すべき」というなら根拠出したり責任持ったりして欲しいですよね。でも、そう言わないと「何をやればいいのかわからない」と言われて何もしてもらえないことも多々あります…
徳丸 浩 @ockeghem
@flat_ff まぁ書いてて困ることがあるのも確かで、根拠が怪しい時は「パスワード入力欄は通例マスク表示する」とか、「パスワードの定期的変更は一般的なガイドラインとして認知されている」などと書きますね。
松村 成裕 @PrimaryText
@flat_ff とりあえずハッシュになってれば、そこまで気にしないという実装、多いと思う。ウチ、銀行じゃないし、って逃げ道。
flat/京山和将@昼夢堂 @flat_ff
さっきのハッシュsaltの話って、あとでまとめたほうがいいのかな。実例とかもうちょっと欲しい感じ。
flat/京山和将@昼夢堂 @flat_ff
【まとめ】短いsaltは使わない。別のユーザーに同じsaltを使わない。saltに乱数を使う必要はない。平文パスのハッシュ値をsaltにしない。
flat/京山和将@昼夢堂 @flat_ff
---------- その後考えてみたこと ----------
flat/京山和将@昼夢堂 @flat_ff
UNIXのpasswdの実装がランダムに見えるsaltなので、擬似乱数を使ってる実装が多い。(実際はUNIX TIME+PIDを使っている) 同じユーザーの同じパスワードでも毎回ハッシュ値が変わる。その妥当性はどうあれ、広く使われている方法に合わせるのは悪い手法ではないと思う。
flat/京山和将@昼夢堂 @flat_ff
ユーザーIDをsaltとした場合、毎回saltが変わる場合に比べてメリットはあるのか?ひとつ思いついたのは、「パスワード再利用禁止」にたいする優位性。
flat/京山和将@昼夢堂 @flat_ff
同じユーザーが同じパスワードを使う限り、再設定しても同じハッシュ値になる。なので、「同じパスワードを一定期間再設定禁止とする」ポリシーに対してハッシュ値のみで実現できる。
flat/京山和将@昼夢堂 @flat_ff
何らかの理由でsaltを変えたいときが出るかもしれない。そのときはIDごと変えないといけないけど、そういう場合が出るかは不明。IDとは別にsaltを記録して、単なるパスワード変更ではsaltを変えないという運用もありそう。
flat/京山和将@昼夢堂 @flat_ff
IDをそのままsaltにする場合は、一意性を保ったまま十分な長さを確保しないといけない。「IDには使えないけどsaltには使える文字」で埋めるか、IDのハッシュ値を使う方法がありそう。

微妙な違和感が残っていたのを形にできたので、質問してみました。

flat/京山和将@昼夢堂 @flat_ff
@ockeghem wasbook p.327 51-001のパスワードのハッシュ化について質問です。運用中にハッシュアルゴリズム(あるいはストレッチ回数)を変えることになった場合、単にソースを変更しただけでは認証ができません。どういう対応が望ましいでしょうか?
flat/京山和将@昼夢堂 @flat_ff
@ockeghem ちょっと考えた方法は、ログイン認証時に新旧両方のアルゴリズムでハッシュ値を出して比較します。新ハッシュ値と一致ならそのまま認証OKとし、旧ハッシュ値と一致なら新ハッシュ値で置換してOK。両方と不一致ならNGです。問題ないでしょうか?
徳丸 浩 @ockeghem
@flat_ff それでも大きな問題はないと思いますが、ハッシュ値にアルゴリズムを示す番号を追加しておくと良いです。1:XXXX だったらバージョン1の方法、2:XXXXだったらバージョン2の方法という具合に。後から追加する場合は、XXXX → 2:XXXX という具合
flat/京山和将@昼夢堂 @flat_ff
@ockeghem UNIXのpasswdで見る$1$っぽい(ただしsaltを含まない)イメージですね。ありがとうございました。

もし他のシチュエーションがあっても、バージョン付けで実装すれば多分対応できそうです。
パスワード変更時にももちろんハッシュのバージョンは変えられるのですが、ログイン時にもこっそり上げられるというのは地味にいいポイントなのかなと思います。

コメント

keyray @Keyray7 2011年1月13日
短くないことと、ユーザ毎に違うこと、予測不可能性はいらない、とすると一意で最低文字数制限ありならユーザIDでもいいのかしら?
Masafumi Negishi @MasafumiNegishi 2011年1月14日
Windowsでユーザー名をソルトに使用している例がありますね。Cached Credentialsと呼ばれるドメインユーザーのパスワードハッシュが確かそうです。
flat/京山和将@昼夢堂:ゲムマ秋土曜Q10 @flat_ff 2011年1月14日
passwdのソースを検索してみました。 http://www.bsdlover.cn/study/UnixTree/V7/usr/src/cmd/passwd.c.html この例では、UNIX TIMEにPIDを加えたものを変換してsaltにしているようです。
flat/京山和将@昼夢堂:ゲムマ秋土曜Q10 @flat_ff 2011年1月22日
いろいろ考えてみたことを追記。ツッコミや指摘など歓迎です。
flat/京山和将@昼夢堂:ゲムマ秋土曜Q10 @flat_ff 2011年6月16日
ハッシュアルゴリズムなどの変更時に関する質疑応答を追加。
flat/京山和将@昼夢堂:ゲムマ秋土曜Q10 @flat_ff 2011年6月27日
参考 徳丸本のあれこれを実践してみて気付いたこと | 水無月ばけらのえび日記 http://bakera.jp/ebi/topic/4441
ログインして広告を非表示にする
ログインして広告を非表示にする