security - 種類 - webアプリ 認証方式




フォームベースのWebサイト認証の最終的なガイド (8)

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

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

次のようなトピックが含まれています。

  • ログイン方法
  • ログアウトする方法
  • ログインしたままにする方法
  • クッキーの管理(推奨設定を含む)
  • SSL / HTTPS暗号化
  • パスワードを保存する方法
  • 秘密の質問を使う
  • 忘れたユーザー名/パスワード機能
  • クロスサイトリクエストフォージェリ(CSRF) を防ぐための nonces 使用
  • OpenID
  • 「覚えておく」チェックボックス
  • ユーザー名とパスワードのブラウザ自動補完
  • 秘密のURL(ダイジェストで保護された公開 URL
  • パスワード強度の確認
  • Eメール検証
  • そして、 フォームベースの認証 についてもっと ...

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

  • 役割と許可
  • HTTP基本認証

助けてください。

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

決定的な記事

資格情報を送信する

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

  • クライアントとサーバー間の接続が暗号化されていない場合、あなたがすることはすべて 、中間者攻撃に対して脆弱 です。 攻撃者は、受信したJavaScriptを置き換えてハッシュを解除したり、すべての資格情報をサーバーに送信したり、クライアントの応答を聞いたり、ユーザーを偽装したりする可能性があります。
  • サーバーで追加の冗長な作業を行わないと、サーバーが受信したハッシュ化されたパスワードの 安全性 低下 します。

SRP と呼ばれる別の安全な方法がありますが、それは特許を取得しています(それは 自由にライセンスさ れていますが)そして利用可能な良い実装はほとんどありません。

パスワードを保存する

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

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

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

セキュリティに関する質問

セキュリティに関する質問は安全ではありません - 使用しないでください。 どうして? セキュリティ上の問題が何であれ、パスワードの方が優れています。 第3部 を読む @ Jens Rolandで 秘密の質問を使う このwikiの 答え

セッションクッキー

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

クッキーはハイジャックされる可能性があります :それらはクライアントの他のマシンや他のコミュニケーションと同じくらい安全です。 それらはディスクから読み取られ、ネットワークトラフィックを傍受され、クロスサイトスクリプティング攻撃によって持ち上げられ、有害なDNSからフィッシングされ、クライアントは自分のクッキーを間違ったサーバーに送信します。 永続的なクッキーを送信しないでください。 Cookieは、クライアントセッションの終わり(ブラウザを閉じるかドメインから離れる)に期限切れになるはずです。

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

一方、銀行やクレジットカードなどの金融Webサイトには機密データしかないため、自動ログインやセキュリティの低いモードを許可しないでください。

外部リソース一覧


パートI:ログイン方法

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

HTTPSにするか、HTTPSにしないか

接続がすでに安全である(つまり、SSL / TLSを使用してHTTPS経由でトンネリングされている)場合を除き、ログインフォームの値はクリアテキストで送信されるため、ブラウザとWebサーバーの間を盗聴したユーザーは通過時にログインを読み取ることができます。スルー。 この種の盗聴は政府によって日常的に行われていますが、一般に、私たちはこれを言う以外に「所有されている」電線に対処しません。あなたが重要なものを保護しているなら、HTTPSを使用してください。

本質的に、ログイン中の盗聴/パケット盗聴から保護するための唯一の 実用的な 方法は、HTTPSまたは別の証明書ベースの暗号化方式(たとえば TLS )または実績のあるテスト済みのチャレンジ/レスポンス方式(たとえば Diffie-Hellman ベースのSRP) 他の方法は 、盗聴者によって 簡単に迂回 れる可能性があります

もちろん、少し実用的でないことを望んでいるのであれば、何らかの形の2要素認証スキーム(たとえば、Google Authenticatorアプリ、物理的な「冷戦スタイル」のコードブック、またはRSAキージェネレータドングル)を使用することもできます。 正しく適用されれば、これはセキュリティで保護されていない接続でも機能する可能性がありますが、開発者が2要素認証を実装してもSSLを実装しないとは考えにくいです。

独自のJavaScript暗号化/ハッシュをロールバックする(しない)

あなたのウェブサイトにSSL証明書を設定することのゼロではないコストと技術的な困難さを考えると、安全でないネットワーク上で平文ログインを渡すことを避けるために彼ら自身のブラウザ内ハッシュまたは暗号化スキームを転がしたくなる開発者がいます。

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

パスワードのハッシュ化はパスワードの 漏洩 に対して効果的であることは事実です 、リプレイ攻撃、Man-in-The-Middle攻撃/ハイジャック(攻撃者がセキュリティ 保護 されていないHTMLページに到達する前に数バイトを挿入できる場合)ブラウザ、彼らは単純にJavaScriptでハッシュをコメントアウトすることができます)、またはブルートフォース攻撃(あなたが攻撃者にユーザー名、salt、およびハッシュされたパスワードの両方を渡しているので)。

人類に対するキャプチャ

CAPTCHA は、攻撃の1つの特定のカテゴリを妨害することを意図しています。自動辞書/ブルートフォース試行錯誤、人間のオペレータなし。 これが本当の脅威であることに疑いの余地はありませんが、CAPTCHA、特に適切に設計されたサーバーサイドのログインスロットルスキームを必要としない、シームレスに対処する方法があります。

CAPTCHAの実装は似たようなものではありません。 それらはしばしば人間が解けるものではなく、それらのほとんどは実際にはボットに対して無効であり、それらはすべて安価な第三世界の労働に対して無効である( OWASP によると、現在の搾乳率は500テストあたり12ドルである)。一部の国では技術的に違法です( OWASP認証チートシートを 参照)。 CAPTCHAを使用する必要がある場合は、Googleの reCAPTCHA 使用します。これは定義上OCR-hardであるため(すでにOCRと誤分類された本のスキャンを使用しているため)、ユーザーフレンドリになるために非常に努力しています。

個人的には、私はCAPTCHASをいらいらさせ、ユーザーが何度もログインに失敗してスロットル遅延が最大になったときの最後の手段としてそれらを使う傾向があります。 これは許容できるほど十分にまれにしか起こらず、システム全体を強化します。

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

最近よく見られるハッキングやユーザーデータの漏洩の後は、ついにこれが一般的な知識になるかもしれませんが、言わなければなりません。パスワードを平文でデータベースに保存しないでください。 ユーザーデータベースは、定期的にSQLインジェクションによってハッキング、リーク、収集されています。また、プレーンテキストのままのパスワードを保存している場合は、ログインセキュリティのために即座にゲームオーバーとなります。

パスワードを保存できない場合、ログインフォームからPOSTされたログインとパスワードの組み合わせが正しいことをどのように確認しますか? 答えは、 キー導出関数 を使用してハッシュする こと です。 新しいユーザーが作成されたりパスワードが変更されたりするたびに、パスワードを取得してArgon2、bcrypt、scrypt、PBKDF2などのKDFを介して実行し、クリアテキストのパスワード( "correcthorsebatterystaple")をランダムな文字列に変換します。データベースに格納する方がはるかに安全です。 ログインを確認するには、入力したパスワードに対して同じハッシュ関数を実行します。今度はsaltを渡して、結果のハッシュ文字列をデータベースに格納されている値と比較します。 Argon2、bcrypt、およびscryptは、すでにハッシュを付けてsaltを保管しています。 詳細 article はsec.stackexchangeのこの article をチェックしてください。

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

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

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

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

セッションデータに慣れていない場合は、次のようになります。ランダムに生成された単一の文字列が有効期限が切れたCookieに格納され、サーバーに格納されているデータのコレクション(セッションデータ)を参照するために使用されます。 MVCフレームワークを使用している場合、これはすでに間違いなく処理されています。

可能であれば、ブラウザに送信されるときにセッションCookieにsecureおよびHTTP Onlyフラグが設定されていることを確認してください。 HttpOnlyフラグは、XSS攻撃によって読み取られるCookieに対する保護を提供します。 安全なフラグは、CookieがHTTPS経由でのみ返送されることを保証するため、ネットワーク盗聴攻撃から保護します。 クッキーの価値は予測できないはずです。 存在しないセッションを参照するcookieが提示された場合は、 セッションの固定 を防ぐためにその値を直ちに置き換える必要があります。

パートII:ログインしたままにする方法 - 悪名高い「Remember Me」チェックボックス

永続的なログインクッキー(「私を覚えている」機能)は危険な領域です。 一方では、ユーザーがそれらを処理する方法を理解している場合、それらは従来のログインとまったく同じくらい安全です。 一方で、それらは公共のコンピュータでそれらを使用してログアウトするのを忘れているかもしれない、そしてブラウザのクッキーが何であるか、またはそれらをどのように削除するのかわからないかもしれない不注意なユーザの手にある巨大なセキュリティリスクです。

個人的に、私は私が定期的に訪れるウェブサイトへの永続的なログインが好きですが、私はそれらを安全に扱う方法を知っています。 あなたのユーザが同じことを知っていることに前向きであれば、あなたはきれいな良心を持って永続的なログインを使うことができます。 そうでなければ - そうですね、あなたは自分のログイン資格情報に不注意なユーザーがハッキングされた場合に自分自身にそれをもたらしたという哲学に加入することができます。 私たちがユーザーの家に行って、顔を見せるようなポストイットのメモを、彼らがモニターの端に並んでいるパスワードで切り離すようなものでもありません。

もちろん、一部のシステムではアカウントをハッキングすることができません。 そのようなシステムでは、永続的なログインをすることを正当化できる方法はありません。

永続的なログインCookieを実装することを決定した場合は、次のようにします。

  1. まず、 Paragon Initiativeの このテーマ に関する記事 を少し読んでください。 あなたは正しい要素の束を正しく取得する必要があります、そして記事はそれぞれを説明する素晴らしい仕事をします。

  2. そして、最も一般的な落とし穴の1つを繰り返して言い表すには、自分の データベースに保存されたログインクッキー(トークン)を保管しないでください。 ログイントークンはPassword Equivalentであるため、攻撃者が自分のデータベースを手に入れた場合、平文のログインパスワードの組み合わせの場合と同様に、トークンを使用して任意のアカウントにログインすることができます。 したがって、永続的なログイントークンを保存するときにはハッシュを使用して https://security.stackexchange.com/a/63438/5002https://security.stackexchange.com/a/63438/5002 よると、この目的のために弱いハッシュで問題ありません)。

パートIII:秘密の質問を使う

「秘密の質問」を実行しないでください 。 「秘密の質問」機能はセキュリティのアンチパターンです。 MUST-READリストからリンク番号4の論文を読んでください。 それについては、Sarah Palinに聞いてもいいでしょう。 彼女の安全保障上の質問に対する答えが…「ワシラ高校」だったので、電子メールアカウントは前の大統領選挙運動の間にハッキングされました!

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

  • 母親の旧姓や好きなペットのような「標準的な」秘密の質問

  • 誰でも自分のブログ、LinkedInのプロフィール、または同様のものから持ち上げることができる簡単なトリビア

  • パスワードを推測するよりも回答が簡単な質問。 これは、まともなパスワードに対して、あなたが想像できるすべての質問です。

結論として、セキュリティ上の質問は本質的にそれらのすべての形式とバリエーションにおいて安全ではなく、そして何らかの理由で認証スキームに採用されるべきではありません。

セキュリティの問題が実際にも存在する真の理由は、再アクティブ化コードを取得するために電子メールにアクセスできないユーザーからのサポートコールを2、3回行うことでコストが節約されるためです。 これはセキュリティとSarah Palinの評判を犠牲にしています。 価値がある? おそらくそうではありません。

第4部:パスワード機能を忘れた

忘れてしまった、または紛失したユーザーパスワードを処理 するためにセキュリティ上の質問 使用し てはいけ ない 理由はすでに述べました。 また、ユーザーに実際のパスワードを電子メールで送信しないでください。 この分野で避けるべきもう2つの最も一般的な落とし穴があります。

  1. 忘れてしまったパスワードを自動生成された強力なパスワードに リセット しないでください。このようなパスワードは覚えにくいことで有名です。つまり、ユーザーはパスワードを変更するか書き留める必要があります。 新しいパスワードを設定する代わりに、ただちに新しいパスワードを選択するようにしてください - とにかくやりたいことです。 (これに対する例外は、パスワードを保存/管理するためにユーザーがパスワードマネージャを普遍的に使用している場合、それを書き留めないと覚えられないのが普通です)。

  2. データベース内の失われたパスワードコード/トークンを常にハッシュします。 また 、このコードはパスワード相当物の別の例です。そのため、攻撃者があなたのデータベースを手に入れた場合に備えてハッシュ化しなければなりません。 紛失したパスワードコードが要求されたら、平文のコードをユーザーのメールアドレスに送信し、それをハッシュして、データベースに保存してください。そして 、オリジナル 捨て ます。 パスワードや永続的なログイントークンと同じです。

最後の注意: 'パスワードを失ったコード'を入力するためのあなたのインターフェースがあなたのログインフォーム自体と少なくとも同じくらい安全であることを常に確認してください、さもなければ攻撃者は代わりにアクセスを得るためにこれを使うでしょう。 非常に長い 'パスワード紛失コード'(たとえば、大文字と小文字が区別される16文字の英数字)を生成することをお勧めします。ただし、ログインフォーム自体に対して行うのと同じスロットルスキームを追加することを検討してください。

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

最初に、現実性チェックのためにこの小さな記事を読みたいと思うでしょう: 500の最も一般的なパスワード

さて、そのリストは これまでのところどこの システムで 最も一般的なパスワードの 標準的な リストではないかもしれませんが、施行されたポリシーがない場合、パスワードを選択する人々の貧弱さを示す良い指標です。 さらに、最近盗まれたパスワードの公に利用可能な分析と比較すると、このリストは自宅に非常に近いように見えます。

そのため、最低限のパスワード強度要件はなく、2%のユーザーが最も一般的なパスワードのトップ20を使用しています。 意味:攻撃者が20回だけ攻撃を試みると、あなたのウェブサイトの50のアカウントに1つが割れてしまう可能性があります。

これを防ぐには、パスワードのエントロピーを計算してからしきい値を適用する必要があります。 米国標準技術局(NIST)の Special Publication 800-63に は、非常に優れた提案があります。 つまり、辞書とキーボードレイアウトの分析(たとえば、 'qwertyuiop'は悪いパスワードです)と組み合わせると、18ビットのエントロピーレベルで、 選択が不十分なパスワードの99%を拒否する ことができ ます 。 単純にパスワードの強度を計算し て視覚的強度のメーター をユーザーに表示するのは良い方法ですが、不十分です。 それが強制されない限り、多くのユーザーはそれを無視するでしょう。

そして、エントロピーの高いパスワードの使いやすさを爽快に感じるために、Randall Munroeの Password Strength xkcd を強くお勧めします。

Troy Huntの Have I Been Pwned API を利用して、公共のデータ侵害で侵害されたパスワードに対してユーザーのパスワードをチェックします。

第6部:はるかに多くの場合 - または:Rapid Fireによるログイン試行の防止

まず、数字を見てください。 パスワード回復の速さ - あなたのパスワードはいつまで立ち上がるのでしょうか

そのリンク内のテーブルを調べる時間がない場合は、それらのリストを次に示します。

  1. あなたがそろばんでそれを解読していても、弱いパスワードを解読するのは 事実上時間 がかかり ません

  2. 大文字と小文字が区別されない 場合、英数字の9文字のパスワードを解読するのに 実質的 に時間がかかり ませ ん。

  3. 8文字未満の長さで あれば、複雑な記号と文字と数字の大文字と小文字のパスワードを解読するのに 実質的 に時間がかかり ません (デスクトップPCは、問題なく最大7文字までキースペース全体を検索できます)。数日あるいは数時間)

  4. ただし、 1秒間に1回の試行に制限されている場合は 、6文字のパスワードでさえも解読するのに非常に長い時間がかかります

それでは、これらの数字から何を学ぶことができるでしょうか。 非常に多くのことが言えますが、最も重要な部分に集中することができます。大量の連射による連続ログイン試行(つまり、 ブルートフォース 攻撃)を防ぐという事実は、それほど難しくありません。 しかし、それを 正しく 防止することは見かけほど簡単ではありません。

一般的に言えば、ブルートフォース攻撃 (および辞書攻撃) に対して効果的な3つの選択肢があります 。ただし、既に強力なパスワードポリシーを採用しているため、これらは問題にならないはずです

  • N回の試みが失敗した後に CAPTCHAを 提示する(地獄として迷惑で、しばしば効果がない - しかし、ここで私は繰り返します)

  • 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人のユーザーを選んで5万人の最も一般的なパスワードを試すのではなく(私たちの制限のためにできません)、最も一般的なパスワードを選び、5万人のユーザーに対して試してみます。 そうすれば、CAPTCHAやログイン調整などの最大試行回数を回避するだけでなく、最も一般的なパスワードの1が49.995よりはるかに高いため、成功の可能性も高まります。

  • 各ユーザーアカウントのログイン要求を30秒間隔で間隔を空けてレーダーの下に潜入する

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

抽象すぎる? 言い換えてみましょう:

あなたのサイトが過去3ヶ月間に1日当たり平均120回の悪いログインをしたとしましょう。 それを使用して(移動平均)、あなたのシステムはグローバル制限をその3倍に設定するかもしれません - すなわち。 24時間で360回失敗しました。 その後、1日以内にすべてのアカウントで失敗した試行の合計数がその数を超えると(またはさらに高速化の速度を監視して計算されたしきい値で起動すると)、システム全体のログイン調整が有効になります。 (それでも、クッキーログインやバックアップCAPTCHAログインを除く)。

私はまた、分散ブルートフォース攻撃 を防ぐためのトリッキーなピットファルを回避する方法について、より詳細な 質問と 本当に良い議論を 掲載しました。

第VIII部:2要素認証と認証プロバイダ

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

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

Web認証についての必ずお読みください

  1. OWASP認証ガイド / OWASP認証チートシート
  2. Web上でのクライアント認証に関する注意事項(読みにくいMITの研究論文)
  3. ウィキペディア:HTTP cookie
  4. 代替認証のための個人的な知識の質問:フェイスブック時代のセキュリティの質問(非常に読みやすいBerkeleyの研究論文)

徹底的な防御に基づいて、私が使用した提案を1つ追加したいと思います。 通常のユーザーと同じ認証および認証システムを管理者用に持つ必要はありません。 高い権限を付与する要求に対して、別のURLに別のログインフォームを作成して別のコードを実行することができます。 これは、通常のユーザーにとって非常に面倒な選択となる可能性があります。 私が使ったのは、管理者アクセスのためにログインURLを実際にスクランブルし、新しいURLを管理者に電子メールで送ることです。 あなたの新しいURLは任意に難しい(非常に長いランダムな文字列)可能性があるので、どんなブルートフォース攻撃もすぐにやめますが、あなたの管理者ユーザの不便さだけが彼らの電子メールのリンクをたどっています。 攻撃者はPOSTをどこに行けばいいのかわかりません。



私はそれが答えとしてあるいはコメントとしてこれに答えるのが最善であったかどうかわからない。 私は最初の選択肢を選びました。

Poingののについて PART IV:パスワードを忘れた場合の機能 最初の回答では、私は攻撃のタイミングについてのポイントになるだろう。

[ パスワード 記憶する] フォームで、攻撃者は電子メールの全リストを確認し、システムに登録されているものを検出する可能性があります(下記のリンクを参照)。

忘れられたパスワードフォームに関して、私はそれがある遅延機能を用いて成功したクエリと失敗したクエリの間の時間を等しくすることは良い考えであると付け加えます。

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


私はちょうど私がちょうどうまく働いていることがわかったというこの解決策を共有すると思った。

私はそれを ダミーフィールド と呼んでい ます。

要するに、あなたはこれを自分の中に挿入 <form> し、検証時に空になるようにチェック するだけです 。

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

トリックは、ボットがデータを必須フィールドに挿入する必要があると考えることに騙されることです。そのため、入力を「電子メール」と名付けました。 使用しているemailというフィールドがすでにある場合は、ダミーフィールドに "company"、 "phone"、または "emailaddress"などの別の名前を付けてみてください。 あなたが必要としていないことを知っているものを選び、人々がWebフォームに記入するのに論理的だと通常思うもののように思えるものを選んでください。 input CSSまたはJavaScript / jQueryを使用し て フィールドを 非表示にしましょう - 自分に最適なものは何でも - 入力 をに 設定 しない でください。 type hidden

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

例:

人間の場合: ユーザーはダミーフィールド(私の場合は "email")を見ず、それを埋めようとしません。 そのため、フォームが送信された時点では、ダミーフィールドの値はまだ空のはずです。

ボットの場合: ボットは、型が text 名前と名前 email (またはあなたがそれを呼び出したものは何でも)で あるフィールドを見 て、適切なデータでそれを論理的に満たすのを試みます。 あなたが何らかの素晴らしいCSSで入力フォームをスタイルしていても、ウェブ開発者はそれをいつもやります。 ダミーフィールドの値がどのようなものであっても、それが 0 文字 よりも大きい限り問題ありません 。

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

これはログイン/認証フォームでもうまく使えると思います。

警告 :もちろんこの方法は100%確実というわけではありません。 ボットはスタイルが display:none 適用され た入力フィールドを無視するようにプログラムすることができます 。 また、(ほとんどのブラウザに内蔵されているように)何らかのフォームの自動補完を使用して、すべてのフォームフィールドを自動入力する人たちについて考える必要があります。 彼らは同様にダミーフィールドを拾うかもしれません。

ダミーフィールドを表示されているが画面の境界の外側に置くことで、これを少し変えることもできますが、これはまったくあなた次第です。

クリエイティブに!



まず、この答えはこの正確な質問には最適ではないという強い警告です。 それは間違いなく最高の答えではありません!

私は先に進み、将来のより良い認証へのアプローチへのアップグレードパスを見つけるという精神の中で、Mozillaが提案した BrowserID (あるいはもっと正確には Verified Email Protocol )について言及します。

このように要約します。

  1. Mozillaは、この問題に対する良い解決策を見つけることとうまく調和する values を持つ非営利団体です。
  2. 今日の現実は、ほとんどのWebサイトがフォームベースの認証を使用しているということです。
  3. フォームベースの認証には大きな欠点があり、これは phishing 危険性が高まります。 ユーザーは、ユーザーエージェント(ブラウザ)によって管理されている領域ではなく、リモートエンティティによって管理されている領域に機密情報を入力するよう求められます。
  4. ブラウザは暗黙のうちに信頼されているので(ユーザエージェントの全体的な考えはユーザに代わって行動することです)、それらはこの状況を改善するのを助けることができます。
  5. ここでの進歩を遅らせる主な力は、 展開のデッドロック です。 解決策は、それ自体でいくつかの追加的な利益をもたらすステップに分解されなければならない。
  6. インターネットインフラストラクチャに組み込まれているIDを表現するための最も簡単な分散型の方法は、ドメイン名です。
  7. IDを表現する第2レベルとして、各ドメインは独自のアカウントセットを管理します。
  8. 「account @ domain」という形式は簡潔で、幅広いプロトコルとURIスキームによってサポートされています。 そのような識別子は、もちろん、Eメールアドレスとして最も広く認識されています。
  9. 電子メールプロバイダは、すでにオンラインで事実上の主要なアイデンティティプロバイダです。 現在のパスワードリセットフローでは、通常、そのアカウントに関連付けられた電子メールアドレスを管理していることが証明できれば、そのアカウントを管理できます。
  10. 検証済み電子メールプロトコルは、公開鍵暗号に基づいて、ドメインAにアカウントを持っていることをドメインBに証明するプロセスを合理化するための安全な方法を提供するために提案されました。
  11. 検証済み電子メールプロトコルをサポートしていないブラウザ(現在すべて)では、MozillaはクライアントサイドのJavaScriptコードでプロトコルを実装するシムを提供しています。
  12. 確認済みEメールプロトコルをサポートしないEメールサービスの場合、このプロトコルを使用すると、第三者が信頼された仲介者として機能し、ユーザーのアカウントの所有権を確認したと主張できます。 そのような第三者を多数所有することは望ましくありません。 この機能はアップグレードパスを許可することのみを目的としており、電子メールサービスがこれらのアサーション自体を提供することがはるかに推奨されています。
  13. Mozillaは、そのような信頼できる第三者のように行動するための独自のサービスを提供しています。 検証済みEメールプロトコルを実装しているサービスプロバイダ(つまり信頼者)は、Mozillaの主張を信頼するかどうかを選択できます。 Mozillaのサービスは、確認リンク付きの電子メールを送信する従来の方法を使用してユーザーのアカウント所有権を確認します。
  14. サービスプロバイダーは、もちろん、彼らが提供したいかもしれない認証の他の方法に加えてオプションとしてこのプロトコルを提供するかもしれません。
  15. ここで求められている大きなユーザーインターフェースの利点は「IDセレクター」です。 ユーザーがサイトにアクセスして認証を選択すると、ユーザーのサイトを識別するために使用される可能性のある一連の電子メールアドレス( "個人用"、 "勤務先"、 "政治活動"など)がブラウザに表示されます。
  16. この取り組みの一環として求められているもう1つの大きなユーザーインターフェースの利点は 、ブラウザがユーザーのセッション( 現在主にサインインしている ユーザー)についての情報を得るのに役立つためです
  17. このシステムは分散されているため、Facebook、Twitter、Googleなどの主要サイトへのロックインが回避されます。

これは厳密には「Webサイトのフォームベース認証」ではありません。 しかし、現在の標準のフォームベース認証から、より安全なブラウザサポート認証への移行を目指しています。





article