web-dev-qa-db-ja.com

パスワードを変更するときに、ユーザーの既存のパスワードを要求するのはなぜですか？

Webアプリケーションのコンテキストでは、ユーザーが現在のパスワードを変更する場合、通常、最初に現在のパスワードを入力する必要があります。ただし、この時点では、ユーザーは現在のパスワードを使用してログインし、認証されています。

悪意のあるユーザー（ユーザーのマシンの現在のセッションにアクセスする可能性がある）がパスワードを変更できないようにするために、既存のパスワードが必要であることを多少理解しています。ただし、この引数はどのような状況でも使用できませんか？機密情報を要求するたびにパスワードを要求しないのはなぜですか？パスワードを変更する動作はどのように違うのですか？

web-applicationpasswordsauthenticationpassword-management
31
Craig Curtis

ユーザーが（ログインしている間に）数分間コンピューターから離れたままになっている場合、他の誰かが近くを歩いてパスワードをすばやく変更できるようにしたくありません。 1つには、これにより、攻撃者が関連する電子メールアドレスを変更することも可能になり、正当な所有者が自分のアカウントを取り戻すことはできなくなります。

もう1つ、オフィスのいたずらの可能性を考えてみてください。

パスワードの変更は機密性の高い操作であり、ユーザーに再認証を要求することは理にかなっています。また、パスワードの変更は比較的まれな操作であるため、ユーザーに不便はほとんどありません。パスワードを変更するというまれなケースでのみユーザーエクスペリエンスが変更されます。

53
D.W.

他の回答で示されたセキュリティの動機とは別に（パスワードは非常に機密性が高く、ランチタイムのレイドなどの一時的なアクセスを取得して永久的なアクセスに変換したくないため）、実用的な問題が発生する可能性があります。たとえば、password-encrypted user secretsが存在するシステムでは、そのようなデータを復号化して新しいパスワードで再暗号化するために古いパスワードが必要です。これはまさにWindowsオペレーティングシステムで発生することであり（これはUnixセキュリティモデルとの大きな違いの1つです）、一部のWebベースのシステムにも適用されます（Webベースのシステムの動作によって異なります）。

30
Thomas Pornin

これは [〜＃〜] toctou [〜＃〜] 原則（チェック時間/使用時間）と呼ばれ、認証保証ユーザーのID（つまり、ユーザーはstillシステムに認証されたのと同じユーザー）が低すぎて許可できませんパスワードの変更やIDの再定義など、いくつかのアクションを実行します。

重要なアクションが実行されたときに認証保証レベルをできるだけ高くするには、資格情報のチェックから特権の使用までの「デルタTOCTOU」をできるだけ短くして、D.W。が対処する問題を回避する必要があります。

私にとって、これはセキュリティとユーザビリティの間の調整可能な妥協の明白な例です。

25
Henning Klevjer

古いパスワードが必要になるもう1つの理由は、パスワードがハッシュされ、新しいパスワードが古いパスワードとあまり似ていないことを確認したい場合です。その情報を取得できないため、ユーザーに尋ねる必要があります。それ以外の場合は、ハッシュされたパスワードから。

8
Stéphane Chazelas

上記の回答が示唆したように、それはダメージを制限することについてです。

別の例としては、パスワードのリセット機能を http://www.example.com/changepassword.php?newpassword=monkey への呼び出しとして実装した場合、そのようなリンクを作成できます。 tinyurlまたは何かとして非表示にして、そのようなリンクをハッキングしたい人に送信します。ログイン中にリンクをクリックすると、アカウントからロックアウトされて引き継がれます。

5
Bristol

アプリケーションがCSRF（クロスサイトリクエストフォージェリ）トークンを使用しない場合、攻撃者はリンクを送信するだけでパスワードを簡単に更新できます。また、ユーザーがセッションにアクセスしている場合、パスワードを更新できなくなると非常に役立ちます。

2
dany

私は「敏感な行動の確認」のための標準、ガイドライン、または少なくとも認識された用語を探していました。私が見つけたのはOWASP認証チートシートと 機密機能には再認証が必要 セクションがあります。要約すると、攻撃面は次のようになります。

  • CSRF
  • XSS
  • ユーザーのブラウザへの一時的な物理的アクセスを含むセッションハイジャック

敏感な機能の場合、アカウントの現在の資格情報が必要です（現在のパスワードを読み取ります）ほとんどの場合）上記の攻撃のリスクを軽減します。

一部の製品とサービス（以下を参照）では、機密リソースを定義でき、再認証またはステップアップ（ユーザーが追加の認証要素を提供する）を必要とします。

また、UIレベルの強制は推奨されないことに注意してください。 ここ Auth0には、クライアントライブラリを使用して特定の機密リソース用の専用トークンを発行する方法の例があります。

参照：

1
saaj