ほとんどのログインフォームでuser&passを使用しています。
そして、一部の人はメールとパスに行きます。それらの長所と短所は何ですか?これが私が考えたことです。
メールのPROS
[〜#〜] cons [〜#〜]
Webアプリケーションの使いやすさは見逃してはならない重要なものであるため、これはプログラミングに関連していると思います。
もう1つ覚えておくべきことは、他のユーザーも「ユーザー名」を見ることができる場合、プライバシーの問題のためにメールアドレスを使用すべきではないということです。
OpenIDとOAuth .....見栄えがよくなりました。管理するユーザーがさらに少なくなり、変更時に1か所での移行が容易になります。
はい、注意する必要があります。バックアップのメールアドレス(追加のプロフィールフィールド)は、ユーザーが使用しているメールアドレスとは異なると主張します。多くのシステムには他にもいくつかのフィールドがあり、これらのフィールドを使用して、本当に毛深い場合に自分自身を認証することができます。ただし、この時点では、テクニカルサポートへの問い合わせが必要になることがよくあります。
システムの種類によっては、電子メールの使用がセキュリティ上の脆弱性になる場合があります。あなたのメールアドレスはわかりますが、ユーザー名プロンプトに何を入力するのかわかりません。ユーザー名を簡単に推測できることが問題であれば、メールアドレスは使用しません。
電子メールをユーザー名として使用するときに発生する可能性があるもう1つの問題は、「ユーザー獲得」攻撃です。たとえば、「メールの変更」ページがある場合、または新しいユーザーを作成する場合、新しいユーザーが既に存在するメールを挿入すると、アプリケーションはエラーを返す必要があります。その結果、攻撃者は簡単なスクリプトを実行することにより、アプリケーション内のすべてのユーザーを発見できます(ユーザーが存在しない場合は、追加されます)
セキュリティが懸念される場合、短所は長所を上回ると思います。多くの企業はメールアドレスをリサイクルしているため、ユーザーがメールアドレスを使用しなくなった(メールアカウントを削除した)場合、他のユーザーが使用できるようにリサイクルされる可能性があります。
その場合、他の人はあなたの組織から定期的に連絡を受けることがあります。これにより、新しいユーザーは、以前のアカウントのユーザーが組織にログインしていたことを知ることができます。セキュリティに関する質問などの追加のチェックを行わずに、単純な電子メールベースのパスワードリセットを使用する場合、彼らがする必要があるのは、現在所有している電子メールアドレスを使用してパスワードを回復することだけであり、彼らはその人のアカウントにアクセスできます。
銀行向けにプログラミングしていないことを願っています。 USBank.comはメールではなくユーザー名を使用します。私も信用組合のアカウントを持っています。彼らは電子メールも使用せず、代わりにアカウント番号を使用しています。これらはリサイクルされません。
セキュリティを優先する場合は、電子メールを使用しないでください。
メールアドレスを変更する手段を提供する限り、メールは適切なユーザー名になります。 LinkedInは、ユーザー名としてメールを使用してアカウントを作成するときにこれを提供します。また、ログイン後、メインのメールアドレスを変更して、ユーザー名をそのメールアドレスに変更することもできます。
あなたがこのようなことをしている限り、あなたはすべて準備ができているはずです。
私はこれをb2bアプリで実行しました。ユーザーがクライアントの会社を辞めたとき、他の誰かが古い非アクティブ化された電子メールアドレスをログインとして使用し、意図的にそれを変更せずに私たちからの電子メールを受信しないようにするのは本当に大変です。
最終的には、パスワードをリセットするメールが返送され、問題を修正するための電話が返送されてサポートされます。
メール(プロ)-メールを送信してアカウントを確認できるため、アカウント作成のスパムを減らします。
アカウントの公開を許可する場合のもう1つの注意事項は、ユーザー名を必要としないことは「表示名」を許可する必要があることを意味します(確かにメールアドレスは表示しません)が、ユーザーが実名混乱を引き起こす可能性のある重複した名前の可能性があります(写真と同じ名前の2つのSOコメント投稿者を考えてください。あなたがクリックして完全なプロファイルに移動しない限り、それは同じ人物であると想定されています) 。その場合は、一意の表示名(実際の名前を使用できないようにする)を強制するか、混乱している2人のボブジョンソンがぶらぶらしていることを受け入れる必要があります。
欠点:Webサイトや電子メールなどのアプリケーション間でユーザー名を共有する必要がある場合、セキュリティ上の問題が発生する可能性があります。たとえば、電子メールがユーザー名に使用されている場合、Webサイトのユーザー名にアクセスできるユーザーは、電子メールアドレスにもアクセスできます。通常、これは問題ではありませんが、問題である可能性があります。一般的なログイン手順がない場合、またはセキュリティが重要でない場合を除いて、アプリケーション間でユーザー名とパスワードを分離しておくことは、一般的に適切なポリシーです。
CON:ユーザーとスパマーの間の絶縁層が1つ少なくなります。どういうわけか、誰かがユーザー名の完全なリストを入手した場合、彼らはすべてのユーザーをスパムすることができます。ただし、サイトがユーザー名を使用し、メールがセカンダリフィールドである場合、これは問題ではありません。
もちろん、すべてのユーザーデータを取得しない限り、とにかくそれははるかに大きな問題です。
会社の所有権の変更により変更が義務付けられる前に、Arena Solutionsの「Product Lifecycle Management」ソフトウェアを使用しました。これは、すべての機密企業データがオフショアのどこかでホストされていて、ブラウザからどこからでもアクセスできる取引の1つでした。
Arena PLMは非常に安全であると宣伝されていましたが、(デフォルトの)動作では、ユーザー名としてメールアドレスが必要でした。有効期限のある強力なパスワードが許可されていましたが、パスワードの有効期限が切れると、別のパスワードを選択するか、古いパスワードをそのまま使用し続けるように言われました。
セキュリティの主張はデータ転送にSSHを使用することに基づいていると思いますが、私には断固とした人物がログインできると思われました。
もちろん、強力なパスワードの使用と更新強制する必要がありますです。
メールアドレスを使用すると、たとえば、pwng0d69をJon Skeetとして認識させたい場合など、メンバーがユーザー名を変更するのが簡単になります。ただし、自分のメールアドレスを要求するサイトごとに、個人的には別の潜在的なスパムの送信元にうんざりしています。
Open IDを使用:)
PRO:一部のサービスでは、電子メールをネット上の特定のユーザーを識別するための標準にすることを検討しているようです。
CON:これはまだ起こっていません。OpenAuthやOpenIDなど、他にもたくさんのオプションがあり、現在サポートされています(Facebookスプレッドを使用してログインすることもできます)。
アプリのターゲットユーザーが何であれ、IDの選択を調整してください。