ユーザー名は秘密にしておくべきですか？
同僚との話し合いをまとめ、将来のデザインを導くのを手伝ってください：
影響が大きいシナリオでも：支払いアプリケーションまたは政府ゲートウェイを保護するが、インターネットでアクセス可能なアプリケーション
ユーザー名を保護するために、次の（またはその他の）手段のいずれかを実装する価値はありますか？
K政府ゲートウェイ または HSBCオンラインバンキング のような複雑なシステム生成のユーザー名が必要ですか？ユーザーがこれを忘れ、書き留める必要があるか、追加のコールセンターのトラフィックが必要か、メールアドレスや携帯電話番号などのパブリックユーザー名を使用するリスクと比較して、ユーザー名のメモをセルフサービスで提供する必要があるかどうかのトレードオフですか？
よりわかりやすい「ユーザー名が認識されませんでした」および「パスワードが正しくありません」ではなく、「ユーザー名またはパスワードが正しくありませんでした」という一般的なメッセージを提供する
次のタイプのログインシーケンスを使用すると、フィッシングサイトの識別に役立つサイトキーまたはユーザーが個人用パスフレーズを選択できます。
- ユーザー名と単純な秘密の値（郵便番号など）を入力します
- 無効な場合、エラーが表示されます：ユーザー名または値が正しくありません
- これらが有効な場合、ユーザーの個人用サイトキー画像が表示され、パスワードが要求されます
- 無効なパスワードの場合、エラーメッセージの誤ったパスワード
- 有効なアクセスが許可された場合
Quora.comでのよりフレンドリーな方法とは対照的に、正しいユーザー名のエントリで写真が表示されます。これはリスクの低いQ＆Aサイトでのみ許容されますか？
私の同僚は、ユーザー名を秘密にしておくことと上記のタイプの対策を主張しています：
- 大量のユーザー名を列挙すると、サイトに対して辞書やブルートフォース攻撃を試すことができます
- アカウントのロックアウトが有効になっているすべてのアカウントをロックすることで、サイトにアクセスできます
- ユーザーはサイト間で同じユーザー名とパスワードを使用することを好み、多くのサイトは自分のサイトに電子メールアドレスと携帯電話番号を使用しています。ユーザーがサイト間で認証情報を共有している場合、認証情報が他のサイトから盗まれたりフィッシングされたりして、サイトへのアクセスに使用される可能性があります
- モバイルや電子メールなどの既知の事実は、認証強度にはカウントされません。ユーザー名が既知の事実である場合、同じレベルのセキュリティを維持するには、統計的差異を補うためにパスワードを大幅に強化する必要があります。ユーザー名とパスワードの両方が6文字以上の場合、52文字の可能性があると仮定すると、52 ^ 12の組み合わせになります。ただし、ユーザー名が既知の事実である場合、52 ^ 6の組み合わせになります。同じレベルの保護を得るには、パスワードを最低12文字に増やす必要があります。これを怠ると、アカウント乗っ取りのリスクが高まります。
私はそれぞれに対抗します：
- これに対する本当のコントロールは、パスワードの長さ、複雑さ、アカウントロックアウトポリシーです。
- これは、一定時間（たとえば、5〜30分）後に自動ロック解除する、大量のロック解除機能を使用する、指数バックオフまたはIP禁止を一定の回数試行した後、選択的な自動化を解除することで軽減できます。何回か失敗した後に表示されるコントロール（例：Captcha、Robooスクリプト）
- ユーザー教育、2番目の認証要素、適応認証（たとえば、デバイスID、場所などに基づくステップアップ認証または段階的認証）は、これに対するより良い防御になります。
- ユーザー名をIDとして、パスワードを認証として表示します。より強力な認証が必要な場合は、パスワードを長くするか、2つのパスワードが必要です-IDはそのままにしてください
私の位置を学び、変更することを嬉しく思います。前もって感謝します。
従来の知恵re：ブルートフォース攻撃または列挙
これを見るにはいくつかの方法があります。ただし、実際に考える前に http://thedailywtf.com/Articles/The-Phantom-Password.aspx で始める必要があります。
パスワードが開示される程度はさまざまです。 Slashdotでの私のユーザー名は、私の投稿を読むすべての人に知られています。私の職場でのユーザー名は、オフィスの誰でも見ることができ、私のメールアドレスを知っている人なら誰でも同じように識別できます。誰も私の銀行口座番号（私のオンラインバンキングのユーザー名）を知っているべきではありません。
これらの状況のそれぞれで、ユーザー名が無効であること、またはパスワードが無効であることを明確に述べることの利点は限られています。さて、そのシナリオでは：Slashdotを使用している場合、アカウントは永久に存在するため、関係なくそれを把握できます。あなたが私の仕事を攻撃しているなら、それは私がまだ雇われているかどうかを与えることができます。私の銀行口座またはクレジットカード口座に対しては、それが口座を列挙する唯一の方法です。それは明確な目標を提供します。
どちらか一方を承認することは公共のシステムに限定された価値を持ち、パスワード認証は常に「ユーザー名とパスワードが一致するか？これは、間にステップがないT/Fの質問です。
New Age Wisdom re：Phishing
ユーザーがWebサイトにアクセスしたが、それが間違ったWebサイトである可能性がある。彼らはURLに注意を払わずにログイン資格情報を入力し（または、おそらく偽装されている可能性があります）、アカウントが侵害されます。銀行は、認証をマルチステッププロセスにすることでこれに対処しています。この考えに対して、元の質問者は、ユーザー名が正しい場合、一連の写真を表示することについて言及しています。私は反論します：常に認証プロセスがすべてのステップを通過するようにします。 jonjacob（jinkleheimerschmidt）は有効なログインではない可能性がありますが、一連の写真を表示してパスワードを要求する必要があります。これにより、情報漏えいのリスクを抑え、フィッシングによるユーザーアカウントの侵害を防ぐことができます。
リスク対報酬
上記のユーザー名とパスワードに関する従来の知識は単純で、ほとんどの人に受け入れられると思います。フィッシングは新しい変数であり、それに対処することで一部のシステムの状況が変化します。ここで説明されていない、またはまだ考えられていない質問への回答があります。しかし、私はまだ、誰かがいかなる状況でもアカウントを列挙することを防ぐことができるはずだと信じています。
Ifusers have complex passwordsorあなた トークン のような追加のセキュリティを使用して、攻撃の複雑さを「妥当な」レベルに強制するには、暗号化の側面をカバーする必要があります。ただし、考慮すべきプライバシーの側面があります。一部の人々は、anybodyがそれらについて何かを理解することを好まないだけです。 すべてのマイノリティに対応することはできず、ビジネスやコミュニティの要件に従って設計することはできません。
義務的な引用： " セキュリティは常にトレードオフです。 "
ユーザー名を秘密にするという提案はばかげているようです。
アカウントのセキュリティを損なわない方法でユーザーを識別する何らかの方法が必要になることは避けられません。メールアドレスが認証トークンである場合、メールはどのように機能しますか？一部のソフトウェアの使用に問題がある場合、これがどのアカウントに関連しているかをヘルプデスクに伝えるにはどうすればよいですか？
アカウントのロックアウトが有効になっているすべてのアカウントをロックすることで、サイトにアクセスできます
また、個別のパスワードがなかったシステムにアクセスすることもできます。ユーザー名を明らかにすることは問題ではなく、ロックアウトルールの実装に問題があります。
ユーザーは同じユーザー名とパスワードを使用したい
はい、これを認めます。しかし、それは仮定を正当化しません。ユーザーは愚かです。それを乗り越えなさい。彼らにあなたのサイトが安全であると思わせたいならば、南京錠の全体像を置くことがSSLを使用するよりもうまくいくことを示す多くの研究があります。パーシャルを介して実装されたセカンダリ認証トークンをフィッシングしようとしている場合（「ピンから3桁目と8桁目を選択してください」など）、テキスト入力ボックスを提供し、全体を提供するよう依頼してください。
モバイルや電子メールなどの既知の事実は、認証の強度にはカウントされません
？しかし、携帯電話番号とメールアドレスあるユーザー名!!!!!!!!
パスワードは、高セキュリティ環境の完全なソリューションではありません。ただし、ユーザー名をオーセンティケータとして使用しようとしても、セキュリティは向上せず、他のものに危害を加えます。
以前はセキュリティを組み合わせていました。
たとえば、ユーザーのメールアカウントの場合：
- ID：[email protected]
- PASSWD：1z "1dgG" @ "é〜＃。
イントラネットのユーザーアカウントの場合、次のようになります。
- ID：1501823098（通常、自分のIDカードから独自のIDを使用するか、他の方法でできない場合はそのIDを生成します。）
- PASSWD：＃\ ed "1：！）3qs
イントラネット（またはインターネット）のユーザーアカウントをユーザーに知らせる問題は、ハッカーがブルートフォースでログインしようとすることです。パスワードが複雑な場合でも、辞書攻撃とブルートフォースは、接続や帯域幅の減少などに影響を与えます。
また、イントラネット/インターネットアプリケーション全体のユーザー名アカウントとパスワードに関するポリシーが1つしかないのは、竜巻に対してパンヘルメットだけで実行するようなものです。あなたは生き残ることができますが、それは自殺のようです！
3つの異なるアカウントIDと3つの異なるパスワードを学習する必要があるためにユーザーが文句を言う場合でも、ハッキングされている1つのアカウントを分離するのは簡単であり、ユーザーは数週間後に適応するので、作業ははるかに簡単になります。その方針に、あなたは本当によく保護された拠点を持っているでしょう。
少なくとも、それが私の仕事でしたことです。今でも、ユーザーはIDやパスワードを忘れたり、書き留めたりする傾向がありますが、それが問題なので、私は適切なセキュリティポリシーを確保するために仕事をしました。 （IDを提供するか、紛失した場合はパスワードをリセットできます。）
これがお役に立てば幸いです。
編集：
これに対する本当のコントロールは、パスワードの長さ、複雑さ、アカウントロックアウトポリシーです。
複雑で適切な長さのパスワードを使用すると、辞書に大きな欠陥が生じます。私は（自分用に）複雑で26文字の長さのパスワードを使用しています。辞書がそれをすぐに見つけられなくても、それは多くのネットワークプロセスを消費するでしょう。また、アカウントロックアウトポリシーを設定することをお勧めしますが、アカウントがロックアウトされると、ブルートフォーススクリプトは別のアカウントを試し、そのようにループします。少なくともアカウントが安全であっても、ネットワークの帯域幅は大幅に失われ、最悪のシナリオでは、すべてのアカウントがクラックされ、グローバルネットワークが停電する可能性さえあります。
一定時間（たとえば5〜30分）後に自動ロックを解除し、大量のロック解除機能を実行し、指数バックオフまたはIP禁止を一定の回数試行した後、選択的な自動化を解除することで、これを緩和できます。何回か失敗した後に表示されるコントロール（例：Captcha、Robooスクリプト）
そこでは、欠陥はユーザーです。さて、ユーザーは常にITの欠陥ですが、3週間の休暇後（私の仕事でN + 2 ...の実話で起こりました）にパスワードを忘れたユーザーを想像してみてください。アカウント、待って、もう一度試して、もう一度ブロックしてください。2回試した後、彼はモンゴルのライダーがヨーロッパに侵入するようにあなたにラッシュします！あなたは彼のためにこのルールを無効にする必要がありますが、あなたが例外を作ったという噂が広まり、他のユーザーは彼らのために同じことをしてほしいと思うでしょう。最悪の場合、ユーザーはあなたのところに来ませんが、同僚の1人のアカウントを使用します（IDとパスワードを書き留め、それらをデスクブロッターの下に大切に保管します）。
ユーザー教育、2番目の認証要素、適応認証（たとえば、デバイスID、場所などに基づくステップアップ認証または段階的認証）は、これに対するより良い防御になります。
まあ、私はこの点であなたに完全に同意します。私はセキュリティポリシーに関するユーザートレーニングを定期的に行っています。何が問題になっているのかを忘れないようにして、新しいユーザーをトレーニングしています。しかし、それは通常すべての会社であるはずです。
ユーザー名、ID、パスワードを認証と見なします。より強力な認証が必要な場合は、パスワードを長くするか、2つのパスワードを要求します。身元を明記する
識別は、純粋にユーザー/管理者に優しいものです。セキュリティを強化したい場合は、パスワードを長くするか、2つのパスワードを要求してもハッカーの邪魔になるだけです。ポリシーを強化する実際の方法（少なくとも私にとって）は、暗号化をアップグレードすることです（ハッシュmd5、RSAなど...）。私のN + 2は役に立たないと思っていましたが、セキュリティサーバーで重大なリークが発生した後、彼はそのように考えなくなりました（リークは彼の責任でした。理解するには2番目の回答を参照してください...）。セキュリティがあれば、気を付けることはできません。
あとは視点だけです。あなたの同僚は正しいと言う人もいれば、あなたが正しいと言う人もいます。私にとっては、両方の党が正しいと思います。あなたとあなたの同僚は、協力してトレードオフを見つける必要があります。
これがあなたの質問に答えたことを願っています。
簡単な答えは、ユーザー名を与えるとアプリケーションの安全性が低下することです。
他の認証要素のセキュリティを強化することについての議論は、何でもあります。
他の要素のセキュリティをさらに強化するために行うことは、ユーザー名を非表示にしたままでも実行できます。このアプリケーションが本当に大きな影響を与える場合は、ユーザー名のセキュリティがドアで許可されているかどうかについて考えられるすべての対策を実装することになります。
はい-全体的なセキュリティはバランスが取れており、実際のサポートコストを測定することによってのみ、ユーザー名を提供することが評判と予算に対する認識または計算されたリスクに値するかどうかを確認できます。
本当の問題は、ユーザー名フィールドを維持してCookieに格納するなどのエンジニアリングコストを負担するか、そうでなければその認証要素を提供する理由です。