SSNを含むWebベースのアプリケーションフォームの参照コードベースの認証を使用した潜在的なリスク
現在、ユーザーがSSNおよびその他の識別可能な情報を入力する必要があるWebベースの会員申請フォームを作成しています。会員申請の要件の一部は、ユーザーが申請を再開し、フォームフィールドに既に入力した情報を事前に入力できるようにすることです。利害関係者は、ユーザー名とパスワードをユーザーに負担させたくない。次の代替認証方法を考え出しました。
ユーザーはアプリケーションを起動し、ボタンをクリックしてアプリケーションを「保存」できます。 [保存]をクリックすると、メールが送信され、6文字の英数字の参照コードを受け取ります。
アプリケーションを「再開」するには、ユーザーは6文字の参照コードと、生年月日、姓、SSNの最後の4桁を入力する必要があります。
私の質問は、1から10のスケールで、ユーザーがこの方法で認証できるようにするためのリスク要因は何ですか？ブルートフォースがWebベースのフォームを攻撃した場合、誰かが他の誰かのアプリケーションをロードできる確率はどのくらいですか。リスクスケールが高い場合は、このフォームのセキュリティを強化するために何ができますか。パスワードシステムを実装することはできません。参照コードは、誰かが電話でカスタマーサービスエージェントにコードを提示できるほど単純である必要があります。
追加のセキュリティ：
- 参照コードは、使用しない場合は1週間後に期限切れになります。
- 参照コードは、フォームが送信されると期限切れになります。
- WebアプリケーションはHTTPSおよびTLSを使用してデータを転送します。
1週間に約200のアプリケーションが送信されるため、1週間で最大約200のアプリケーションにアクティブな参照コードが含まれる可能性があります。
まず、フォームが長すぎて、ユーザーに欠落している詳細を入力させるだけでなく、実際にこれをすべて実装することが理にかなっているのでしょうか。
第二に、あなたは国については言及しません。私はあなたが米国市民をターゲットにしていると仮定します。
さらに、SSNがすべての人にあるわけではないので、さらに、SSNがない人はSSNに登録できないと仮定します。
あなたの必要条件は
次に、ユーザーは6文字の参照コードと、生年月日、姓、SSNの最後の4桁を入力する必要があります。
私はこれが出てきた方法が本当に好きではありません。どうやら、誰かが認証方法としてそれを思いついたので、システムの後で実際に認証を設計するのではなく、ニーズに対して十分に安全かどうかを確認する必要があります。
2010年の米国勢調査によると、 8,745,538 のうち 2,442,977人の姓がスミス であり、通常、毎週1人から2人（1 、58）は、プラットフォームの姓です。
姓だけを使用するのは明らかに悪い考えです。しかし、混合されている他のアイテムはどうですか？生年月日はおおよそ1年を通して分散され（これは leaplings協会 ！のメンバーシップアプリケーションでない限り）、SSNはそれをさらに配布するようです。悲しいかな、それは長い間知られています 社会保障番号はランダムではありません 、そして生年月日に基づいてSSNを予測することが可能かもしれないので、セキュリティ対策として、あなたは当てにしてはいけないと思いますそれらの4桁。
いずれにせよ、これらはすべて公開データであり、フルネームを使用している場合でも、本質的に欠陥のある識別方法であり、 Lisa Davies または Jessica Ishak 。ホワイトペーパー 名前/生年月日の組み合わせを識別子とする問題 は、8.3％の人は名前とDOBで一意に識別できないと結論付けています。
ただし、6文字の参照コードである、ここでプレイする余分なエースがあります。おそらく、同じ名前と生年月日を持つ2人が異なる参照コードを受け取るように生成するでしょう。好ましくは、異なる人々に異なる参照コードを与えること。これは私たちが信頼できる最強の作品です。
これらの参照コードは、シーケンシャルコードではなく、ランダムな方法で生成する必要があります。不快と見なされる単語を生成することを回避するために母音を含めなかったと仮定し、さらには数字を無視したとしても、216 = 85,766,121の組み合わせ。各ユーザーに一意のコードを与え、エントリがまばらであるため有効なものを推測するのが難しいほど十分な量（十分にランダムなジェネレータを使用している場合）。
したがって、指定された参照コードのみを使用して適切なジョブを実行できます。ただし、再開フォームではブルートフォース保護を考慮に入れる必要があります。これにより、たとえば、ユーザーは他の指定されたデータの代わりにキャプチャを入力するよう求められ、無効なコードの再開を複数回試行する際の制限を含めることができます。
まず、SSNデータを保存すると、システムが法的責任の非常に特別な定義になります。絶対に必要でない場合、これを行うことを2度考えてください。
「...誰かがWebベースのフォームをブルートフォース攻撃した場合、誰かが他の人のアプリケーションをロードできる可能性はどの程度ですか...」
確率の数値だけでアプローチがかなり確実になり、試行がレート制限されるため、ブルートフォースは起こりそうにありません[〜＃〜] but [〜＃〜]！
より可能性の高いシナリオは、実装の詳細から派生しています。
継続認証情報を提供する代わりに、ユーザーは同じSSNで新しいフォームを開始するだけでどうなりますか？
同じSSNを持つ複数の人はどうですか？
ログイン検証後、SSNはクライアント側で利用できますか？もしそうなら、それがストリームで変更された場合はどうなりますか？フォーム識別子はどうですか？それはSSNか何かですか？それがストリームで変更された場合はどうなりますか？
クライアント情報がログイン時にのみ検証される場合、ストリームデータのスパイダリングは、レート制限された検証後に可能になる可能性があります。
要するに、あなたのログオン継続技術はおそらく弱いリンクではありません。もちろん、私が確実に知ることができる方法はありませんが、考慮すべき例にすぎません。
幸運を！
まず、SSNは識別情報としては基本的に役に立たないことを指摘することが重要だと思います。それらは秘密のコードではありません。それらを含むすべてのデータ侵害は別として、それらは長い間ランダムではない方法で生成されました。 SSNを知ることはIDの証明であるという考えはかなり固いものです。あなたの主な問題は、最初の登録にあると思います。
ただし、これはすべて公開情報であるため、個人情報は攻撃者に知られているものとします。したがって、唯一の真のセキュリティは6桁のコードです。あなたが良い安全なPRNGを持っていると仮定すると、100万の異なる可能な数があります。他のものの代わりに、これは間違いなく総当たりです。
ブルートフォース攻撃を防ぐための最も簡単なアプローチは、誰かが同じアカウントに短時間で多くのログインを試みることを防ぐことです。たとえば、試行が失敗するたびに5秒の遅延を強制し、失敗するたびにそれを2倍にすることができます。
「後で戻る」オプションを持つ長く複雑なフォームの実践は珍しいことではありません。たとえば、内国歳入です。
あなたはパスワードやユーザー名を申請者に負担させたくないと言っていますが、私はすでにプロキシによってパスワード/ユーザー名になるのに十分なデータを持っていると思います：メールアドレス、名前、DOB、SSN、6桁のパスワードをキャプチャします/参照。識別、認証、承認を分離するのに役立つかもしれません。電子メールアドレス、名前、DOB、完全なSSNをキャプチャしている間に、それらが正しいことをどのようにして知ることができますか？これらをサードパーティのデータベースと照合して確認している場合は、そのデータを使用して正確さを確認できます。おそらく、実際に生年月日と完全なSSNが必要であるためです。そのデータはすべて識別に関するものであり、関係者だけが、アイデンティティについてどの程度確実になりたいかを知っています。
人が去り、彼らに戻って彼らにパスワードを覚えておいて負担をかけないようにしたいが、彼らが使用した生年月日、名前の変形、SSNを持っているかどうか、最後に6つを覚えておく必要がある-桁パスワードではありません。また、アクセスできる有効なメールアドレスを入力する必要があります。
6桁のパスワードではないことを書き留めることが要件である場合は、6桁で入力する必要があります。要件が特にコードを書き留めることができない場合は、リンクを使用できます。とにかくこれをメールで送信しています。 GUIDトークンをURLの形式で入力して、ユーザーがURLをコピーアンドペーストするだけでよいようにします。そのURL GUIDはX日間有効で、フォームが完了すると、フォームは無効になります。最終的には、GoogleドキュメントのURLと同様のURLになります。利害関係者はこの概念を理解し、「Googleにとって十分に安全であれば、私たちにとって十分に安全である」と考える可能性があります。 ;利害関係者の専門知識のレベルによって異なります。ご存知のように、多くのサイトはこの方法を使用してパスワードをリセットします。ユーザーや利害関係者は、これが一部のREST APIの仕組みであることを知らない可能性があります。ヘッダーで送信されたAPIキーがあり、SSH証明書ベースの認証でさえ、本当に古くて長い長いパスワードだけです。
このスキームの利点は、顧客にとって簡単なことです。 GUIDは、TLSを使用しているため、ログに保存されず、プロキシによって表示されません。GUIDには、多くのエントロピーがあり、衝突の可能性はほとんどありません。 。それらを列挙することは不可能です。リンクを電子メールで送信できるように、コードを電子メールで送信すると述べました。
いくつかの欠点があります。 38桁のパスフレーズは、ユーザーがボックスに入力することを本当に望んでいる場合、最も便利ではありません。
要件の1つ（この編集の前に見逃していた）は、コードがサービスデスクと対話できる必要があることです。 GUIDを含むURLに加えて、GUIDの最後の6桁をトークンとして使用し、個人にIDの1つを提供するよう依頼しますトークンと電話またはテキストメッセージによる6桁です。少々お粗末ですが、エントロピーが改善され、コードを読み上げる方法が提供されます。URLの最後の6桁を使用すると、すべての一貫性が保たれます。寒い彼らが登録した姓またはメールアドレスを使用します。姓は2文字のみなので、エントロピーは8ビットだけですが、何もないよりはましです。
これに当てはまるいくつかの不利な点があり、あなたが説明している一般的なケースにも当てはまります：メールユーザーエージェント、メール転送エージェント、エンドポイント、見落とし、共有メールボックスのセキュリティへの依存。被害者を知っている悪い俳優は、彼らのDOBとSSNをすでに知っているかもしれません（私はSSNを持っていないので、これが事実かどうかはわかりませんが、英国ではNINはかなり公開されています）。ブルートフォースはありそうもないですが、良い習慣として、試行を抑制したいと思うでしょう。
1から10のスケールでリスクについて質問します。リスクは、ビジネスへの影響と可能性の産物です。前者についてはお答えできません。CIAに対する妥協の影響を判断するには、ビジネスへの影響評価を行う必要があります。 GDPRで要求されているとおりにPIAを実行する場合、データ主体の権利と自由への影響の観点から、単一のレコードはデータ主体にとって限界的なリスクであると主張するかもしれません。攻撃者ができることはあまりなく、 DOB +の名前はすでにかなり公開されています。 SSNについてはよくわかりません。英国のNIN + DOB +の名前は、アイデンティティハイジャックのリスクとなる可能性があります。データ侵害はICOに通知されると私は思うので、あなたの影響はあなたの規模で3から6になるでしょう。データベース全体の損失は5〜8となる可能性がありますが、この質問は、列挙の実行不可能性を想定した単一のレコードに関するものです。その可能性は、脅威のモデリングを行うことを必要とすることです。私は、データベースがどれだけのターゲットをターゲットにしているのか実際には言えません。それが非常に魅力的である場合、たとえば、メンバーのレコードを直接取得できることが大きな現金報酬につながる場合、誰かがボットネットをレンタルして衝突またはブルートフォース攻撃を試みる可能性があります。もちろん成功する可能性は低いですが、賞金がそれだけの価値がある場合、彼らは試してみるかもしれません。ただし、資格情報のデータベースが不十分な内部慣行によって公開されている可能性が高くなります。エンドユーザーは高度なセキュリティを意識している可能性が低いため、とにかく資格情報を保存する可能性があります。
脅威モデルは、ユーザーの行動やユーザーのメールに関心があるのか、それとも自分が制御できる部分だけに集中したいのかを教えてくれます。サイトが攻撃に対して非常に耐性がある必要がある場合は、英国政府ゲートウェイが行うように、事前に登録されたアドレスにカタツムリのメールで資格情報を投稿することを検討してください。
リスク/脅威の評価がテクノロジと、実施しているコントロールのセキュリティに限定されていると仮定すると、URLのGUIDはクライアントにとって最も簡単なソリューションであり、利害関係者はそれも許容範囲です。
脅威の評価で、アクティブな時間枠の間にだれもそのURLを偶然見つけたくないと示している場合は、ソーシャルメディアアカウントを介してログインを許可することを検討する必要があります。例：oAuthなどアイデンティティを提供します。ユーザーにとっては簡単で、「モダン」です。しかし、欠点は、oAuthをコーディングする必要があることです。 Googleへの制御、そしてもちろんそれはそのようなアカウントを持つユーザーに依存しています。
なぜ彼らにリンクを送信しないのですか？
リンクには一意の64文字を含めることができます。これは参照コードよりもはるかに強力であり、姓とSSNの最後の4桁を入力するだけで済みます。
なぜ2FAを使用しないのですか？
現在使用しているのは、変化する1つの値（参照コード）のみです。アプリケーションに非常に機密性の高いデータが含まれているとしましょう。このデータにアクセスできるCEOまたはその他の人物は、BEC（ビジネスメールの侵害）の被害者です。攻撃者は自分のリンクにアクセスでき、姓を知っているため、電子メールのどこかに埋め込まれているSSNの最後の4桁を見つける可能性があります。 2FAはこれを回避する方法であり、SSNの最後の4桁を使用するのではなく、OTPから常に変化する独立した値を使用すると、セキュリティが大幅に向上します。
ブルートフォースを防ぐ
アプリケーションの総当たり攻撃を防ぐために、特定の参照コードに対してスロットルを有効にすることができます。この参照値を使用して、特定の時間枠内で姓が5回誤って入力されたとすると、新しい参照コードが電子メールに送信されます。これにより、ブルートフォースが大幅に困難になります。