6

さて、これはおそらく非常に基本的なことですが、開発のこの段階では、その影響は私にとって重要です。どんな意見や議論にも感謝しています。

この例のデータは、SSL暗号化を使用して保護されていません。

page1.php/aspusername変数とpasswordをPOSTするフォームが含まれていますpage2.php/asp。

  • おそらくFiresheepのようなサードパーティのソフトウェアを使用して、どこからでも誰でもPOSTデータをリッスンするだけで傍受できますか？

上記の質問がTRUEになる場合：

  • 暗号化されていないPOSTデータを誰でも自由に利用できると常に見なす必要がありますか？
  • 私のサイトの標準のログインフォームは、そこにさえないセキュリティの層を描写するための単なる策略ですか？
  • 次に、ユーザーエクスペリエンスをパーソナライズする方法として、ログイン機能を検討する必要がありますか？
  • 登録およびログイン手順中にパスワードが保護されないため、ユーザーに通常の（より安全であると想定される）パスワードを使用しないように勧めるのは理にかなっていますか？

私はこれらの問題について熟考し、あらゆる意見やフィードバックに感謝します。

4

4 に答える 4

10

ユーザーが暗号化されていないHTTPを介してログインフォームを送信すると、一連のルートを経由してデータがサーバーに送信されます。これらのルートのいずれかで、はい、誰かがデータを盗聴する可能性があります。また、ユーザーのマシンが感染した場合、ハッカーはデータをローカルで盗聴する可能性があります。

ログインフォームの場合は、SSL、期間を使用する必要があります。また、ユーザーのパスワードがデータベースで暗号化されていることを確認してください。ログインのプロセスは次のとおりです。

  1. ユーザーは、ユーザー名とパスワードを使用してHTTPS経由でログインを送信します
  2. サーバーはパスワードを取得し、ハッシュアルゴリズムを適用します。通常、MD5を使用しますが、SHA256のような強力なものをお勧めします。
  3. サーバーは、暗号化された値をデータベース内の暗号化された値と比較します

そうすれば、データベースがハッキングされた場合、パスワードを理解するのは非常に困難です（「パスワード」のような基本的なものを使用していない限り、それはその時点での彼らのせいです）。

通常の（より安全であると想定される）パスワードは保護されないため、使用しないようにユーザーに勧めるのは理にかなっていますか？

ユーザーを遠ざけることになります。

于 2011-05-16T10:38:29.757 に答える
2

はい。通過するパケットを見ることができる人は誰でも、ユーザー名とパスワードを見ることができます。これにより、オープンな共有 Wi-Fi ネットワークなどで特に脆弱になります。

あなたの仮定はすべて真実だと思います。これが、特にサービスのセキュリティレベルが異なる場合に、サービス間でパスワードを共有することが悪い習慣である理由です.

可能であれば SSL ログインに移行することをお勧めします。これは、共通のパスワードの使用に関するアドバイスを無視するユーザーが非常に多いため、また、SSL ログインが適切な方法であるためです。Firesheep のようなものが「普通の」人が簡単に使えるようになる前は、良い習慣でしたが、今ではさらに重要になっています。

于 2011-05-16T10:40:59.390 に答える
2

Firesheep などのサードパーティ製ソフトウェアを使用して、POST データを傍受するだけで、どこからでも誰でも POST データを傍受できますか?

いいえ、トラフィックはそれらの近くを通過する必要があります。

上記の質問が TRUE の場合:

そうではありませんが、それでもそうです。

暗号化されていない POST データは誰でも自由に利用できると常に考えるべきですか?

LAN のみを通過する場合を除き、はい。LAN のみを通過する場合は、修飾子「その LAN で」を追加すると、答えは「はい」になります。

私のサイトの標準のログイン フォームは、実際には存在しないセキュリティ レイヤーを表示するための単なる策略ですか?

いいえ

ログイン機能は、ユーザー エクスペリエンスをパーソナライズするための手段と考えるべきでしょうか?

確かに、暗号化なしで深刻なことをするべきではありません。

登録およびログイン手順中に保護されないため、通常の (より安全であると想定される) パスワードを使用しないようにユーザーに勧めることは理にかなっていますか?

どのシステムでもそうするのは理にかなっています。通信が安全であったとしても、将来的にサーバーが危険にさらされたり、サードパーティのシステムが危険にさらされたりして、そこにあるデータがシステムを攻撃するために使用される可能性があります.

于 2011-05-16T10:41:11.067 に答える
1
ログイン機能は、ユーザー エクスペリエンスをパーソナライズするための手段として考えるべきでしょうか? 登録およびログイン手順中に保護されないため、通常の (より安全であると想定される) パスワードを使用しないようにユーザーに勧めることは理にかなっていますか?

これは、ログイン フォームを使用する Web サイトによって異なります。Gmail などのほとんどの大規模なサイトでは、ログイン認証に https を使用してから、http に切り替えます。(このスイッチがいくつかの脆弱性をもたらすという報告もあります。) 他のサイトは非表示のフォーム フィールドにソルト値を送信します。元のパスワードはソルトとハッシュに置き換えられます。サーバー上で同じ操作が繰り返され、正しいパスワードが送信されたことを確認します。これはバックグラウンドで行われるため、ユーザーは が暗号化されていないかどうかを実際に確認することはできません。優れたサイトにはこれが期待されます。通常のサイトではこれができない場合があります。ルーターとモデムの構成ページの多くは、暗号化や難読化を採用していません。

于 2011-05-16T10:51:36.593 に答える