任意のユーザー名要件を持つことのポイントは何ですか？
Security.SEを見回しましたが、次の問題に関連する部分はあまり見つかりませんでした。
私は最近、アルバイトでの支払い方法として Chase Quick Pay にサインアップしました。 愚かなパスワード要件 を聞いたことがありますが、愚かなusername要件はありません。
私が 登録済み のとき、私はそれがどれほど奇妙であるかを本当に考慮していませんでした（ポリシーのために過去3か月間にユーザー名を2回忘れたので、私は本当にそうするべきでした）：
今、Stack Exchangeエンジンは、最初の文でそれをすべて言っている@ -Polynomialによる 良い答え の質問の方向にとても優しく私に指摘してくれました：
認証強度は、ユーザー名ではなくパスワードから取得する必要があります。
したがって、簡単に言えば：ユーザー名にこのような要件があることのポイントは何ですか？
編集：明確化のために-これらの種類のユーザー名要件を持つことによる実際のセキュリティ上の利点はありますか？
ボーナス： 自分の銀行のユーザー名/パスワードセキュリティポリシー を見ただけで、次のことがわかりました（異常ではありません）：
注：最初の文字として「X」を許可しないことの意味はよくわかりません...答えることができる人なら誰でも+10を受け取ります！
ユーザー名の選択に関する要件/制限を適用するための2つの主要な引数があります。 1つ目は、ユーザー名を攻撃者が予測しにくくすることで、オンライン推測攻撃に対抗できるようになることです。ユーザー名は必ずしもパスワードほど秘密であるとは見なされませんが、ユーザーを偽装するために盗まれる必要がある少なくとも2つの情報の1つです。攻撃者に知られていないこの情報の利点を無視すべきではありません。
2007年の論文 強力なWebパスワードは何かを達成しますか？（PDF） オンラインパスワード推測の脅威を評価し、それと戦うためのオプションを検討します。サイトはより厳しいパスワードポリシーを適用する可能性があり、ユーザーがプロセスの順守と苛立ちを経験するのに苦労した場合、ユーザビリティを損なう可能性があります。または、サイトはユーザー名の制限を強制し、パスワードポリシーを同じに保つことができます。彼らの理論は、攻撃者が多くの可能な組み合わせを試さなければならない場合、それが簡単なユーザー名と複雑なパスワードによるものか、それとも半複雑なユーザー名と半複雑なパスワードによるものであるかはそれほど重要ではないというものです。
これは、ユーザー名をそのままにして、パスワードのセキュリティを補うために2番目の認証要素を追加するサイトの3番目のオプションを無視します。また、攻撃者が可能なパスワードとペアリングできるように、サイトがより有効に動作することを要求します 有効なユーザー名の開示を避けます 。
2番目の引数は、やや固有のユーザー名要件を適用することで、サイトが他のサイトで使用したのと同じ資格情報をユーザーが選択するのを阻止できることを期待できます。これは非常に現実的な脅威であり、サイトが通常とは異なるユーザー名の要件を適用する（またはID自体を割り当てる）以外のことを行うことは困難です。ただし、2010年からの1つのすばらしい研究 実際のユーザー名とパスワードの再利用を監視 銀行と他のサイトの間の人々による。調査によると、人々は実際に73％の確率で他のサイトで銀行のパスワードを再利用しましたが、また銀行が一意のユーザー名規則を実施したとしても、すると、そのユーザー名は42％の確率で少なくとも1つの他のサイトで再利用されます。
したがって、一意のユーザー名の要件を適用すると、資格情報が共有される可能性は低くなりますが、その可能性は排除されませんでした。しかし、その低いリスクは、一部のサイトでは、ユーザーにとって不便であると見なされている可能性があります。
もう1つの考えられる理由は、これは議論ではなく、要件ですが、レガシーシステムの互換性です。古いソフトウェアが、おしゃれなWebフロントエンドの背後でバックエンド処理を実行している場合は、特定の方法でフォーマットされたユーザー名のみを受け入れるようにコーディングされている可能性があります。そのソフトウェアを取り除いて交換しないと、サイトは顧客への制限を通過して行き詰まる可能性があります。 「ユーザーIDをXで始めることはできません」という行は、これがあなたの場合の要因である可能性があると私に思わせます。
これらのユーザー名の要件により、ユーザー名が予測不可能になる可能性があります。これによってセキュリティが大幅に改善されるとは思いませんが、少し役立ついくつかのシナリオを考えることができます。それがユーザビリティの損失を相殺することは疑わしいですが、結論を出す具体的な証拠はありません。いつものように、 ユーザビリティを犠牲にしてセキュリティを確保すると、セキュリティを犠牲にして実現します。 ：ユーザーがユーザー名を忘れる可能性が高い場合、これは、ユーザー名を安全でない場所に保存する必要があることを意味します場所（目的を無効にする）または、ユーザー名（強力に認証されない可能性があります）を回復する方法が必要です。
予測が難しいユーザー名はプライバシーを向上させます。 johnsmithアカウントを作成しようとして、そのユーザー名がすでに使用されているために失敗した場合、John Smithがその会社と銀行取引をしていることがわかります。 John Smithのアカウントがjohnsmith1の場合、さらにユーザー名を列挙する必要があります。ただし、ユーザーが選択したユーザー名では、サフィックス1を使用することをお勧めします。ほとんどのWebサイトは、一意のトークンとしてメールアドレスに依存しています。[email protected]としてアカウントを作成する場合、このアドレスに送信されたメールを読むことができることを証明する必要があります。銀行は通常、外部のセキュリティに依存することをためらうため、電子メールプロバイダーに依存したくない傾向があります。
バンキングに対するかなりの数の攻撃が家の環境で行われます-配偶者、子供、訪問者など。ユーザー名が予測しにくいと、被害者のコンピューターにアクセスできるが実行する可能性が高いカジュアルな攻撃者に対する機密性を向上させることができます攻撃を真剣に研究するよりも、日和見攻撃。繰り返しになりますが、ユーザーが選択したユーザー名を使用しても、複雑さの要件はそれほど改善されません。多くのユーザーは、ユーザー名をブラウザーにあらかじめ入力したままにし、johnsmith1を選択しない場合、バリエーションは彼らはお互いをよく知っているので、攻撃者に知られている。
予測が難しいユーザー名を使用すると、弱いユーザーが見つかるまでユーザー名とパスワードの組み合わせを多数試すことで機能する非標的型攻撃に対する防御力も向上します。繰り返しますが、johnsmithに加えてjohnsmith1を試しても、大幅な改善はありません。
Xで始まらないユーザーIDについては…銀行です。腸の奥深くにあるのは、x86プロセッサの仮想マシンで実行されているエミュレートされたVAXで実行されている少し最近のエミュレートされたIBMビッグアイアンで実行されているエミュレートされたIBMビッグアイアンで実行されているCOBOLプログラムです。あなたが生まれる前に、誰かが削除されたレコードを17番目の列にXを入れて示すことは良い考えだと決めました。 Y2Kバグを修正する必要がなくなったCOBOLプログラマーもそれを修正することを提案しましたが、これはジョブスペックの範囲外であり、機能するものには触れないように言われました（銀行の場合、これは異なる方法で機能する可能性があります）監督の名前はジョージの代わりにザビエルだった）。
- ユーザーIDを予測しにくくするため。
- 他のシステムに準拠するため。
予測できないユーザーIDの理由は次のとおりです。
アプリケーションは、ユーザーIDごとのパスワード推測の数（インターネットバンキングでは一般的なもの）を制限します。その後、攻撃者は「既知のすべてのユーザーIDに対してパスワード123456を試す」攻撃を仕掛けることができます。攻撃者が大量のユーザーIDを知らない場合、この攻撃はあまり意味がありません。
アプリケーションには、私たちが知らない設計上のセキュリティ上の欠陥があるかもしれません。たとえば、アプリケーションはユーザーIDを使用してセッショントークンを取得する場合があります。
一部の（レガシー）システムがユーザーIDを16進数として解釈するのを防ぐために、最初の文字としての「X」は許可されない場合があります。
奇妙なユーザー名を強制すると、パスワードを再利用しているXYZアカウントと同じユーザー名を持つのとは対照的に、アカウントは2番目のパスワードのように機能するため、簡単にアカウントを解読できます。 （ただし、いくつかの要件を課すと、ユーザーが自分のユーザー名を忘れてしまいやすくなります！）
ユーザー名に最小の長さを設定する主な理由は、「ジョー」のような一般的な名前を使用しないようにするためですが、もっとユニークなものを強制します（おそらく、姓、日付を追加します...）
電話で伝える必要がある場合は、特殊文字を制限することは理にかなっています。文字が必要な場合も、通常のユーザー名のように見せるために役立ちます。ユーザー名に数字を要求するのは意味がないと思います。
銀行の規則は、一般的にはるかに健全です。 Xで始まるユーザー名が内部で使用されていると思います（例：テストユーザー、予約済みアカウントなど）。
奇妙なユーザー名を強制すると、パスワードを再利用しているXYZアカウントと同じユーザー名を持つのとは対照的に、アカウントは2番目のパスワードのように機能するため、簡単にアカウントを解読できます。 （ただし、いくつかの要件を課すと、ユーザーが自分のユーザー名を忘れてしまいやすくなります！
制限が異なると、ソースが異なる可能性があります。
ユーザー名の文字セットをASCII英数字に制限することは、ユーザー名をさまざまなデータ形式で簡単に格納でき、ほとんどのタイプのインジェクション攻撃（SQLインジェクション、HTMLインジェクション、シェルインジェクション）のベクトルとして使用できないことを意味しますなど）、「マークアップに意味のある」文字がASCII英数字の範囲外であるため。これは、スタッフがユーザー名を簡単に操作できることも意味します。
完全に数値のユーザー名を禁止することは、ユーザー名と数値のユーザーIDの混同を避けるための試みである可能性があります。
制限のもう1つの原因は、異なるユーザーセット（内部の人間のユーザー、外部のWebユーザー、システムユーザーなど）のユーザー名が重複しないようにすることです。これが、Debianがsalsa.debian.orgで作成されたアカウントに「-guest」接尾辞を付けることを要求する理由であり、「少なくとも1つの数字が含まれている必要があり」、「Xで始めることはできません」理由。