パスワードの保管と解読

パスワードはそのまま保存しないのが原則です。代わりにハッシュ値（元に戻せない要約値）を保存し、ログイン時は入力値から計算したハッシュと突き合わせる。この「元に戻せない」性質のおかげで、保管データが漏れても即座に全員のパスワードが分かるわけではありません。ハッシュ関数そのものの性質（一方向性・衝突）は別ページの担当で、ここでは保管方式の選び方と、攻撃側の手口だけを扱います。

ソルトは秘密ではありません。保管データと一緒に置かれ、漏れれば攻撃者にも見えます。それでも成立するのは、狙いが「隠すこと」ではなく「使い回しの計算をさせないこと」だからです。逆に言えば、ソルトが全員同じ値だと目的を果たしません（1つの表を作り直せば全員に使える）。「利用者ごとに違うこと」がソルトの本体です。

アカウントロックが効くのはオンライン攻撃だけです。オフライン攻撃は攻撃者のマシンの中で完結するので、何回失敗しようとロックされる相手がいません。だから設問で「保管データが持ち出された後の対策」を問われたら、ロックや試行回数制限を書いても点になりません。答えるべきはソルトとストレッチング（1件あたりの計算を重くする）、そしてパスワードの再設定です。逆に「ログイン画面への大量試行」ならロック・遅延・多要素認証の側。「どこで試行しているか」を本文から特定してから対策を選ぶのが確実です。

パスワードリスト攻撃は「弱いパスワード」の問題ではありません。他サービスで正解だった組をそのまま打ち込むので、複雑さを増やしても使い回している限り防げない。しかも1アカウントあたりの試行は数回で済むため、アカウントロックの閾値にも引っかかりにくいのが厄介です。対策は複雑さの強制ではなく使い回しをさせないことと多要素認証。設問で「文字種を増やす規則を設けたのに被害が出た」とあれば、この攻撃を疑います。

数え方の落とし穴が2つあります。1つは「長さ8ちょうど」と「8文字以下」の取り違え。「以下」なら1文字から8文字までの合計（10¹+…+10⁸）ですが、最上位の項が支配的なので実質は最長の場合とほぼ同じ。細かく足しても桁は変わりません。もう1つは平均で当たるまでの回数で、全部試すまでではなく候補数のおよそ半分で当たると見積もるのが普通です。「最大何回」と「平均何回」のどちらを問われたかを必ず確認してください。

反復回数は正規の利用者側の待ち時間も同じだけ増やします。ログイン1回に数十ミリ秒〜数百ミリ秒かかっても人間には気になりませんが、攻撃者にとってはその数十ミリ秒が候補数のぶんだけ積み上がる。「守る側は1回、攻める側は何億回」という非対称性を利用しているのがストレッチングです。反復回数は機材の性能向上に合わせて見直して引き上げるものだ、という点も押さえておきます。