システムのログイン画面にrecaptchaを導入しました。
私の目標はすべて、辞書/ボット攻撃やその他の種類のセキュリティなどのセキュリティに関するものでした。
ユーザーは今それを嫌いです、それを理解しない人もいました。私はそれを削除しなければなりませんでした。
私が見回すと、ログイン画面にそれが表示されるシステムは多くありません。ほとんどの場合、お問い合わせのような他のフォームや、投稿したいときにStack Exchangeのように表示されます。
それをログイン画面に表示するのは良い考えですか?
いくつかの大規模なシステムで私が見た方法は、連続して失敗したログイン試行の後にのみキャプチャを要求することです(つまり、有効なログイン後にカウントをリセットします)。自動化されたクラッキングが心配な場合は、20、50、100回の試行が失敗するなど、大量の失敗にキャプチャを設定できます。正当なユーザーにはほとんどキャプチャが表示されませんが、自動攻撃によってキャプチャされます。
この複雑さを追加する価値はありますか?セキュリティとUXはトレードオフです。リスクプロファイルの正しいトレードオフを見つける必要があります。
ログイン画面のキャプチャは意味がありません。ユーザーがそれを嫌っていたのも当然です。フォームのキャプチャフィールドの目的は、ボットによってフィールドが送信されないようにすることです。ボットは有効な認証情報を持っていないため、ログイン画面からログインできないようにする必要があります。ボットが有効な資格情報を推測できる場合は、パスワードの強度を上げる必要があります。
ユーザーは今それを嫌いです、それを理解しない人もいました。私はそれを削除しなければなりませんでした。
ここで、ユーザビリティとセキュリティのどちらかを決定する必要があります。ログインページにキャプチャを付けることは便利ですが、信じられないほどユーザーフレンドリーではありません。
私の最善のヒントは、データベースへの無効なログイン試行をすべてログに記録し、ユーザーを認証する前に、そのIPが過去1時間以内にX回ログインを試みたかどうかを確認することです。
また、すべてのログインページに何らかの形式のクロスサイトリクエストフォージェリシステムを追加することもできます。つまり、ログインを試みるたびに、トークンを含む非表示のフィールドが生成されます。つまり、攻撃者はログインを試行するために2つの要求を行う必要があります。
これを攻撃する別の方法は、「ハニーポット」をインストールすることです。これは、ログインフィールド(ユーザー名、パスワード)とともにHTMLに含まれている通常の入力フィールドですが、この追加フィールドはCSSを使用して非表示になっています。
通常、ボットはHTMLに表示されるすべてのフィールドにテキストを入力しようとするため、PHPでは、ハニーポットフィールドが空でないかどうかを確認しました-そのIPを禁止します。
(これは、ジャンプするときに日付を更新する小さな管理機能を備えたスカイダイビングクラブのホームページ用でした。デリケートなアプリケーションにはお勧めしません)
CaptchaまたはReCaptchaを追加することは解決策ではなく、ハッカーとユーザーの両方にとっての単なる障害です。
私は眼鏡をかけていると非常に良い視力があり、時には画像のテキストをほとんど理解できません。彼らのビジョンを否定している誰かが激怒するだろうと私は想像します。
実装するものはすべて特定の目的を持つ必要があります。そうしないと、うんちが詰まったパイを空に投げてしまうだけで、これらのパイは最終的にユーザーに直接届きます。
ここに考えられるいくつかの食べ物があります:
1
問題
自動ブルートフォース攻撃によりユーザーアカウントがハッキングされる
解決
ログインに3回失敗すると、アカウントがロックされるようになりました
2
問題
すべてのユーザーアカウントが明らかになり、ボットがすべてのアカウントをブルートフォースにしようとしている
ログインに3回失敗したため、すべてのアカウントが数秒以内にロックされます
ソリューション?豊富ですが、このステップに到達する必要さえありましたか?これは現在問題ですか?
あなたのキャプチャが何を達成しようとしているのかについて少し考えてください。ここに私が考えることができる目標があります:
これは、おそらくユーザーをより幸せにする方法です。
コンピューターが(Bobとして)正常にログインした場合は、そのコンピューターにCookieを設定して、Capchaを必要とせずにコンピューターがBobのアカウントに5回無料でログインできることをサーバーが認識できるようにします。
ログインしようとしているコンピューターがBobの最後の既知のIPからのものである場合は、そのIPに、CAPCHAを必要とせずにBobのアカウントにログインするための5回の無料試行を与えます。
ここでの考え方は、大量のパスワードの推測は通常、正当にアカウントにログインしていないコンピューターまたはIPから発生するということです。
これは、アカウントまたはipsにいくつかの「自由な試行」を与える他の回答からのアイデアと組み合わせることによっておそらく改善することができます。
CAPTCHAシステムは、自動ボットと実際のユーザーを区別するためにあります。残念ながら、あなたが指摘したように、それらは(特に障害のあるユーザーにとって)あまり便利ではありません。
それが「良いアイデア」であるかどうかは、実際にはユースケースに依存しますが、ユーザーログインではあまり効率的ではありません。これらは、パスワード推測攻撃を防ぐのにあまり役立ちません。アプリケーションにレートリミッターを実装する方が便利です。 [〜#〜] totp [〜#〜] PINを実装している間、ユーザーはより良いセキュリティを提供します。
サーバーのリソースをクライアントに費やす場合や、これらのリソースが限られている場合は、クライアントから何らかの形で「作業の証明」を取得することは非常に良い考えです。このようなクエリの典型的な使用例は、匿名ユーザーの作業を実行するシステムです(たとえば、WebベースのWHOISアプリケーションは、それを使用してリソースを保持できます)。
現在のボットのほとんどは、deathbycaptchaアカウントを持っているため、10回または100回の試行が失敗した後にキャプチャを追加しても役に立たず、dbcのAPIは本当に使いやすいです。ですから、キャプチャを毎秒表示するのは良いことだと思います。
ブルートフォース攻撃を防ぐには、次のことをお勧めします。
1)パスワードが十分に複雑であることを確認します。多くのユーザーが名前などの非常に単純なパスワードを使用する可能性がある場合、パスワードは8文字以上で、数字、文字、大文字と小文字が混在している必要があります。
2)ログインに5回失敗した後のIPのロックアウト。
パスワード回復画面にキャプチャフィールドを追加する価値があるかもしれません。それがどのように機能するかをユーザーに説明するのに十分なテキストを含めるようにしてください。