タスクは次のとおりです。最小限の資金を使用して、ユーザーのアカウントに対する単純なパスワードの選択からユーザーのアカウントの保護を強化します。
資金の最低額はいくらですか？ IPアドレスとユーザーエージェントによってブロックするために参照テーブルを使用しません。 システムへの追加の要求を使用しないでください。許可システムに不要なサイクルを散らかさないでください。
そして、完全に魔法の要件を満たすために-たとえボットが必要なログインとパスワードを入力したとしても...それを入力させず、実際のユーザーを入れます。
これはできますか？ 理論的には、もちろんそうではありません。 しかし、実際には、プライベートで、特定の条件下で、判明したように、それは非常に可能です。
詳細については、katの下に招待します。
したがって、ユーザーのログインが「test」で、パスワードが「12345」であるとします。 悪意のあるボットは、生成されたパスワードの辞書を接続し、毎秒700パスワードの速度で動作する準備ができています。 彼は、ユーザーのログインが「テスト」であることを知っています。 状況はひどいです。パスワード「12345」は非常に短時間で計算されます。 一方、ユーザーはサイトを開き、ログインとパスワードをログインWebフォームに入力し始めました。
誰も作業を開始せず、災害が発生するまで、認証システムに変更を加えましょう。
魔法は3番目の変数にあり、ログインとパスワードのペアに「接着」する必要があります。 私は彼女をタッチと呼びました。
誰かが受け取るたびに（注意： receiveですが 、要求しません！）ログインパスワード、ユーザー "test"の "touch"日付は現在の日時に更新されます：
login/password/touch: 'test', '12345', '2014-12-13 14:00:00'.
ボットが最初の反復を開始し、「2014-12-13 15:00:00」のログイン「テスト」にパスワード「1」を提供するとします。 login_checkコントローラーは機能しています。これは、データベースからログインとパスワードのペアを読み取ります。 これらの2秒はどこから来たのですか？！ これはさらに進んでいきます。
このようなログインとパスワードのペアがあります。 最後の「タッチ」と現在の時刻の差は1時間です。 したがって、レコードはリクエストに正常に返されます。
最初に、ログインとパスワードのペアが一致し、login_checkは「test / 12345」が「test / 1」と等しくないと結論付けます。 コントローラは「認証エラー」を返します。 そして、ユーザー「テスト」の「タッチ」日付が現在の「2014-12-13 15:00:00」に更新されます。
ボットは次の反復に進みます：パスワード「2」を試行します。
ボットの速度はマイクロ秒単位で測定されます。 彼はすぐにログインを試みます：「2014-12-13 15:00:00」。
そして、ここで私たちのアルゴリズムが有効になります-「タッチ」パラメータの条件はもはや満たされていません。 まだ2秒が経過していません。 失敗。
ロジックによって変更されたlogin_checkコントローラーは、ログインとパスワードのペアを受信できません。
レコードは存在しますが、その「タッチ」日付はまだ「新鮮」です。
そして、彼女はすでにサンプルから外れています。 そして、そのようなログインとパスワードのペアがないため、コントローラーは認証エラーボットに応答します。
ボットはあきらめずに選択を続行し、最終的に正しいパスワード「12345」に到達します。
成功を返すのは現在の試みである可能性は非常に小さいです。 ログイン試行ごとに1/700！ つまり、以前は1対1でしたが、現在は1対700です。 ボットが高速であるほど、失敗する可能性が高くなります。
その結果、パスワードのごく一部のみが真に検証されます。 残りは、たとえそれらが真であったとしても、偽陽性を受け取ります。
そして、ユーザーは何ですか？
ユーザーから始めましょう。 ユーザーは、ボットとは異なり、キーボードを介して手でデータをWebフォームに入力し、視覚器官でモニターを見ます。 また、アルゴリズム機能の柔軟性はボットよりもはるかに優れています。 実際、ユーザーは何らかの形で人工知能です。 そのため、ロジックの一部はすでにその中にあります。 そしてそれを使用します！
ユーザーが認証エラーを確認すると、多くの場合、パスワードを再度書き換えます。 彼が自分でパスワードを入力したとしても。 パスワードがpassword-managerから自動的に設定される場合でも。 これは、単純なパスワード保護システムを適用する前でも行いました。
はい、2秒ほど話すことを約束しました。 私が言う：
ユーザーがデータ調整操作を実行して次のログイン試行を行う最適な時間は2秒です。 この2秒で、ユーザーは完全にフィットします。 ユーザーが期限に間に合わない場合、ユーザーはいつでも再試行できます。この時間中にタッチ操作はおそらくキャンセルされます。
結論として。
ボットが2秒の遅延を発見した場合はどうなりますか？ テストデータを適用すると、ボットの有効性が低下することを意味します。1400回ではなく1回だけパスワードの推測を試みます。
PSシステムはすでに1つのプロジェクトに実装されており、これまでシステムへのアクセスに問題のある単一のチケットを作成していないため、批判を聞きたいと思います。
事前に感謝します。