4
最も長い間、私は「どこでも同じようなパスワード」の問題を避けるために私が訪れるさまざまなサイトのパスワードを生成するためにJavascriptブックマークレットを使用することを検討していました。しかし、this paperを読んだ後、この方法を使用すると悪質な単一のページが私のセキュリティ全体を傷つける可能性があることがわかりました。JavaScriptのパスワードジェネレータのセキュリティに関する考慮事項は何ですか？
私は次のような解決策を考えています。ブックマークレットは、元のURLが追加された新しいページ（例：http://example.com/password_man.html?url=slashdot.org）でURLを開きます。 example.comのページにあるスクリプトは、実際のパスワード生成を行います。
誰もこの方法でセキュリティ上の問題が発生していませんか？私が見る限りでは、悪意のあるページでさえパスワードを見ることしかできず、ではなく、はマスターパスワードのような機密情報にアクセスできます。私はこれを仮定して正しいですか？
より明確化：
- パスワードの生成は完全にクライアント側で実行されます。上記の例で言及されている "password_man.html"には、既にブックマークレットに含まれているようなjavascriptコードが含まれており、マスターパスワードを指定するための入力フィールドが含まれます。
- "url"パラメータの解釈もクライアント側で行われます。私はこのファイルを自分のGoogleコードアカウントの特定のリビジョン（つまり、password_man.htmlのv1234）としてホスティングすることを考えています。
- また、HTTP/HTTPSすべての処理がクライアントブラウザによって行われるため、問題はありません。データはサーバに返されません。 MITM攻撃では、クリアテキストプロトコル（HTTPなど）を使用している場合に、生成されたパスワード（例：そのパスワードはマスターパスワード）を返すようにページを変更できると主張していますが（例：それを提出、またはセッションIDを詮索される要求からパスワードなどをスヌーピング）すでにMITM状況を持っている場合の対処が容易になり、攻撃の他の道があります
更新 ：問題を巡り調査した後、同じページ内でこれを安全に行う方法がないと結論づけました。ブックマークレットがドメインをキャプチャして新しいウィンドウ（window.open経由）を開くだけであっても、悪意のあるサイトはwindow.openを上書きして、実際にマスターパスワードを取得するページのコピーを開くことができます基本的にフィッシング攻撃を行う）。
クイック返信ありがとうございます。私はあなたが提起した問題にうまく対処するためのいくつかの説明を追加しました。まず、生成されたパスワードは、ユーザー名、マスターパスワード、サイトドメインの2つを入力する必要があります（ユーザー名とマスターパスワード）。 第2に、すべての処理がクライアント側で行われるため、MITMの攻撃者は、前後に移動するデータではなく、ダウンロードされているスクリプトのみを監視することができます。リクエストに追加されたURLは、あなたのフィールドの1つを入力するためにローカルのjavascriptによってのみ使用されます。 –