11

(今のところこの質問が Stack で出されていないことに驚きましたが、検索を行ったところ何も見つかりませんでした oO)

私はサービス ベースの webapp に取り組んでいますが、ユーザー ログインを処理するための最良の方法は何だろうと思います。これまでのところ、私は持っています:

  1. ユーザーがログインすると、クレジットが提供されます。パスワードは、POST 経由でサーバーに送信されるよりも、ローカルでソルト化およびハッシュ化されます (そのため、スニッフィング ユーザーは元のパスワードを取得できません。つまり、他のサイトでパスワードを確認することはできません)。
  2. ログインとハッシュ化されたパスワードは、TTL が 15 分の Cookie に保存されます (Web アクションごとに取り消されます)。
  3. パスワードはサーバー側でソルト化され、再度ハッシュ化され、データベースに保存されているパスワードと比較されます (したがって、パスワードは異なるソルトで二重にハッシュ化されます。これは、データベースに侵入する誰かのためのものです - 彼らはまだ回復できません)ログインクレジット）
  4. ユーザーは、1 つの IP から 5 分間に最大 3 回のログイン試行を行うことができます
  5. ユーザーは、最後に成功したログイン試行と失敗したログイン試行に関する情報を、日付と IP とともに取得します

ハッシュ化されたパスワードの代わりに一意のセッション ID を Cookie に保存する方が良いと誰かが指摘していましたが、なぜそれがそれほど重要なのか疑問に思います。誰かがパケットを盗聴した場合、セッション ID に関係なく、すべてのデータでログインからパケットを取得できます。正当なユーザーを装い、自分自身でログインする必要があります。ログインとハッシュ化されたパスワードをCookieアプローチに保存するよりも、保存されたセッションIDアプローチの他の利点はありますか?

4

3 に答える 3

13

ハッシュ化されたパスワードを Cookie として保存することは非常に厄介な脆弱性であり、OWASP 違反です。パスワードをハッシュすることの要点は、ログインするために攻撃者にハッシュを破らせることです。攻撃者がデータベースからハッシュを取得してログインできれば、パスワードをプレーン テキストで保存するのと同じシステムになります。

すべてのプラットフォームにはセッション ハンドラーがsession_start()あり、PHP では $_SESSION スーパー グローバルを使用するだけです。独自のセッション ハンドラを作成すると、安全性が低下します。

于 2012-10-30T23:41:07.960 に答える
7

セッション ID を保存することで、同じユーザーの異なるセッションを識別することができ、それらを特別な方法で処理したい場合があります (たとえば、単一のセッションのみを許可したり、ユーザーではなくセッションに関連付けられたデータを持ったりします)。

また、さまざまなセッションのアクティビティを簡単に区別できるため、コンピューターでセッションを開いたままにしておくと、パスワードを変更せずにセッションを強制終了でき、他のセッションは違いに気付かない.

于 2012-10-30T19:50:48.713 に答える
0

ダブル ハッシュでは、エクスプロイトから保護されません。保存されたユーザー ID とハッシュ化されたパスワードを Cookie から取得してサーバーに送信すると、すぐにアクセスできるようになります。セッション ID を使用すると、少なくともタイムアウトになります。

于 2015-11-20T20:21:46.360 に答える