フォームベースの Web サイト認証の決定版ガイド [終了]

08-06-2019
|

質問

Web サイトのフォームベースの認証

私たちは、Stack Overflow が、非常に特殊な技術的な質問に対するリソースであるだけでなく、一般的な問題のバリエーションを解決する方法に関する一般的なガイドラインとしても役立つと考えています。「Web サイトのフォームベースの認証」は、このような実験には適したトピックです。

次のようなトピックを含める必要があります。

ログイン方法
ログアウト方法
ログイン状態を維持する方法
Cookieの管理（推奨設定を含む）
SSL/HTTPS暗号化
パスワードの保存方法
秘密の質問の使用
ユーザー名/パスワードを忘れた場合の機能
の使用ノンス防ぐためにクロスサイトリクエストフォージェリ (CSRF)
OpenID
「私を覚えておいてください」チェックボックス
ユーザー名とパスワードのブラウザーの自動補完
シークレット URL (パブリック URL ダイジェストで保護されています）
パスワードの強度を確認する
電子メールの検証
などなど フォームベースの認証...

次のようなものを含めるべきではありません。

役割と権限
HTTP基本認証

ご協力ください:

サブトピックの提案
このテーマに関する良い記事を投稿する
公式回答を編集する

解決

パート I:ログイン方法

認証のためにサーバー側のスクリプトに値を POST するログイン + パスワード HTML フォームを作成する方法をすでに知っていると仮定します。以下のセクションでは、健全で実用的な認証のパターンと、最も一般的なセキュリティの落とし穴を回避する方法について説明します。

HTTPS にするかどうか?

接続がすでにセキュアでない限り (つまり、SSL/TLS を使用して HTTPS でトンネリングされている場合)、ログインフォームの値はクリアテキストで送信され、ブラウザと Web サーバー間の回線を盗聴している人は、通過するログイン情報を読み取ることができます。を通して。この種の盗聴は政府によって日常的に行われていますが、一般に、次のように言う以外に「所有」電線については取り上げません。重要なものを保護する場合は、HTTPS を使用してください。

本質的には、唯一の 実用的 ログイン中の盗聴やパケットスニッフィングから保護する方法は、HTTPS または別の証明書ベースの暗号化スキーム (たとえば、 TLS) または実証済みかつテスト済みのチャレンジ/レスポンススキーム (たとえば、ディフィー・ヘルマン-ベースの希望小売価格）。 他の方法は簡単に回避できます 盗聴攻撃者によって。

もちろん、少し非現実的になっても構わない場合は、何らかの形式の 2 要素認証スキームを採用することもできます (例:Google Authenticator アプリ、物理的な「冷戦スタイル」コードブック、または RSA キー生成ドングル）。正しく適用されれば、これは安全でない接続でも機能する可能性がありますが、開発者が 2 要素認証を実装して SSL は実装しないとは考えにくいです。

(しないでください) ロールユアオウンの JavaScript 暗号化/ハッシュ

Web サイトに SSL 証明書を設定するコストがゼロではないことと、技術的な難しさが認識されているため、一部の開発者は、安全でない回線を介して平文ログインが渡されるのを避けるために、ブラウザ内で独自のハッシュまたは暗号化スキームを導入しようとする誘惑にかられます。

これは崇高な考えではありますが、本質的には役に立たないものです（そして、セキュリティ上の欠陥) 上記のいずれかと組み合わせていない限り、つまり、強力な暗号化で回線を保護するか、実証済みのチャレンジ/レスポンスメカニズムを使用するかのいずれか (それが何であるかわからない場合は、それが 1 つであることを知ってください)デジタルセキュリティにおいて証明するのが最も難しく、設計するのが最も困難で、実装するのが最も難しい概念）。

パスワードをハッシュ化するのは事実ですが、 できる に対して効果的 パスワードの開示, 、リプレイ攻撃、中間者攻撃/ハイジャックに対して脆弱です (攻撃者がブラウザに到達する前に、セキュリティで保護されていない HTML ページに数バイトを挿入できる場合、JavaScript のハッシュをコメントアウトするだけで済みます)。またはブルートフォース攻撃（ユーザー名、ソルト、ハッシュされたパスワードの両方を攻撃者に渡すことになるため）。

人道に対するCAPTCHA

キャプチャ特定のカテゴリの攻撃を阻止することを目的としています。人間のオペレーターを使用しない自動辞書/ブルートフォースの試行錯誤。これが本当の脅威であることは疑いありませんが、CAPTCHA を必要とせずにシームレスに対処する方法、特に適切に設計されたサーバー側のログイン調整スキームがあります。これについては後ほど説明します。

CAPTCHA 実装は同じように作成されるわけではないことに注意してください。それらは人間には解決できないことが多く、そのほとんどは実際にはボットに対して無効であり、それらはすべて第三世界の安価な労働力に対して無効です（によると）オワスプ, 、現在の搾取料金は 500 テストあたり 12 ドルです)、一部の国では一部の実装は技術的に違法である可能性があります (「 OWASP 認証のチートシート）。CAPTCHA を使用する必要がある場合は、Google の CAPTCHA を使用してください。再キャプチャ, 定義上、OCR が難しく (すでに OCR で誤って分類された書籍スキャンを使用しているため)、ユーザーフレンドリーになるよう非常に努力しているためです。

個人的には、CAPTCHAS は煩わしいと感じる傾向があり、ユーザーが何度もログインに失敗し、スロットル遅延が最大になった場合の最後の手段としてのみ使用します。これは許容できるほど稀に発生するものであり、システム全体が強化されます。

パスワードの保存 / ログインの確認

近年大々的に報道されたハッキングやユーザーデータの漏洩を経て、これはついに常識になったかもしれませんが、次のように言わなければなりません。パスワードを平文でデータベースに保存しないでください。ユーザーデータベースは日常的にハッキング、漏洩、または SQL インジェクションを通じて収集されるため、生の平文パスワードを保存している場合、ログインセキュリティは即座にゲームオーバーになります。

では、パスワードを保存できない場合、ログインフォームから POST されたログインとパスワードの組み合わせが正しいことをどのように確認すればよいでしょうか?答えは、キー導出関数. 。新しいユーザーが作成されるか、パスワードが変更されるたびに、パスワードを取得して、Argon2、bcrypt、scrypt、PBKDF2 などの KDF を介して実行し、平文のパスワード (「correcthorsebatterystaple」) を長いランダムな文字列に変換します。、データベースに保存する方がはるかに安全です。ログインを検証するには、入力したパスワードに対して同じハッシュ関数を実行します。今回はソルトを渡し、結果のハッシュ文字列をデータベースに保存されている値と比較します。Argon2、bcrypt、および scrypt は、ソルトをハッシュとともに保存します。これをチェックしてください記事詳細については、sec.stackexchange を参照してください。

ソルトが使用される理由は、ハッシュ自体では十分ではないためです。ハッシュを保護するために、いわゆる「ソルト」を追加する必要があります。レインボーテーブル. 。ソルトは、完全に一致する 2 つのパスワードが同じハッシュ値として保存されるのを効果的に防止し、攻撃者がパスワード推測攻撃を実行した場合にデータベース全体が 1 回の実行でスキャンされるのを防ぎます。

ユーザーが選択したパスワードは十分強力ではないため、暗号化ハッシュをパスワードの保存に使用しないでください。通常、十分なエントロピーが含まれていないため)、パスワード推測攻撃は、ハッシュにアクセスできる攻撃者によって比較的短時間で完了する可能性があります。これが KDF が使用される理由です - これらは効果的に使用されます「鍵を伸ばして」, つまり、攻撃者がパスワードを推測するたびに、ハッシュアルゴリズムが複数回 (たとえば 10,000 回) 繰り返され、攻撃者がパスワードを推測する速度が 10,000 倍遅くなります。

セッションデータ - 「Spiderman69 としてログインしています」

サーバーがユーザーデータベースに対してログインとパスワードを検証し、一致するものが見つかったら、システムはブラウザが認証されたことを記憶する方法を必要とします。この事実は、サーバー側でのみセッションデータに保存される必要があります。

セッションデータに慣れていない場合は、その仕組みを次に示します。ランダムに生成された 1 つの文字列が期限切れの Cookie に保存され、サーバーに保存されているデータのコレクション (セッションデータ) を参照するために使用されます。MVC フレームワークを使用している場合、これは間違いなくすでに処理されています。

可能であれば、セッション Cookie がブラウザに送信されるときにセキュアフラグと HTTP のみフラグが設定されていることを確認してください。HttpOnly フラグは、XSS 攻撃を通じて読み取られる Cookie に対するある程度の保護を提供します。セキュアフラグは、Cookie が HTTPS 経由でのみ返送されることを保証し、ネットワークスニッフィング攻撃から保護します。Cookie の値は予測可能であってはなりません。存在しないセッションを参照する Cookie が存在する場合は、その値を直ちに置き換えて、問題を防ぐ必要があります。セッション固定.

パート II:ログイン状態を維持する方法 - 悪名高い「Remember Me」チェックボックス

永続的ログイン Cookie (「私を記憶」機能) は危険ゾーンです。一方で、ユーザーがその処理方法を理解していれば、従来のログインとまったく同じくらい安全です。その一方で、公共のコンピュータでこれらを使用し、ログアウトを忘れたり、ブラウザの Cookie が何なのか、その削除方法を知らない可能性のある不注意なユーザーにとっては、セキュリティ上の大きなリスクとなります。

個人的には、定期的にアクセスする Web サイトでは永続的なログインが好きですが、それを安全に処理する方法は知っています。ユーザーも同じことを知っていると確信できる場合は、良心をもって永続ログインを使用できます。そうでない場合は、ログイン資格情報に不注意なユーザーがハッキングに遭った場合に自分自身がそれを招いたという考えに同意するかもしれません。私たちがユーザーの家に行って、モニターの端に並べられたパスワードが書かれたフェイスパームを誘発するポストイットをすべて剥がすわけでもありません。

もちろん、システムによっては、 どれでも アカウントがハッキングされた。このようなシステムでは、永続的なログインを正当化する方法はありません。

永続的なログイン Cookie を実装する場合は、次の方法で実行します。

まずは時間をかけて読んでみてくださいパラゴン・イニシアティブの記事件名に。多くの要素を正しく理解する必要がありますが、この記事ではそれぞれについて詳しく説明しています。
最も一般的な落とし穴の 1 つを繰り返します。 永続ログイン Cookie (トークン) はデータベースに保存しないでください。ハッシュのみを保存してください。 ログイントークンはパスワードと同等であるため、攻撃者がデータベースを入手した場合、平文のログインとパスワードの組み合わせであるかのように、トークンを使用して任意のアカウントにログインできます。したがって、ハッシュを使用します（によると） https://security.stackexchange.com/a/63438/5002 永続的なログイントークンを保存する場合は、弱いハッシュでもこの目的には十分です)。

パート III:秘密の質問の使用

「秘密の質問」を実装しない. 。「秘密の質問」機能はセキュリティのアンチパターンです。必読リストのリンク番号 4 から論文をお読みください。それについては、彼女の Yahoo! にちなんでサラ・ペイリンに聞いてみてください。以前の大統領選挙中に電子メールアカウントがハッキングされました。その理由は、彼女の秘密の質問に対する答えが...「ワシラ高校」！

ユーザーが指定した質問であっても、ほとんどのユーザーは次のいずれかを選択する可能性が高くなります。

母親の旧姓や好きなペットなどの「標準的な」秘密の質問
誰でも自分のブログ、LinkedIn プロフィールなどから引用できる簡単なトリビア
パスワードを推測するよりも簡単に答えられる質問。適切なパスワードであれば、想像できるすべての質問がこれに当てはまります

結論として、秘密の質問は、事実上すべての形式とバリエーションにおいて本質的に安全ではないため、いかなる理由であっても認証スキームで使用すべきではありません。

セキュリティの質問が世に出回っている本当の理由は、電子メールにアクセスできないユーザーから再アクティベーションコードを入手するために数回サポートに問い合わせるコストを都合よく節約できるためです。これは安全とサラ・ペイリンの評判を犠牲にしたものです。価値がある？おそらくそうではありません。

パート IV:パスワードを忘れた場合の機能

なぜそうすべきかについてはすでに述べました 秘密の質問は決して使用しないでください 忘れた/紛失したユーザーパスワードを処理するため。また、言うまでもなく、ユーザーに実際のパスワードを電子メールで送信してはなりません。この分野では、避けるべきよくある落とし穴が少なくとも 2 つあります。

やめてください リセット 忘れたパスワードを自動生成された強力なパスワードに変更します。このようなパスワードは覚えにくいことで知られています。つまり、ユーザーはパスワードを変更するか、たとえばモニターの端にある明るい黄色のポストイットに書き留める必要があります。新しいパスワードを設定する代わりに、ユーザーがすぐに新しいパスワードを選択できるようにします。それがユーザーが望むことです。(例外として、ユーザーが一般にパスワードマネージャーを使用して、通常はメモしないと思い出すことが不可能なパスワードを保存/管理している場合があります)。
紛失したパスワードコード/トークンは必ずデータベース内でハッシュ化してください。また, 、このコードはパスワード同等物の別の例であるため、攻撃者がデータベースを入手した場合に備えてハッシュする必要があります。紛失したパスワードコードが要求された場合は、プレーンテキストコードをユーザーの電子メールアドレスに送信し、それをハッシュしてデータベースに保存します。 原本を捨てる. 。パスワードや永続的なログイントークンと同じです。

最後のメモ:「紛失したパスワードコード」を入力するためのインターフェイスが少なくともログインフォーム自体と同じくらい安全であることを常に確認してください。そうしないと、攻撃者が単にこれを使用してアクセス権を取得することになります。非常に長い「紛失したパスワードコード」 (たとえば、大文字と小文字を区別する 16 文字の英数字) を生成することは良いスタートですが、ログインフォーム自体に行うのと同じ調整スキームを追加することを検討してください。

パート V:パスワードの強度を確認する

まず、この小さな記事を読んで現実を確認してください。最も一般的なパスワード 500 個

さて、おそらくリストはそうではありません 正規の 最も一般的なパスワードのリスト どれでも システム これまでどこでも, しかし、これは、強制的なポリシーが導入されていない場合、人々がパスワードをいかに適切に選択しないかを示す良い指標です。さらに、最近盗まれたパスワードの一般公開されている分析と比較すると、このリストは恐ろしいほど近いものに見えます。

それで：パスワード強度の最小要件がないため、ユーザーの 2% が最も一般的なパスワードの上位 20 個のいずれかを使用しています。意味：攻撃者がわずか 20 回の試行を受けた場合、Web サイト上のアカウント 50 個に 1 個がクラック可能になります。

これを阻止するには、パスワードのエントロピーを計算し、しきい値を適用する必要があります。米国国立標準技術研究所 (NIST) 特別出版物 800-63 非常に良い提案がいくつかあります。これを辞書とキーボードレイアウト分析と組み合わせると (たとえば、「qwertyuiop」は不適切なパスワードです)、不適切に選択されたすべてのパスワードの 99% を拒否する 18 ビットのエントロピーのレベルで。単純にパスワードの強度を計算し、視力メーターを見せるユーザーにとっては良いことですが、不十分です。それが強制されない限り、多くのユーザーはおそらくそれを無視するでしょう。

そして、高エントロピーのパスワードの使いやすさについての新鮮な見方については、Randall Munroe のパスワード強度xkcd 強くお勧めします。

トロイ・ハントを活用する私は Pwned API を取得しましたかユーザーのパスワードを、公的データ侵害で侵害されたパスワードと照合します。

パート VI:さらに多くのこと - または:急速なログイン試行の防止

まず、数字を見てください。パスワード回復速度 - パスワードはどのくらいの期間有効ですか

そのリンク内の表に目を通す時間がない場合は、以下にそのリストを示します。

かかる 実質的に時間がない そろばんを使って解読する場合でも、脆弱なパスワードを解読する
かかる 実質的に時間がない 英数字 9 文字のパスワードを解読するには 大文字小文字を区別しません
かかる 実質的に時間がない 記号、文字、数字、大文字と小文字が混在する複雑なパスワードを解読するには 8文字未満 (デスクトップ PC は、最大 7 文字までのキースペース全体を数日、場合によっては数時間で検索できます)
ただし、6 文字のパスワードでも解読するには膨大な時間がかかります。 1 秒あたり 1 回の試行に制限されている場合は、

では、これらの数字から何が学べるのでしょうか?そうですね、たくさんありますが、最も重要な部分に焦点を当てましょう。大量の連続ログイン試行を防ぐことができるという事実 (つまり、の 強引な 攻撃）実際にはそれほど難しくありません。でもそれを防ぐのは右思っているほど簡単ではありません。

一般的に、ブルートフォース攻撃に対して有効な 3 つの選択肢があります。 (辞書攻撃もありますが、すでに強力なパスワードポリシーを採用しているため、問題になることはありません):

を提示する キャプチャ N 回の試行が失敗した後 (非常に面倒で、効果がないこともよくありますが、ここでは繰り返します)
アカウントのロック N 回の試行に失敗した後、電子メールの検証が必要になります (これは DoS 攻撃が起こるのを待っている）
そして最後に、 ログインスロットル:つまり、N 回の試行が失敗した後の試行間の遅延を設定します (はい、DoS 攻撃は依然として可能ですが、少なくともその可能性ははるかに低くなり、実行するのははるかに複雑です)。

ベストプラクティス #1: 次のような短い時間の遅延は、失敗した試行の数に応じて増加します。

1 回の試行失敗 = 遅延なし
2 回の試行失敗 = 2 秒の遅延
3 回の試行失敗 = 4 秒の遅延
4 回の試行失敗 = 8 秒の遅延
5 回の試行失敗 = 16 秒の遅延
等

このスキームを攻撃する DoS は、結果として生じるロックアウト時間は以前のロックアウト時間の合計よりわずかに長くなるため、非常に非現実的です。

明確にするために：遅延は、ないブラウザに応答を返すまでの遅延。これは、特定のアカウントまたは特定の IP アドレスからのログイン試行がまったく受け付けられず、評価されないタイムアウトまたは不応期間に似ています。つまり、正常なログインでは正しい資格情報が返されず、間違った資格情報によって遅延が増加することはありません。

ベストプラクティス #2: 次のような、N 回の試行が失敗した後に有効になる中程度の時間遅延です。

1 ～ 4 回の試行失敗 = 遅延なし
5 回の試行失敗 = 15 ～ 30 分の遅延

このスキームを DoS 攻撃することは非常に非現実的ですが、確かに実行可能です。また、このような長い遅延は正規のユーザーにとって非常に迷惑になる可能性があることに注意することも重要かもしれません。忘れっぽいユーザーはあなたを嫌うでしょう。

ベストプラクティス #3: 2 つのアプローチを組み合わせる - 次のように、N 回の試行が失敗した後に有効になる固定の短い遅延時間のいずれかです。

1 ～ 4 回の試行失敗 = 遅延なし
5 回以上の試行失敗 = 20 秒の遅延

または、次のように上限が固定された増加する遅延。

1 回の試行失敗 = 5 秒の遅延
2 回の試行失敗 = 15 秒の遅延
3 回以上の試行失敗 = 45 秒の遅延

この最終的なスキームは、OWASP のベストプラクティスの提案 (MUST-READ リストのリンク 1) から引用されたものであり、たとえそれが制限的なものであることは明らかであっても、ベストプラクティスとして考慮される必要があります。

ただし、経験則として、次のように言えます。パスワードポリシーが強化されるほど、遅延によってユーザーを悩ませる必要が少なくなります。強力な (大文字と小文字を区別する英数字 + 必須の数字と記号) 9 文字以上のパスワードが必要な場合は、スロットリングをアクティブにする前に、ユーザーに 2 ～ 4 回の遅延なしのパスワード試行を与えることができます。

この最後のログイン調整スキームを攻撃する DoS は次のようになります。 とても 非実用的。そして最後の仕上げとして、永続的な (Cookie) ログイン (および/または CAPTCHA で検証されたログインフォーム) の通過を常に許可して、正当なユーザーが遅延することさえないようにします。 攻撃の進行中. 。そうすることで、非常に非現実的な DoS 攻撃が可能になります。 非常に 非現実的な攻撃。

さらに、管理者アカウントは最も魅力的なエントリポイントであるため、管理者アカウントに対してより積極的なスロットルを実行することは理にかなっています。

パート VII:分散型ブルートフォース攻撃

余談ですが、より高度な攻撃者は、「アクティビティを分散する」ことでログインスロットリングを回避しようとします。

IP アドレスのフラグ付けを防ぐためにボットネット上で試行を分散する
1 人のユーザーを選択して、最も一般的な 50,000 個のパスワードを試行するのではなく (調整されているため、これはできません)、最も一般的なパスワードを選択し、代わりに 50,000 人のユーザーに対してそれを試行します。そうすれば、CAPTCHA やログイン調整などの最大試行回数を回避できるだけでなく、最も一般的なパスワード 1 位の可能性が 49.995 位よりはるかに高いため、成功の可能性も高まります。
各ユーザーアカウントのログインリクエストの間隔を、たとえば 30 秒間隔にして、目立たないようにする

ここでのベストプラクティスは次のとおりです 失敗したログインの数をシステム全体で記録する, 、サイトの不正ログイン頻度の移動平均を、すべてのユーザーに課す上限の基礎として使用します。

抽象的すぎませんか？言い換えてみましょう:

過去 3 か月間、あなたのサイトで 1 日あたり平均 120 件の不正ログインがあったとします。それ (移動平均) を使用して、システムはグローバル制限をその 3 倍に設定する可能性があります。24 時間で 360 回の試行が失敗しました。その後、すべてのアカウントの試行失敗の合計が 1 日以内にその数を超えると (あるいは、加速率を監視し、計算されたしきい値でトリガーすると)、システム全体のログイン調整がアクティブ化され、すべてのユーザーに短時間の遅延が発生します。 (Cookie ログインやバックアップ CAPTCHA ログインを除きます)。

という質問も投稿しました詳細と、厄介な落とし穴を回避する方法についての非常に優れたディスカッション分散型ブルートフォース攻撃を防御する場合

パート VIII:二要素認証と認証プロバイダー

認証情報は、エクスプロイト、パスワードを書き留めて紛失したり、キーのあるラップトップが盗まれたり、ユーザーがフィッシングサイトにログインしたりすることによって侵害される可能性があります。ログインは、電話、SMS メッセージ、アプリ、ドングルから受信した使い捨てコードなどの帯域外要素を使用する 2 要素認証でさらに保護できます。いくつかのプロバイダーが 2 要素認証サービスを提供しています。

認証はシングルサインオンサービスに完全に委任でき、別のプロバイダーが資格情報の収集を処理します。これにより、問題は信頼できる第三者に委ねられます。Google と Twitter はどちらも標準ベースの SSO サービスを提供していますが、Facebook は同様の独自のソリューションを提供しています。

Web 認証に関する必読リンク

他のヒント

最終的な記事

認証情報の送信

資格情報を 100% 安全に送信する唯一の実用的な方法は、 SSL. 。JavaScript を使用してパスワードをハッシュすることは安全ではありません。クライアント側のパスワードハッシュに関する一般的な落とし穴:

クライアントとサーバー間の接続が暗号化されていない場合、行うことはすべて暗号化されません。中間者攻撃に対して脆弱. 。攻撃者は、受信した JavaScript を置き換えてハッシュを破ったり、すべての資格情報をサーバーに送信したり、クライアントの応答をリッスンしてユーザーになりすましたりする可能性があります。等信頼できる認証局による SSL は、MitM 攻撃を防ぐように設計されています。
サーバーが受信したハッシュ化されたパスワードは、安全性が低いサーバー上で追加の冗長な作業を行わない場合。

と呼ばれる別の安全な方法があります 希望小売価格, 、しかし、それは特許を取得しています（そうですが、自由にライセンスされている) 利用可能な優れた実装はほとんどありません。

パスワードの保存

パスワードを平文としてデータベースに保存しないでください。自分のサイトのセキュリティを気にしていないとしても。ユーザーの一部がオンライン銀行口座のパスワードを再利用すると仮定します。したがって、ハッシュ化されたパスワードを保存し、元のパスワードは破棄してください。また、パスワードがアクセスログやアプリケーションログに表示されないようにしてください。オワスプ Argon2 の使用を推奨します新しいアプリケーションの最初の選択肢として。これが利用できない場合は、代わりに PBKDF2 または scrypt を使用する必要があります。最後に、上記のいずれも使用できない場合は、bcrypt を使用します。

ハッシュ自体も安全ではありません。たとえば、同一のパスワードは同一のハッシュを意味します。これにより、ハッシュルックアップテーブルは、一度に多数のパスワードをクラッキングする効果的な方法となります。代わりに、 塩漬け ハッシュ。ソルトは、ハッシュ化の前にパスワードに追加される文字列です。ユーザーごとに異なる (ランダムな) ソルトを使用します。ソルトは公開値であるため、ハッシュとともにデータベースに保存できます。見るここ詳細については。

これは、忘れたパスワードをユーザーに送信できないことを意味します (ハッシュしか持っていないため)。ユーザーを認証しない限り、ユーザーのパスワードをリセットしないでください (ユーザーは、保存された (および検証された) 電子メールアドレスに送信された電子メールを読み取ることができることを証明する必要があります)。

秘密の質問

秘密の質問は安全ではないため、使用しないでください。なぜ？秘密の質問は何であれ、パスワードの方が効果的です。読む パート III:秘密の質問の使用 で @Jensローランドの答えこのウィキのここにあります。

セッションクッキー

ユーザーがログインすると、サーバーはユーザーにセッション Cookie を送信します。サーバーは Cookie からユーザー名または ID を取得できますが、他の誰もそのような Cookie を生成できません (TODO のメカニズムを説明します)。

Cookieは乗っ取られる可能性がある:これらの安全性は、クライアントのマシンの残りの部分やその他の通信と同じくらいです。これらは、ディスクから読み取られたり、ネットワークトラフィックで盗聴されたり、クロスサイトスクリプティング攻撃によって持ち上げられたり、ポイズニングされた DNS からフィッシングされたりして、クライアントが間違ったサーバーに Cookie を送信する可能性があります。永続的な Cookie を送信しないでください。Cookie はクライアントセッションの終了時 (ブラウザを閉じるか、ドメインから離れるとき) に期限切れになります。

ユーザーを自動ログインしたい場合は、永続的な Cookie を設定できますが、これはフルセッション Cookie とは区別する必要があります。ユーザーが自動ログインしており、機密性の高い操作のために実際にログインする必要があることを示す追加フラグを設定できます。これは、シームレスでパーソナライズされたショッピング体験を提供しながら、財務情報を保護したいショッピングサイトで人気があります。たとえば、再び Amazon にアクセスすると、ログインしているように見えるページが表示されますが、注文するとき (または配送先住所やクレジットカードなどを変更するとき) は確認を求められます。あなたのパスワード。

一方、銀行やクレジットカードなどの金融 Web サイトには機密データのみが含まれるため、自動ログインや低セキュリティモードを許可すべきではありません。

外部リソースのリスト

Web でのクライアント認証の注意事項 (PDF)
多くの素晴らしいヒントが記載された 21 ページの学術論文。
YC に質問してください:ユーザー認証のベストプラクティス
このテーマに関するフォーラムでのディスカッション
パスワードを間違って保存している可能性があります
パスワードの保存に関する紹介記事
議論：コーディングの恐怖:パスワードを間違って保存している可能性があります
コーディングホラー記事に関するフォーラムのディスカッション。
パスワードをデータベースに保存しないでください。
パスワードをデータベースに保存することに関する別の警告。
パスワードクラッキング
いくつかのパスワードハッシュスキームの弱点に関する Wikipedia の記事。
レインボーテーブルで十分:安全なパスワードスキームについて知っておくべきこと
レインボーテーブルとそれに対する防御方法、および他のスレッドに対する防御方法についてのディスカッション。広範な議論が含まれています。

まず、この回答はまさにこの質問に最適ではないということを強く警告します。それは間違いなくトップの答えであってはなりません。

Mozilla の提案についてお話します。ブラウザID (あるいは、おそらくより正確には、検証済み電子メールプロトコル) 将来の認証へのより良いアプローチへのアップグレードパスを見つける精神で。

このように要約します。

Mozilla は非営利団体です。価値観それは、この問題に対する適切な解決策を見つけることとよく一致します。
現在、ほとんどの Web サイトではフォームベースの認証が使用されているのが現実です。
フォームベースの認証には大きな欠点があり、次のようなリスクが高まります。フィッシング. 。ユーザーは、ユーザーエージェント (ブラウザ) によって制御される領域ではなく、リモートエンティティによって制御される領域に機密情報を入力するように求められます。
ブラウザは暗黙的に信頼されているため (ユーザーエージェントの全体的な考え方はユーザーに代わって動作することです)、ブラウザはこの状況の改善に役立ちます。
ここでの進歩を妨げる主な要因は、導入のデッドロック. 。ソリューションは、それ自体で何らかの追加的なメリットを提供するステップに分解する必要があります。
インターネットインフラストラクチャに組み込まれているアイデンティティを表現するための最も簡単な分散型の方法は、ドメイン名です。
アイデンティティを表現する第 2 レベルとして、各ドメインは独自のアカウントのセットを管理します。
フォーム「アカウント」@「ドメイン」は簡潔であり、幅広いプロトコルと URI スキームでサポートされています。もちろん、このような識別子は電子メールアドレスとして最も広く認識されています。
電子メールプロバイダーは、オンラインにおける事実上の主要な ID プロバイダーです。現在のパスワードリセットフローでは、通常、アカウントに関連付けられた電子メールアドレスを管理していることを証明できれば、そのアカウントを管理できるようになります。
Verified Email Protocol は、ドメイン A にアカウントがあることをドメイン B に証明するプロセスを合理化するための、公開キー暗号化に基づく安全な方法を提供するために提案されました。
Verified Email Protocol をサポートしていないブラウザ (現在はすべて) の場合、Mozilla はクライアント側の JavaScript コードでプロトコルを実装する shim を提供します。
Verified Email Protocol をサポートしていない電子メールサービスの場合、このプロトコルにより、サードパーティが信頼できる仲介者として機能し、ユーザーのアカウント所有権を確認したと主張できます。このような第三者が多数存在することは望ましくありません。この機能は、アップグレードパスを許可することのみを目的としており、電子メールサービス自体がこれらのアサーションを提供することが非常に望ましいです。
Mozilla は、そのような信頼できる第三者のように機能する独自のサービスを提供しています。Verified Email Protocol を実装するサービスプロバイダー (つまり、信頼当事者) は、Mozilla の主張を信頼するかどうかを選択できます。Mozilla のサービスは、確認リンクを含む電子メールを送信するという従来の方法を使用して、ユーザーのアカウント所有権を確認します。
もちろん、サービスプロバイダーは、提供したい他の認証方法に加えて、このプロトコルをオプションとして提供することもできます。
ここで求められているユーザーインターフェイスの大きな利点は、「アイデンティティセレクター」です。ユーザーがサイトにアクセスして認証を選択すると、ブラウザには、サイトで自分自身を識別するために使用できる電子メールアドレスの選択 (「個人用」、「仕事用」、「政治活動用」など) が表示されます。
この取り組みの一環として追求されているもう 1 つの大きなユーザーインターフェイスの利点は、ブラウザがユーザーのセッションについてさらに詳しく知ることができるようにする – 主に現在サインインしているユーザー – そのため、ブラウザーの Chrome にそれが表示される場合があります。
このシステムは分散型であるため、Facebook、Twitter、Google などの主要なサイトへのロックインが回避されます。すべての個人が独自のドメインを所有できるため、独自の ID プロバイダーとして機能します。

これは厳密には「Web サイトのフォームベースの認証」ではありません。しかし、これは現在の標準的なフォームベースの認証から、より安全なものに移行するための取り組みです。ブラウザでサポートされている認証。

問題なく動作していることがわかったこのソリューションを共有したいと思いました。

私はそれを ダミーフィールド (ただし、私がこれを発明したわけではないので、私を信用しないでください)。

要するに：これを <form> 検証時に空であることを確認します。

<input type="text" name="email" style="display:none" />

トリックは、ボットを騙して必須フィールドにデータを挿入する必要があると思わせることです。そのため、入力に「メール」という名前を付けました。すでに電子メールというフィールドを使用している場合は、ダミーフィールドに「会社」、「電話」、「電子メールアドレス」などの別の名前を付けてみる必要があります。自分には必要ないとわかっているもの、そしてウェブフォームに入力するのが通常だと思われるものを選択してください。今すぐ非表示にします input CSS または JavaScript/jQuery を使用したフィールド - 最適なものを使用してください - ただ しないでください 入力を設定する type に hidden そうでないとボットは騙されないでしょう。

フォーム (クライアント側またはサーバー側) を検証するときは、ダミーフィールドが入力されているかどうかを確認して、フォームが人間によって送信されたのかボットによって送信されたのかを判断します。

例：

人間の場合:ユーザーにはダミーフィールド (私の場合は「email」という名前) は表示されず、入力しようともしません。したがって、フォームの送信後もダミーフィールドの値は空のままである必要があります。

ボットの場合: ボットには、タイプが次のフィールドが表示されます。 text そして名前 email （またはあなたがそれを何と呼んでも）そして論理的に適切なデータを入力しようとします。入力フォームを派手な CSS でスタイル設定したかどうかは関係ありません。Web 開発者は常にそれを行っています。ダミーフィールドの値が何であっても、それがより大きい限りは気にしません。 0 文字。

私はゲストブックでこの方法をと組み合わせて使用しましたキャプチャ, それ以来、スパム投稿を一度も見ていません。以前は CAPTCHA のみのソリューションを使用していましたが、最終的には 1 時間ごとに約 5 件のスパム投稿が発生するようになりました。フォームにダミーフィールドを追加すると、(少なくとも今までは) すべてのスパムが表示されなくなりました。

これはログイン/認証フォームでも問題なく使用できると思います。

警告:もちろん、この方法は 100% 確実というわけではありません。ボットは、次のスタイルの入力フィールドを無視するようにプログラムできます。 display:none それに適用されました。また、何らかの形式のオートコンプリート (ほとんどのブラウザに組み込まれているのと同じように!) を使用してすべてのフォームフィールドを自動入力している人についても考慮する必要があります。ダミーフィールドを選択することもできます。

ダミーフィールドを画面の境界外に表示したままにすることで、これを少し変えることもできますが、これは完全にユーザー次第です。

クリエイティブに！

上記の答えが「間違っている」とは思いませんが、触れられていない認証の大きな領域があります（むしろ強調されているのは、「どのようなオプションが利用可能で、どのような取引があるか」ではなく、「Cookieセッションを実装する方法」です） -オフ」。

私が提案する編集/回答は次のとおりです

問題はパスワードのチェックよりもアカウントの設定にあります。
2 要素認証の使用は、より賢いパスワード暗号化手段よりもはるかに安全です。
保存されているデータがアカウントの作成と自己生成で価値がない場合を除き、パスワードの独自のログインフォームまたはデータベースストレージを実装しようとしないでください（つまり、FacebookのようなWeb 2.0スタイル、フリッカー, 、など）
1. ダイジェスト認証は、すべての主要なブラウザおよびサーバーでサポートされている標準ベースのアプローチであり、安全なチャネル経由であってもパスワードを送信しません。

これにより、ブラウザ自体が通信を毎回再暗号化するため、「セッション」や Cookie が必要なくなります。これは最も「軽量」な開発アプローチです。

ただし、公共の低価値サービスを除いて、これはお勧めしません。これは、上記の他の回答の一部に伴う問題です。サーバー側の認証メカニズムを再実装しないでください。この問題は解決されており、ほとんどの主要なブラウザーでサポートされています。クッキーは使用しないでください。自分の手で作成したデータベースには何も保存しないでください。リクエストごとに、リクエストが認証されているかどうかを尋ねるだけです。それ以外はすべて、構成およびサードパーティの信頼できるソフトウェアによってサポートされる必要があります。

それで ...

まず、最初のアカウント作成 (パスワードあり) とその後のパスワードの再チェックを混同しています。私が Flickr で、初めてサイトを作成する場合、新しいユーザーはゼロ値 (空白の Web スペース) にアクセスできます。アカウントを作成した人が自分の名前を偽っていても、私はまったく気にしません。病院のイントラネット/エクストラネットのアカウントを作成している場合、価値はすべての医療記録にあるため、するアカウント作成者の身元 (*) に注意してください。

これは非常に非常に難しい部分です。ののみ適切な解決策は信頼の網です。たとえば、あなたは医師として病院に入社します。写真、パスポート番号、公開キーを使用してどこかにホストされる Web ページを作成し、それらをすべて秘密キーでハッシュします。次に、あなたが病院を訪れると、システム管理者があなたのパスポートを調べ、写真があなたと一致するかどうかを確認し、Web ページ/写真のハッシュを病院の秘密キーでハッシュします。これからは、キーとトークンを安全に交換できるようになります。病院を信頼する人なら誰でも同じことができます（ところで、秘密のソースがあります）。システム管理者は次の情報を提供することもできます。 RSA ドングルまたはその他の 2 要素認証。

しかし、これは多く面倒だし、Web 2.0 とは言えません。ただし、これは、自分で作成したものではない貴重な情報にアクセスできる新しいアカウントを作成する唯一の安全な方法です。

Kerberos および SPNEGO - 信頼できるサードパーティによるシングルサインオンメカニズム - 基本的に、ユーザーは信頼できるサードパーティに対して検証を行います。(注：これは決して信頼できないというわけではありません OAuth)
希望小売価格 - 信頼できるサードパーティを使用しない、ある種の賢いパスワード認証。しかしここで私たちは、「たとえコストが高くなっても、2要素認証を使用した方が安全である」という領域に入りつつあります。
SSL クライアント側 - クライアントに公開キー証明書を与えます (すべての主要なブラウザでサポートされていますが、クライアントマシンのセキュリティに疑問が生じます)。

結局のところ、セキュリティ侵害のコストと、より安全なアプローチを実装するコストとのトレードオフになります。いつか、私たちは適切な姿を見るかもしれない PKI 広く受け入れられているため、独自のロール型認証フォームやデータベースはもう必要ありません。ある日...

ハッシュするときは、MD5 などの高速ハッシュアルゴリズムを使用しないでください (多くのハードウェア実装が存在します)。SHA-512 などを使用します。パスワードの場合、ハッシュは遅い方が良いです。

ハッシュをより速く作成できれば、ブルートフォースチェッカーの動作も速くなります。したがって、ハッシュが遅いとブルートフォースの速度も低下します。ハッシュアルゴリズムが遅いため、長いパスワード (8 桁以上) の場合は総当たり攻撃が現実的ではなくなります。

現実的なパスワード強度の推定に関する優れた記事は次のとおりです。

Dropbox 技術ブログ » ブログアーカイブ » zxcvbn:現実的なパスワード強度の推定

認証システムに関する私のお気に入りのルール:パスワードではなくパスフレーズを使用してください。覚えやすく、解読しにくい。より詳しい情報：コーディングの恐怖:パスワード vs.パスフレーズ

多層防御に基づいて、私が使用した提案を 1 つ追加したいと思います。管理者には通常のユーザーと同じ認証システムを使用する必要はありません。高い権限を付与するリクエストに対して別のコードを実行する、別の URL 上に別のログインフォームを用意できます。これは、通常のユーザーにとっては非常に苦痛となる選択を行う可能性があります。私が使用した方法の 1 つは、管理者アクセス用にログイン URL を実際にスクランブルし、新しい URL を管理者に電子メールで送信することです。新しい URL は任意に困難 (非常に長いランダムな文字列) になるため、ブルートフォース攻撃はすぐに阻止されますが、管理者ユーザーにとって唯一の不便な点は、電子メール内のリンクをたどることです。攻撃者はどこに POST すればよいのかさえわかりません。

これに回答として答えるのが最善かコメントとして答えるのが最善かわかりません。私は最初のオプションを選択しました。

ポージングに関しては パート IV:パスワードを忘れた場合の機能 最初の回答では、タイミング攻撃について指摘します。

の中に パスワードを覚えておいてください フォームを使用すると、攻撃者が電子メールの完全なリストをチェックし、システムに登録されている電子メールを検出する可能性があります (以下のリンクを参照)。

パスワードを忘れた場合のフォームに関しては、何らかの遅延関数を使用して、成功したクエリと失敗したクエリの時間を等しくすることをお勧めします。

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

非常に重要なコメントを 1 つ追加したいと思います。-

「で 企業、 イントラ ネット設定」、上記のすべてではないにしても、ほとんどが当てはまらない可能性があります。

多くの企業は、「内部使用専用」の Web サイトを導入していますが、これは事実上、たまたま URL を通じて実装された「企業アプリケーション」です。これらの URL は、 (おそらく...) 「企業の内部ネットワーク」内でのみ解決されます。 (このネットワークには、VPN に接続されているすべての「出張者」が魔法のように含まれています。)

ユーザーが前述のネットワークに忠実に接続している場合、ユーザーの ID (「認証」) 彼らの許可と同様に、[すでに...]「決定的に知られている」 (「認可」) 特定のことをするために...のような ...「このウェブサイトにアクセスするには」

この「認証 + 認可」サービスは、LDAP などのいくつかの異なるテクノロジーによって提供できます。 (マイクロソフトオープンディレクトリ), 、またはケルベロス。

あなたの観点から見ると、次のことがわかります。それ 誰でも あなたのウェブサイトに合法的にアクセスした人 しなければならない 「魔法のように環境に伴う魔法のように含む...]「トークン」を伴う。（つまり そのようなトークンが存在しないことは、直ちに次の理由となるに違いありません。 404 Not Found.)

トークンの価値はあなたにとって意味がありません。 しかし、 必要が生じた場合、あなたのウェブサイトが「（LDAP...を）知っている人に[権威的に]尋ねることができる「適切な手段が存在する」。など）」について そしてすべての（！） あなたが抱くかもしれない質問。言い換えれば、あなたはそうしますないを活用してください どれでも 「自家製の論理。」代わりに、あなたは権限を尋ね、暗黙的にその評決を信頼します。

うん ...その とても 「荒々しく羊毛のインターネット」からの精神的な切り替え。

使用 OpenID コネクトまたはユーザー管理のアクセス.

何もしないことほど効率的なことはありません。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow