web-dev-qa-db-ja.com

メールでのログインはユーザー名より安全ですか?

私のWebアプリケーションの設計では、セキュリティのためにメンバープロファイルの最終ステップを選択しようとしています。 *ユーザー名または電子メールでログインするシステムを使用する必要があるかどうかを選択する必要があります。

現在のメンバーのテーブルデザインでは、次のように設定しています。

  • メンバーIDは8桁でランダム化されます。
  • 歓迎されたときに表示するnicknameがあります。例えば。ようこそ、 $nickname
  • パスワードはbCryptを使用して暗号化されます。

Webアプリケーションの設計に追加したセキュリティに加えて、どちらがより安全ですか?ユーザー名とパスワード、またはメールとパスワード?

また、メールやパスワードの新しい基準あるも知っています。

3
Traven

それらに選択を与えなさい。たとえば、電子メールアドレスはかなり長いですが、通常は短いユーザー名を選択します。ログインフォームを作成して、両方を受け入れることができます。

ユーザー名はアカウントを保護するためのものではなく、パスワードは安全のためのものです。ブラウザーに入力したときにユーザー名が表示されるのは当然のことですが、パスワードは非表示です。また、ユーザーはしばしばユーザー名を再利用しますが、パスワードの再利用とは対照的に、これは問題にはなりません。そしてもちろん、電子メールアドレスは誰とも共有されるべきではありませんでした。

しかし、主な問題:ログイン以外の目的で使用したいので、ハッシュ化/暗号化されたユーザー名または電子メールアドレスを保存しないでください。ハッシュ化されたパスワードでデータベースを盗んだ場合、ユーザー名とメールアドレス。 「セキュリティ上のメリット」はなくなりました。

したがって、ユーザーにonly電子メールアドレス(およびパスワード)またはonlyユーザー名(およびパスワード)は意味がありません。

防御策としては、強力なパスワードを適用し、強力なパスワードハッシュ関数を使用してパスワードを暗号化する必要があります。 cost十分に高い値 を設定することを忘れないでください。

さらに、データベースを盗まなかった攻撃者がボットネットを貸し出し、脆弱なユーザーパスワードを総当たりすることを防ぐために、IPアドレスごとに1時間あたりのログイン試行回数を制限します。また、アカウントのログイン試行が多数発生する場合は、過去にアカウントのログインが成功していないIPアドレスからのログイン試行をブロックします。

7
user2428118

ブルートフォーサーが攻撃を実行する前にユーザー名を必要とするため、ユーザー名を持つことは電子メールよりも不明瞭になり、セキュリティが提供されます。

電子メールは、電子メールほどユーザー名ほどあいまいではありません。ユーザーは、他のすべてのアカウント登録、ニュースレターの購読で自分の電子メールを使用するか、誰かに連絡してもらうためにどこかにそれを投稿することさえあります。ハッカーが少し調査したり、あなたを知っていたり、ソーシャルエンジニアリングを通じて何らかの形であなたの電子メールアドレスを入手したりした場合、ブルートフォース攻撃やパスワードを推測する可能性が高くなります。

ハッカーは攻撃を行うためにユーザー名とパスワードの両方を知っている必要があるため、ユーザー名はこの方法でより多くのセキュリティを実装します。ユーザー名を取得するよりも、正当な理由でメールアドレスを取得する方が簡単です。 「ユーザー名を友達リストに追加する」などの機能がある場合は、代わりにメンバーIDによる追加を実装することができ、ログインには使用されません。

メールを所有して使用している私たちのほとんどはメールアドレスを覚えていることが多いので、メールアドレスは1つ少ないことを覚える必要があるため、ユーザーにとって便利です。セキュリティと便利さは常にお互いのトレードオフです。

また、ユーザー名をわかりにくくするために、ログインに失敗したときに「ユーザー名が存在しません」などのメッセージが返されないことを確認してください。 「ログイン失敗:ユーザー名/パスワードを確認してください」のようなものを返します

ほとんどの銀行は、認証に電子メールアドレスを使用していないことを知っています。ユーザー名を使用する方が不明瞭になるため、ユーザー名を使用します。この場合、ユーザー名は「パスワード」の別の形式と考えることができます。暗号化されておらず、画面を覗くと他のユーザーがプレーンテキストで表示できるため、安全性の低いパスワードです。

6
Sky

ユーザー名などを秘密にすることで得られるものはほとんどありません。適切なパスワードポリシーを適用している限り、ユーザー名が公開されているかどうかにかかわらず、ブルートフォース攻撃は効果がありません。攻撃者がキーロガーやパケットスニッフィングを介して何らかの方法でパスワードを傍受した場合、秘密のユーザー名も傍受できます。

この問題は、使いやすさの点でよりよく考えられています。ユーザーにメールアドレス、ニックネーム、秘密のログイン名、パスワードを覚えさせますか?単純にする。

3
user2675345

多くの人は同意しませんが、ユーザー名はメールアドレスよりログインの方が安全であると私は主張します。

1)パスワードをハッシュする必要があるのと同じ方法でデータベース内のユーザー名をハッシュしない理由はないので、データベースのクラック引数は議論の余地があります

2)人の電子メールアドレスは、実質的に公の知識です。さらに、それはすでに悪者の手に渡っている可能性があります...あなたのスパムフォルダはそれを証明するはずです。 2つの秘密は1つより優れています。

3)弱いパスワードを選択しないように、パスワードマネージャーの使用を奨励する必要があるOR弱いユーザー名。簡単に思い出せるのであれば、どれほど安全か?

4)残念ながらログイン時にメールが必要なサイトは、実際のメールに転送するサイト固有の「ログインのみ」のメールを作成する非常に良い理由です。繰り返しになりますが、パスワードマネージャーはこれらをユーザー名のように扱うことができ、すべてをまっすぐに保つという面倒を自動化します。さらに、別のフィールドとして電子メールをキャプチャすることを怠った場合、ログイン専用の電子メールアドレスが誰に誰に漏洩したかが正確にわかります。

5)適切に保護されたユーザー名は、特定の電子メールアドレスを制御できなくなる可能性があるため、信頼性が高くなる可能性があります。

2
user127

古い質問ですが、質問はsecurityについてであり、convenienceではないので、私はこれらすべての答えには1つの重要な側面が欠けていると感じてください:列挙攻撃。パスワードおよび/または別の2番目の要素は、ユーザー名/メールではなく、前述のuser2428118としてユーザーを認証するために使用されるものであることには同意するので、これについては説明しません。また、データベース違反が発生した場合でも、ユーザー名も電子メールも、どちらもプレーンテキストで保存されるため、安全ではありません。

ただし、これらの質問のどれも sername / email 列挙型ではないというセキュリティの側面があります。アプリケーションのセキュリティにおいて、私たちの目標は、ハッカーがシステムに侵入するのに役立つハッカーの知識を最小限に抑えるか排除することです。アカウントに使用されているユーザー名またはメールアドレスを特定できる場合、そのアカウントはハッカーが知らないアカウントよりも安全性が低くなります。

認証にusernamesを使用する場合、ユーザーがサインアップするときに、目的のユーザー名が既に使用されていることをユーザーに通知する方法が必要です。ハッカーはこれを利用して、特定のユーザー名がすでに存在するかどうかを判断できます。ユーザー名がわかっていれば、以前のデータベース違反で最もよく使用されているパスワードを使用してログインできるため、これは悪いことです。これらの一般的なパスワードは すぐに利用可能 オンラインです。

ただし、代わりにEメールアドレスを認証に使用する場合、新しいアカウントを追加し、Eメールがすでに存在する場合は、代わりにユーザーにパスワード再設定Eメールを送信します新しい登録メールの。ただし、UIでは、ユーザーに電子メールアドレスを確認して詳細な手順を確認するように伝えますが、そのアドレスが有効かどうかは示しません。

Eメール

  • ハッカーは、yourname @ company.comまたは他の一般的に使用されるアドレス(admin @ company.com、info @ company.comなど)を使用するか、Webフォームに記入して、返信メールにアドレスを使用することにより、名前に基づいて推測できます認証を試みます。ただし、ユーザーは通常、必要に応じて任意のメールアドレスを自由に選択できます。また、サインインしているユーザーは、必ずしもログインしているWebサイトに関連付けられている、または採用されているとは限らないため、この場合、@ companyはありません。 company.com Webサイトにログインしている.com電子メールアドレス。
  • 列挙攻撃を防ぐことができます。

Username

  • オンラインで表示されることもあります(例:"This post was created by {{username}} on {{date}}")メールがプレーンテキストで表示されないようにしてください。
  • 列挙攻撃を防ぐことはできません
  • ユーザーが単純なユーザー名(例:名)を選択することが多いため、辞書攻撃に対してより脆弱です。

ボーナス:とはいえ、ハッカーがシステムにユーザー名または電子メールが存在するかどうかを確認するもう1つの(より難しい)方法は、ログインを試みることです。ページの応答時間を確認します。最高のセキュリティガイドラインは、パスワードを低速ハッシュでハッシュすることを示していますが、ユーザー名または電子メールがデータベースに存在しない場合、一致するユーザーがいないため、パスワードハッシュを検証する必要はありません。ハッシュの実行に100ミリ秒かかり、データベースクエリに5ミリ秒かかる場合、有効なユーザーに対する要求の応答時間は、平均して、無効なユーザーよりも95ミリ秒遅くなります。これを回避する方法は、ユーザーがデータベースに存在しない場合でも、ユーザーが存在する場合でも、提供されたパスワードを常にハッシュすることです。その場合、データベースでハッシュを確認するだけです。

1
Mike

適切なHTTPSやその他のセキュリティメカニズムを使用している場合、セキュリティの点ではそれほど大きな違いはありません。しかし、ユーザー名が複雑すぎる場合、ユーザーはそれらを付箋に書いてデスクトップに(おそらくパスワードを付けて)配置しようとする可能性があります。それほど複雑でないもので行ってください。

2要素認証を使用できる場合は、セキュリティが大幅に向上します。

0
Kasun