5

私はこれまでユーザー認証システムを作成したことがなく、このプロジェクトではセキュリティと効率のバランスをとる必要があります（つまり、セキュリティの終わりに何百人もの工数を費やすことはできませんが、パスワードとログイン情報を保持する必要があります安全）。

認証とセッションにExpressフレームワークとパスポートでNode.jsを使用しています。

私がこれまでに行った調査では、解決すべき3つの問題が示されています。今日まで、私はこれらの問題に共通の解決策が存在するかどうかを文字通り知りませんでした。数時間ランダムに調査を調べても、見つけた答えの完全性に自信が持てませんでした。

問題点：

  1. 暗号化されていないプレーンテキストのパスワードをデータベースに保存しないでください（考えられる答え：サーバー上でパスワードをソルト/ハッシュし、データベースにハッシュを保存します）。

  2. 安全でないhttp接続を介してプレーンテキストのパスワードを渡さないでください（考えられる答え：A--認証プロセスにのみHttpsを使用します。その後httpを使用します。B--ログインページでユーザーにランダムなソルトを送信し、ハッシュします。パスワードクライアント側で、データベースストレージのハッシュを解除して再暗号化します。）

  3. GPUが毎秒700,000,000のパスワードで解読できるような弱い暗号化方式を使用しないでください。（考えられる答え：bcrypt）

これらは、3時間の調査で私が見つけた最も賢明な答えです。これらが十分であるかどうか、それらの弱点は何か、またはどのような代替手段が利用できるかはわかりません。さらに洞察をいただければ幸いです（注：わかりません。httpsはパスワードが送信されるときにパスワードを十分に保護していますか？）

4

1 に答える 1

2

セキュリティのベストプラクティスはたくさんありますが、考え方は基本的に同じです。最高のものを期待し、最悪のものを期待します。それはあなたの3つの問題を説明しています：

  1. 誰かがあなたのデータベースにアクセスしたと仮定すると、パスワードが危険にさらされる可能性は望ましくありません。ハッシュされたパスワードは、ハッシュからパスワードを取得できないことを保証します。
  2. これは、中間者攻撃を回避するためです。サーバーは、サーバーとの間で要求をやり取りするときに、パスワードを簡単にリッスンして記録できます。中間者攻撃が可能であるとは思わない場合でも、最善を期待し、最悪の事態を予想してください。
  3. 覚えやすいが他人が推測しにくい長いパスワードを使用してください。試行回数を5分ごとに3回に制限できれば、クラックするのにさらに多くの時間が必要になるため、さらに良いでしょう。

これらの3つのそれぞれは、誰かがあなたのシステムをクラックしてダメージコントロールを行うか、または時間がかかるためにクラックをほぼ不可能にするという考えに基づいています。パフォーマンスは重要ですが、常にセキュリティほど重要ではありません。常識を主に使用し、仮定に基づいてセキュリティを危険にさらさないでください。これが、セキュリティにエラーを挿入する最も確実な方法だからです。要するに、最高のものを期待し、最悪のものを期待します。

于 2012-09-13T10:28:16.130 に答える