質問

私は金融機関のプログラマーです。最近、すべての新しいユーザー ID に少なくとも 1 つの英字と 1 つの数字を含めるよう強制するように言われました。私はすぐに、これはひどいアイデアだと思いました。これはアンチ機能であり、ユーザー エクスペリエンスが低下すると考えられるため、実装したくありません。問題は、この要件を実装しない理由が見つからないことです。

これは良い要件だと思いますか?

それをやらない正当な理由はありますか?

参考にできる研究を知っていますか。

編集:これは ない パスワードに関して。それについてはすでに同様の要件があり、私はそれに反対しません。

役に立ちましたか?

解決

これに対する反論の 1 つは、他の領域の多くのユーザー名/ID には数値コンポーネントが必要ないということです。ユーザーが他の場所で使用したユーザー ID をよりよく覚えられる可能性は高くなります。数値を含める必要がなければ、その可能性が高くなります。

さらに、システムによっては、外部システムに接続するときにユーザー ID がデフォルトとして機能する場合があります (UNIX 系システムでは ssh がこのように動作します)。この場合、システム間で 1 つの ID を共有することが明らかに有益です。

複数の場所で同じ ID を使用すると、一貫性が向上します。これは、優れたソフトウェア インターフェイスのよく知られた側面です。人々がシステムと対話する方法を示すのはそれほど難しいことではありません ユーザー インターフェイスであり、よく知られているインターフェイス ガイドライン (少なくとも一部) に従う必要があります。(明らかに、未知の可能性がある複数のシステム間の相互作用を考慮している場合、キーボード ショートカットのようなアイデアは無意味ですが、一貫性などの側面は重要です。 する 適用する。)

編集: この議論はユーザー名または公開 ID に関するものだと思いますが、 ない パスワードなど、セキュリティに直接関係するもの。

他のヒント

まずはその具体的な理由を聞いていきたいと思います。箇条書きとその理由のリストがあれば、反論したり代替案を提示したりするのが簡単になります。

一般的なアイデアとしては、次のとおりです。

  • これは意見ですが、ユーザー名に数字を追加しても必ずしもセキュリティが強化されるわけではありません。人々はポストイットにユーザー名を書き留めますが、ほとんどのユーザーはユーザー名の先頭または末尾に「1」を追加するだけなので、簡単に推測できます。
  • ユーザビリティの観点から見ると、これは標準を破っているため好ましくありません。ユーザー名に数字を追加することを強制すると、上記の点につながるだけです。ユーザー名の末尾または先頭に「1」を追加するだけです。

認証システムが複雑になればなるほど、一般ユーザーが認証システムを回避し、チェーン内のリンクを弱める方法を見つける可能性が高くなります。

ユーザーID?パスワードに英数字を必須にすることは、辞書攻撃に対する耐性が高まるため、一般的には良い考えです。ユーザー名にはまったく意味がありません。名前とパスワードの組み合わせの重要な点は、名前の部分を秘密にしておく必要がないことです。

金融機関に勤めている場合は、このようなことについては規制があると思いますので、手に負えない可能性が高いです。ただし、できることの 1 つは、ユーザーが無効な ID を入力したことをユーザーに明確に示すことです。そして、彼が送信をクリックするまで待たないでください。フィールドのすぐ横に何らかのメッセージを表示し、入力中にそれを更新します。

上記の回答のいくつかには反論があります。ユーザーが他のサイトで使用しているのと同じユーザー名を選択すると、金融サイトでも同じまたは類似のパスワードを選択する可能性が高く、セキュリティが低下します。

それをしない理由:ユーザーにこれまで以上の制限を課すと、ユーザーはログイン情報を書き留めるようになり、明らかにセキュリティが失われます。

私が持っている銀行口座はどちらも、オンライン ログインに英数字のユーザー名と 2 つのパスワードが必要です。その中に私も覚えておかなければならないイメージがあります。2 つのパスワードは月に 1 回程度変更する必要があります。したがって、ここにはすべてのログイン情報がテキスト ファイルに保存されています。(見ても意味がありません。銀行に行ってパスワードを再度リセットする必要があります。これは、6 回のログインに対して合計 7 回のパスワード リセットとなります。セキュリティについて話しても 私のアカウントにアクセスできます。)

それがパスワードに含まれていれば問題ありません(悲しいことに、金融会社はこのセキュリティ上の権利を拒否したがります[アメリカン・エキスプレスのことを言っているのです])。

ユーザー名、彼らが望まない限り、私はノーと言います。

ユーザー名は(おそらく)サポートに問い合わせる際に電話で引用する必要があるため、パスワードとは異なり公開されます。また、ユーザー名フィールドは、パスワード フィールドとは異なり、ブラウザーでマスクされないため、公開される可能性がはるかに高く、さまざまな場所にキャッシュ/ログに記録されるため、追加されたセキュリティの「利点」はすぐに失われます。

そして、物事を難しくすればするほど、ユーザーがそれをどこかに書き留める可能性が高くなり、再びセキュリティが損なわれることになります (実際にはパスワード ポリシーにも同じことが当てはまりますが、それはまた別の話です!)。

私も金融機関で働いていますが、ユーザー名 (実際の人物と製品 ID の両方) はすべて小文字、アルファベット、最大 8 文字ですが、それが問題だと考えたことはありません...これにより、0 対 O、1 対 I、8 対 B の混乱を避けることができます。ただし、あなたが私と同じ会社に勤めていて、新しいポリシーを導入しようとしている場合を除きます。

機能を追加するとコストがかかります。現時点では、それを構築してテストし、将来的にはサポートするのに時間がかかります。本当に正当な理由がなければ、いかなる機能も構築すべきではありません。

この機能は無意味です。ユーザー名は秘密にされるべきではないため、強力なユーザー名を持つことにメリットはありません。おそらく時間をかけてパスワード (またはその他の認証要素) を強力にする価値はありますが、ユーザーはセキュリティ上のリスクを冒すことなく自分のユーザー名を他のユーザーに伝えることができる必要があります。

アプリケーションがユーザー ID の選択に追加の制約を課す場合、一部のユーザーは、環境内の他のアプリケーションとは異なるユーザー ID をアプリケーションに対して持つことになります。注記:これは、インターネットに接続されたアプリケーションではなく、内部アプリケーション (従業員が使用するため) であると想定しています。

一貫性のないユーザー名を使用すると、いくつかの特定のリスクが追加されます。

  1. 監査証跡を追跡することが困難になります (重大なセキュリティ リスク)。
  2. 後から使い始めると費用がかかる場合がある シングル・サインオン.
  3. ユーザーは、このアプリケーションが奇妙なユーザー名を使用していることを覚えておく必要があるため、ユーザー エクスペリエンスが低下します。
ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top