私は金融機関のプログラマーです。私は最近、すべての新しいユーザーIDに少なくとも1つのアルファと1つの数値を含めるように強制するように言われました。これは恐ろしいアイデアだとすぐに思いました。これは反機能であり、ユーザーエクスペリエンスが低いと思うので、実装したくありません。問題は、この要件を実装しないという良いケースがないことです。
これは良い要件だと思いますか？
それをしない正当な理由はありますか？
私が参照できる研究を知っていますか。
編集：これはパスワードとは関係ありません。私たちはすでにそれについて同様の要件を持っていますが、私は反対していません。
私は、この背後にある特定の理由について彼らに尋ねることから始めます。箇条書きのリストとその理由がわかれば、反論したり、代替案を提供したりするのが簡単になります。
一般的な考え方について：
認証システムが複雑になるほど、一般ユーザーはそれを回避してチェーン内のリンクを弱くする方法を見つける可能性が高くなることを忘れないでください。
これに対する反論の 1 つは、他の地域の多くのユーザー名/ID は数値コンポーネントを必要としないということです。ユーザーは、他の場所で使用したユーザー ID をよりよく覚えている可能性が高くなります。また、数値を含める必要がない場合は、その可能性が高くなります。
さらに、システムによっては、外部システムに接続するときにユーザー ID がデフォルトとして適切に機能する場合があります (UNIX ライクなシステムでは ssh はこのように動作します)。この場合、システム間で共有される 1 つの ID を持つことは明らかに有益です。
複数の場所で同じ ID を使用すると、一貫性が向上します。これは、優れたソフトウェア インターフェイスのよく知られた側面です。人々がシステムとやり取りする方法がユーザー インターフェイスであることを示すことはそれほど難しくなく、よく知られているインターフェイス ガイドラインの (少なくとも一部は) に従う必要があります。(おそらく未知の複数のシステム間の相互作用を考慮している場合、キーボード ショートカットのようなアイデアは無意味ですが、一貫性などの側面は当てはまります。)
編集:この議論は、パスワードなどのセキュリティに直接関係するものではなく、ユーザー名または一般に公開されている ID に関するものであると想定しています。
ユーザーID？パスワードに英数字を要求することは、辞書攻撃に対する耐性を高めるため、一般的には良い考えです。ユーザー名にはまったく意味がありません。名前とパスワードの組み合わせを持つことの全体的なポイントは、名前の部分を秘密にしておく必要がないということです。
金融機関に勤めていると、こういうことは規制されているので、手が出ない可能性が高いです。しかし、できることの 1 つは、ユーザーが無効な ID を入力したことを明確にすることです。そして、送信をクリックするまで待たないでください。フィールドのすぐ隣にある種のメッセージを表示し、入力時に更新します。
上記の回答のいくつかには反論があります。ユーザーが他のサイトで使用しているのと同じユーザー名を選択すると、金融サイトでも同じまたは類似のパスワードを選択する可能性が高くなり、セキュリティが低下します.
そうしない理由: ユーザーに慣れているよりも多くの制限を課すと、ユーザーはログイン情報を書き留めるようになり、明らかにセキュリティが失われます。
私が持っている銀行口座はどちらも、オンライン ログイン用に英数字のユーザー名と 2 つのパスワードが必要です。そのうちの 1 つは、私が覚えておかなければならないイメージでもあります。2 つのパスワードは、1 か月に 1 回程度変更する必要があります。そのため、すべてのログイン情報をテキスト ファイルに保存しています。(これを見ても意味がありません。銀行に行って、もう一度パスワードをリセットする必要があります。これは、6 回のログインで合計 7 回のパスワードのリセットです。セキュリティについて話してください。アカウント。）
ユーザー名は、（おそらく）サポートを呼び出すときに電話で引用する必要があるため、パスワードとは異なり、公開されます。また、ユーザー名フィールドは、パスワードフィールドのようにブラウザでマスクされないため、より多くの露出があり、さまざまな場所でキャッシュ/ログに記録されるため、追加されたセキュリティの「利点」はすぐに取り消されます。
そして、物事を難しくするほど、ユーザーがそれをどこかに書き留める可能性が高くなり、セキュリティが再び損なわれます（実際には同じことがパスワードポリシーにも当てはまりますが、それは別の話です！）
それが彼らのパスワードにあるならそれは良いことです（悲しいかな、金融会社はあなたにこのセキュリティ権を否定するのが好きです[私はあなたにアメリカンエキスプレスと話している]）。
ユーザー名、彼らが望まない限り、私はノーと言います。
私も金融機関で働いており、私たちのユーザー名 (実在の人物と製品 ID の両方) はすべて小文字、アルファベット、最大 8 文字であり、問題とは考えていません... 0 対 O、1 対 O の混乱を回避します私と 8 対 B - あなたが私と同じ会社で働いていて、新しいポリシーを導入しようとしている場合を除きます...
機能を追加すると、コストが追加されます。現在、それを構築してテストし、将来サポートするには時間がかかります。本当に正当な理由がなければ、機能を構築するべきではありません。
この機能は無意味です。ユーザー名は秘密にしておくべきではないため、強力なユーザー名を使用しても利点はありません。パスワード (またはその他の認証要素) を強化するために時間を費やすことはおそらく価値がありますが、ユーザーは、セキュリティ上のリスクを負うことなく、自分のユーザー名を他のユーザーに伝えることができる必要があります。
アプリケーションがユーザー ID の選択に特別な制約を課している場合、一部のユーザーは、環境内の他のアプリケーションとは異なるアプリケーションのユーザー ID を持つことになります。注: これは、インターネットに接続するアプリケーションではなく、内部アプリケーション (従業員が使用するため) であると想定しています。
一貫性のないユーザー名を使用すると、いくつかの特定のリスクが追加されます。