ユーザー名の入力ミスを防ぐためにどのような方法を使用できますか？
銀行のウェブサイトで自分の口座にログオンしたかった。アカウントは、いくつかのセキュリティチェックによって保護されています。 1つ目は、実際にはユーザー名、つまり機密情報です。これは8桁の数字のパスコード（銀行から提供されたもの）で、入力後、個人データとパスワードも入力する必要があります。今日、私はパスコードがロックアウトされ、電話で銀行に連絡しなければならないことをシステムから通知されました。私はそうしました。そして、私の身元を確認するために電話でその人にかなりの量の個人データを渡した後、私のアカウントはすべて良好であり、ログオンできることを知らされました。彼らはまた、おそらく誰かが私のパスコードを誤って使用し、後で正しい情報を入力できないために私のパスコードをロックアウトしたためだと私に言った。私の最初の反応は「誰かが私のお金を盗もうとした！」でしたが、それは確かにそうだったと私は確信しています。
それが起こった場合、関係するすべての関係者にとって不便でした。パスコードを間違えた人には、明らかに、間違ったパスコードを入力していることが通知されず、後で正しい情報を入力するために時間を無駄にしました。銀行は私を手伝うのに彼らの人的資源を使わなければなりませんでした。月曜日の午前0時5分に銀行に電話をかけることに時間とお金を費やさなければなりませんでした。
そのような状況を防ぐために銀行や他のエンティティによって何かが行われていますか？何が行われていますか？コードを提供するのは彼らであり、ユーザー間でそれらを異ならせない理由はないと思います。私は計算を試みていませんが、特定の一般的な間違いが発生しないことを確認することは非常に複雑に見えません。
編集：これまでに与えられたすべての答えをありがとう。答えは、不便さは軽微であり、それが起こったことのすべてが幸せであることを強調しています。私のお金が盗まれなかったのは確かに不満ではありません。 :)しかし、非類似性の問題に対処できますか？たとえば、ランダムに生成されたパスコードが隣接する数字の転置の影響を受けないことを確認しない正当な理由はありますか？
数値のユーザー名を発行する銀行はかなり煩わしいです。そして、私はほとんどそれより偏執的ですが、誰かがちょうどあなたのIDを指で触れて、彼らがあなたを締め出すまでそれを認識しなかったのはおそらくあなたは正しいでしょう。
この質問に答えるために、一部の銀行は、正しいユーザーアカウントでログインしようとしていることを確認するのに役立ちます。銀行のログインページに表示される「セキュリティ画像」はそうです。そうです、銀行は、それらの画像があなたが彼らのウェブサイトにログインしていることを確実にするのに役立つとあなたに言います。しかし、本当の利点は、ユーザーが他の誰かのアカウントにログインしようとしていることをユーザーが理解できるようにすることです。このプロセスを使用するサイトは、メインのログインページでユーザー名を要求し、「セキュリティイメージ」とパスワードフィールドのある新しいページに移動します。また、以前にログインしたことがないコンピュータからログインする場合は、パスワードを要求する前に別の形式の認証（セキュリティの質問など）を要求する場合もあります。
ログインするたびに、サインアップ時に選択した画像が表示される場合は、その画像が異なる場合に気づく可能性が高くなります（サイトを十分に頻繁に使用するとします）。これは、フィッシングサイトにログインしている可能性がありますが、多くの場合、ユーザーアカウントを偽装しています。
編集：-編集に回答するには-
数値のユーザーIDを扱う場合、10桁しかなく、10キーとモバイルデバイスの非常に狭い領域に詰め込まれています。数万（または数十万）人のユーザー、数字の不足、および3つの一般的なレイアウトのうち2つがどれだけ近いかを考えると、1つのIDが他のIDと十分に異なり、一般的なタイプミスのエラーを防ぐことはできません。 。
また、パフォーマンスの観点から考えると、新しいIDがuniqかどうかを検出することは、適切に設計されたほとんどのシステムで非常に効率的で迅速なプロセスです。ただし、新しいIDが他のIDと異なるかどうかを検出するには、他のすべてのユーザーIDを反復処理し、2つをアルゴリズムと比較する必要があります。これは（比較的）遅くてつらいプロセスです。十分な時間と労力があれば、ngramやその他の比較ポイントをキャッシュして高速化できますが、それでも遅くなります。
つまり、ユーザーIDでこれを行っている会社はありません。確かに数値の会社ではそうではありません。 （しかし、私は喜んで誰かがそれをしていることについてのホワイトペーパーまたはエンジニアリングブログを読みます）
他の2人のユーザー（Philippを含む）がチェックサムディジットに言及しましたが、最初はシステム側に焦点を当て、ユーザー名の違いが質問の焦点になっていたため、これについては説明しませんでした。しかし、さらに考えれば、それはこの会話の中で場所を持っています。チェックサムは、アカウント番号、つまりクレジットカード番号を増やすためによく使用されます。これは、最初の学期のプログラミングの学生が検証ツールを作成するために使用できます。これにより、入力ミスがほとんどなくなり、エントリーフォームに投稿することなくクライアント側で確認できます。誰かがこれを数値のユーザーアカウントで使用している場合、（内部の知識がなければ）言うことは不可能です...私はsomeoneであると思いますが、私はそれを見ていません。コミュニティ内での興味深いディスカッション（またはドキュメント）、誰もそれを行っていることを聞いたことがありません。私たちは皆同意できると思います、あなたの銀行はそうではありません。 :)
連続した番号を取得してパスコードを生成し、実際の番号のチェックサムである1つ以上の数字を追加することができます。ユーザーが入力したチェックサム数字がパスコードの実際の部分と一致するかどうかを確認することにより、クライアント側でパスコードの有効性を確認できます。
1つのチェックサム数字により、別のユーザーの有効なパスコードを誤って10分の1、2分の1から100分の1、3分の1から1000分の1に入力する可能性が減少します。
ただし、欠点は、パスコードが長くなるほど、暗記が難しくなるため、パスコードを忘れてしまい、パスコードを回復するために再び人的資源を消費することになります。つまり、システムの設計者は、他の人のパスコードを入力する人とパスコードを忘れる人によって生じる不便さの適切なバランスを見つける必要があります。
彼らはあなたのアカウントへの攻撃を防ぎました。これは望ましい結果です-彼らが無制限のパスワードを試すことができれば、彼らはあなたのパスワードを推測したでしょう。攻撃は時間内に停止され、わずかな不便が生じました。あなたに深刻な迷惑をかけるためにこのパターンが繰り返された場合、銀行は単にあなたに新しいランダムパスコードを発行することができます。
彼らは、高価な詐欺を防止することよりも、安価な不便さを防止することに関心がありません。
編集：
ランダムに割り当てられた8桁の数字の問題は、定期的に使用する必要がない場合、その数字を覚えていない可能性が高いことです。番号が82640927または82604927である場合、どのように記憶しますか？
入力ミスを減らすために長い間使用されてきたものは、Luhnチェックディジットアルゴリズムです。番号を検証し、いずれかの数字が正しくない場合、または1組の数字が誤って転置された場合に、システムにユーザーに番号の再入力を求めるプロンプトを表示します。クレジットカードはこれを何十年も使用しています。しかし、Luhnアルゴリズムは偶発的な問題をすべて防ぐわけではなく、意図的な試みを停止することもありません。
偶発的な衝突を減らす最善の方法は、潜在的な番号スペースを増やし、番号スペース全体にユーザーをランダムに割り当てることです。ユーザーに0000000001、0000000002、0000000003などの番号が付けられている場合、10桁の数字を使用しても衝突は止まりません。これを実現する1つの方法は、シーケンシャルシードを使用し、それをハッシュアルゴリズムに入力して10桁の数字（下位4バイトのunsigned intを取得することは、これを実現する1つの方法です。2つの数値が互いに関係を持たないようにするのは十分にランダムであり、偶発的なタイプミスが本当に少なく、はるかに遠くなります。 Luhnの数字は、ユーザーが明らかに障害のあるアカウント番号にパスワードを入力する時間を無駄にしないようにするための礼儀チェックとしても役立ちます。
Webサービスでは、ログインリクエストの発信元の場所を考慮し、過去のログイン試行と相関させることができます。クレジットカード会社があなたのクレジットカードでの「異常な活動」に気付いたときにあなたに連絡する方法と同様です。これは、Web上のサービスを提供する組織がこのようなインシデントに対処するために使用できるロジックの1つです。接続に関連付けられているユーザー名が本人ではないと確信を持って言える場合は、これらのイベントを分離して、実際のアカウントに影響を与えないようにすることができます。
あなたのケースでは、銀行はロジックをプログラムするか、アナリストがあなたのアカウントIDでログインしようとする個人があなたと同じ地域から来たか、または完全に異なる地理的地域であると確信している場合に推測させることができます。
彼らに写真を与えるのに役立つ別のルートは、イベントから彼らが利用できるログです。あなたが話したカスタマーサービス担当者は、そのログにアクセスできなかったようです。おそらく、ログを表示する専門知識を持っていなかったでしょう。彼らがそうしたとしても、アプリケーションがその情報を詳細に記録するのは誰ですか？彼らはそれを望んでいるのでしょうか？その場合、何人の人がその情報にアクセスできますか？
これらの状況での高度なロジックは、すぐにトリッキーになる可能性があります。この場合の銀行の処理方法は、関係者全員にとって最も簡単で安価な対応のようです。サービスの中断が銀行との5分間の電話連絡だけだった場合は、被害が大きい可能性がある状況に対処するための非常に影響の少ない方法です。
割り当てられたユーザー名またはパスワードには、1つの重要な利点があります。通常、ユーザーが生成するよりもランダムです。 8文字の数字のみのユーザー名の場合、1億（10 ^ 8）の可能な順列があります。これは米国の人口の1/3未満、インドネシアの人口の約1/2です。したがって、この方法は確かにその数のオンラインバンキングユーザーを超えることはできません。
はい、これはユーザー名が簡単に推測できることを意味します-攻撃者は8桁の数字を反復するだけです。もちろん、この方法で総資産のアカウントに総当たりすることは非常に幸運である必要があります。
ただし、経験したように、同じアクティビティを簡単に使用してサービス拒否攻撃を実行できます。ユーザー名ごとにN回連続してランダムにパスワードをランダムに推測します（Nはアカウントロックをトリガーするために必要な試行回数です）。数時間以内に、銀行はすべてのオンラインバンキング顧客を電話で確認する必要があり、コールセンターは圧倒されます。
解決策は、ユーザー名の文字セットを拡張することです。大文字と小文字を区別する文字も許可することにより、順列の数は218兆（（26 + 26 + 10）^ 8）に拡大し、上記のサービス拒否攻撃の効果を大幅に削減し、また、あなたのような偶発的な衝突を大幅に削減します。経験した。
欠点は、ユーザー名を覚えて入力するのが複雑になることです。これは、ユーザーがユーザー名を選択できるようにすることで部分的に軽減できます。そしてthatの欠点は、ランダム性がいくらか失われることです。
Googleのような一部のWebサイトがこの種の攻撃を防ぐために行っているように見えることの1つは、一定のログイン試行の後、ロックアウトせずに、CAPTCHAと呼ばれるものを提供することです。これはボットのログインを防ぐためにより多く使用されますが、悪意のある人間のユーザーの速度を低下させます。これは、彼/彼女がまだパスワードを把握する必要があり、一部のCAPTCHAが難しいためです。また、正規のユーザーに不便を与える可能性もありますが、これらのサイトでキャプチャを取得するまでに、パスワードを覚えていない可能性があります。
一部のサイトが行っているように見えるもう1つのことは、ユーザー名を永続的にではなく一時的にロックすることです。たとえば、私の2年間の大学のサイトでは、間違ったパスワードを3回入力したときに15分間ロックされ、その後、ロックが解除される前に、新しいパスワードの試行ごとにさらに5分間累積されました。多くのAndroid電話の画面ロックもこれを行います。この方法は、悪意のあるユーザーが多くの試行を試みる可能性があるため、この方法ではDOS攻撃を許す可能性があります。時間制限を特定のIP、Cookieなどにリンクすると、IPが偽装される可能性があることを念頭に置いて、これを軽減できます。
これらの方法はどちらも、悪意のある人間のユーザーよりもボットを抑止するために機能しますが、事故が発生した場合に正当なユーザーのアカウントを永久的にロックすることなく、人間のユーザーを遅くします。どの方法が銀行にとってどれほどうまく機能するかはわかりません。たとえば、Googleよりもはるかに偏執的だからです。また、これらのサイトのほとんどは、ユーザーが指定したユーザー名で使用したものですが、銀行が指定した数値のユーザー名でも機能すると思います。