RFC 4226を使用して、自分のWebサイトにワンタイムパスワードシステムを実装しています。このパスワードは、SMSを介してモバイルデバイスに送信されます。ユーザーはモバイルデバイスでのみパスワードを受け取ることができ、パスワードは15分後に期限切れになります。
ユーザーは、通常使用される標準の英数字の「マスターパスワード」も持っています。3つの失敗のロックアウトワークフローを実装しました。このロックアウトは15分間続きます。
私の質問は、セキュリティの観点から、「マスターパスワード」のみをロックアウトすることは許容されますか？ワンタイムパスワード機能を使用する場合、ユーザーにロックアウトポリシーの回避を許可する必要がありますか？どんな種類のセキュリティホールを開いていますか？
それはあなたの質問に対する正確な答えではありませんが、このようなシステムを構築するときは、2つのバットヘッドのたびにユーザビリティがセキュリティよりも優先されることを覚えておく必要があります。エンドユーザーのセキュリティポリシーを厳しくするほど、エンドユーザーは仕事を遂行するための安全でない回避策を考え出すようになります。
シュナイアーは、ここで要約できるよりはましだと言ったが、そこで彼のものを読むことをお勧めする。
私はあなたの視点のセキュリティと使いやすさを理解しています。 静的なパスワードロックアウトメカニズムを実装することを提案します。これはほとんどすべてのWebサイトのデファクトスタンダードになっています。
ここでは本当によく説明されているので、もう一度入力する必要はありません：
今日のパスワードロックアウトメカニズムのほとんどは静的です。つまり、特定の回数の誤ったパスワードの試行後にユーザーをロックアウトします。この機能は、ログイン機能に対するブルートフォース攻撃を防ぐために実装されています。この機能は想定どおりに機能しますが、独自の欠点もあります。セキュリティの観点から、この機能は悪意のあるユーザーによって悪用され、ユーザー名（英数字ではないにしてもほとんどがアルファベット）のすべての可能な順列と組み合わせでスクリプトを作成することにより、ほとんどまたはすべてのユーザーをロックする可能性があります。サービス拒否で 。
使いやすさの観点から、ユーザーアカウントをロックする前に許可される試行回数については常に議論があります。ほとんどのWebサイトでは3回の試行が許可されていますが、一部（ごく少数）では5回または場合によっては7回の試行が許可されています。
Intellipassは、この機能のセキュリティとユーザビリティの側面の間のギャップを埋めようとします。Intellipassは、ユーザーのすべてのログイン試行を保存することにより、ユーザーの過去の行動をインテリジェントに理解し、それに応じて行動することができます。例：ユーザーが毎回自分自身をロックアウトすると、Intellipassは試行回数を3から5または5から7に動的に増やします。一方、ユーザーがログインを試みるたびに1回目または2回目にログインした場合過去に、何らかの理由で今回3回試行したため、Intellipassは自動的に試行回数を7から5または5から3に減らします。Intellipassの2番目のコンポーネントは、ランダムなキャプチャをスローするか、間に時間遅延を挿入します。ログインは、自動化された攻撃を防止しようとします。