web-dev-qa-db-ja.com

常にリセットリンクを送信するのではなく、SSL暗号化通信を介してユーザーにパスワードを送信することが安全でないのはなぜですか?

誰かにパスワードをメールで送信したくない理由は理解できますが、SSLで暗号化されたWebページで、パスワードを同じにしたい場合にWebサイトが常にパスワードのリセットを要求する理由がわかりません。それ。

SSLは完全に安全ですか?したがって、セキュリティの観点から、パスワードが盗まれる可能性があると私が想像できる唯一の理由は、PCが侵害された場合であり、その場合、パスワードを作成すると、新しいパスワードも侵害されます。

1
john doe

これに関する3つの大きな問題:

  • サーバーはパスワードを送信できなければなりません。つまり、サーバーはパスワードを知っています。つまり、サーバー管理者/所有者もパスワードを読み取ることができます。これはneverが可能であるべきです(ハッシュ、ソルト、および複数ラウンドの派生関数に関する多くのトピックを参照してください)。すべてのサーバーアクセス権を持つ管理者は、必要に応じてユーザーなどになりすますことができますが、多くのユーザーが複数のことにパスワードを使用しています。管理者はこれらにアクセスできるべきではありません。
  • サーバーがハッキングされている場合、同じことが攻撃者に有効です。パスワードを他の場所で再利用できないため、パスワードを読み取ることはできません。
  • いいえ、SSLは「完全に安全」ではありません。特に、TLSはSSLがかなり安全でないために存在します(ただし、TLSも完全ではありません)。
11
deviantfan

1つの重要な問題はまだ言及されていません:
SSL/TLSでのクライアントの(欠落している)認証

@deviantfanにはいくつかの有効な点がありますが、この基本的な問題を追加したいと思います。その理由は、あなたの提案が実現不可能である理由です。

クライアント認証なしのTLS:

通常、SSL/TLSはサーバーがクライアントに対して自身を認証することで実行されますが、その逆は行われません。つまり、すべてのクライアントがサーバーとの安全なTLS接続をセットアップでき、サーバーが正当なものであることを確認できます。ただし、クライアント認証がない場合、サーバーに接続しているのが本人であるとサーバーが確信することはできません。したがって、この設定では、サーバーがクライアントにパスワードを送信しても意味がありません。

TLSとクライアント認証:

TLSセッションをセットアップするためにクライアント認証が実際に実行される場合、サーバーは、クライアントが本人であると主張している人物であることを確認できます。ただし、クライアント認証を有効にするには、クライアント側に証明書(+秘密鍵)をインストールする必要があります。このような相互認証がすでに確立されている場合は、最初にログインするためのパスワードを用意する必要はありません。

4
oh.dae.su

通常、サーバーはパスワードを保存せず、代わりに「塩」とともにパスワードのハッシュを保存します。ソルトはランダムなデータであり、パスワードをハッシュする一方向関数への追加入力として使用されます。

ソルトを追加してパスワードをハッシュ化すると、辞書攻撃や事前に計算されたレインボーテーブル攻撃を防ぐことができます。

3
kvssd

与えられた答えはかなり適切です。ただし、論理的な観点からは、次のように指摘する必要があります。

「たぶん同じにしたいときは、忘れてしまった」

不可能である。安全であると考えられているサイトは、パスワードを知らず、パスワードを知っているユーザーだけが知っているため、ユーザーがパスワードを完全に忘れた場合、パスワードが失われることを意味します。

次に、パスワードを忘れた場合は、あなたユーザーに適したパスワードではなく、パスワード入力アルゴリズムを満たすパスワードを選択したことを示しています。ユーザーが自分からユーザーを保護しようとせず(「強力な」パスワードを強制的に選択させることにより)、代わりにゲームを起動して、より優れたパスワード保護技術に取り組む必要があるため、通常、障害の多くはサイト設計者側にあります。その点に関して、サイトは「ちょっと、あなたは間違ったパスワードを選んだ。これがより良い、覚えやすいパスワードを手に入れるチャンスだ」と微妙に言っている。

0
Supreme Dolphin