パスワードのメールが証明するのは可逆性であり、保存方式ではない

利用者の現在のパスワードをメールで送るサービスは、送信できる形でその秘密を入手できるという一つのことを示した。それは、どの列、アルゴリズム、ライブラリがそれを生み出したかではない。この区別が重要なのは、指摘自体は事実であり、そこから人が導く結論はたいてい過度に具体的だからである。経路のどこかに可逆性があることが仕組みであり、推測された保存形式ではない。

証拠はその水準に保っておけば、レビューの残りは正確なままである。

古い秘密を送り返すことが証明するもの

一方向の検証器は、反転しないよう設計されているため、元のパスワードを生成できない。サービスがパスワードをメールで送れるなら、その時点でパスワードを復元できる素材を保持しているか、ハッシュ化の前に平文を傍受して保存している。いずれの場合も復元の経路は可逆であり、これは真正のセキュリティ上の指摘である。同じデータベースが他の列にコストの高いハッシュを使っているかどうかについては何も言っていない。

中間の場合にも注意すべきであり、アプリケーションが保持する鍵で暗号化して保存されたブロックは、報告書の中で暗号化という言葉が安心感を与えても、実際には可逆である。

なぜこれが設計上の指摘であって、保存の地図ではないのか

メールは復元可能性を証明するが、正確な方式を特定しない。平文かもしれないし、決定論的暗号化、ベンダーの難読化ルーチン、復元専用の別の資格情報ストアかもしれない。製品の異なる部分はしばしば異なる保存を使う。メール一通を根拠にアルゴリズムを割り当てるのは、次の会議で崩れる種類の主張である。

言えることはより狭く、より有用である：この経路は秘密を復元できるので、製品は復元可能な資格情報が存在しないとは主張できない。それ以上はすべて運用者の証拠を必要とする。

リセットは認可を中心に組み立てる

リセットは別の問題を解く：要求者が新しいパスワードを選んでよいと証明することである。これについての OWASP のガイダンスは、適切な有効期限を持つ、安全に生成された単回使用のトークンやコードを説明しており、要求の段階を列挙と洪水から守るべきものとして扱っている。認証されていない要求が単独でアカウントを変更してはならない。置き換えを受け入れる前に認可を検証し、一度の成功した使用の後にトークンを使えなくする。

メール経路はセキュリティモデルの一部である。アカウント名を所持していることは何も証明せず、アカウントの有無を明かすリセットの流れは攻撃者に作業の手引きを与える。

パスワードが守っていたものを無効にする

パスワードを変更しても、それが与えていたアクセスは自動的に終わらない。有効な VPN セッション、記憶されたデバイス、サーバーが発行したトークンは、それぞれ独自の無効化の挙動を持ちうる。リセットでどこからもサインアウトされたと考える利用者はしばしば間違っているため、どれを終わらせるべきかを意図的に決め、実装がそうしていることを検証すべきである。その決定を流れとともに記録する。

運用者向けには、どのコンポーネントが要求を検証し、どれが資格情報を変更し、関連するセッションがどう扱われるかを文書化する。利用者向けには、正規の復元経路を守り、パスワードを返送するメッセージはすべて不審なものとして扱う。

正確な評価は短い：メッセージが何を証明し、何が不明のままで、復元が制御されたプロセスによるアクセスを置き換えるかどうかである。