登録時のパスワードのベストプラクティスは？

Question

ユーザーがアカウントを登録するウェブサイトを持っています。登録フィールドのフォームフィールドは次のとおりです。

名前
Eメール
Eメール確認
Username

ただし、パスワードフィールドはありません。送信ボタンを押すと、LHJVjhwnv％uu5またはRbWM9！jeDZUQbなどの非常に複雑なパスワードがメールで送信されます。

代わりに、ユーザーが登録フォームで自分のパスワードを設定できるようにすることを開発者に呼びかけました。フォームでそのパスワードを確認し、指定された電子メールへの確認リンクが送信されます。その後、この方法で、少なくとも自分のアカウントにログインし、確認リンクを介してメールを確認できます。または、そうしなかった場合、サイトにログインするたびに、メールの確認などを促すことができます。そうしないと、サイトで多くのことを実行できなくなります（例）。このように、たとえ取得しない確認リンクであっても、それでもアカウントのメールを別のメールに更新そして再送させるができます。少なくともこの段階では、まったくないではなく、自分のアカウントにログインできます。

開発者からの返事は以下の通りです

「登録時にパスワードを提供する際の問題は、大量の偽のアカウントが作成されることです。したがって、存在しないメールアドレスで登録するだけのユーザーです。少なくとも、ユーザーが存在することを証明するメール検証で、特定の範囲。間違ったメールアドレスで登録した場合は、再登録できます。」

開発者が採用している現在のアプローチが受け入れられるかどうかすべてにお聞きしたいと思いますか？

そうでない場合、開発者に変更を促すために使用できるいくつかの良い理由は何ですか？ "

私は以下を説明しようとしました

登録する9〜10人が毎日そして次に直接「パスワードリセット」フォーム直後を使用します。このフォームには、ユーザーがサインアップしたメールアドレスを入力してから、新しいパスワードを設定するためのリンクをメールで送信します。彼らが新しいパスワードを設定している場合とにかくの場合、なぜ登録フォームの最初の場所にそれを設定させないのですか？登録直後に、毎日9〜10人がパスワードリセットフィールドを使用するのはなぜですか。メールで送られてきて、キーや文字が欠けている、またはコピー/貼り付けなどを認識していないように見える、これらの複雑なパスワード（私は反対ではない）と格闘しているようです。それ。初回だけで自分のパスワードを設定できれば、電子メールで送信されたパスワードが機能しないため、直後にパスワードリセットフィールドに移動する必要はありません。毎日パスワードリセットのメールが届くのは変だと思った。万人向けではありませんが、私がMandrillappを使用して送信メールを追跡し始めて以来、1日あたり9〜10人の優れたユーザーがいます。これは次のポイントでバックアップされます。
毎日、少なくとも2〜3人が、受け取ったパスワードが機能していないことを連絡フォームに記入しています。自分で設定できれば、すべて回避できます。連絡しなくて済むことさえあるかもしれません。
8000近くのアカウントのうち、50％がログインしたことがありません。私の疑いは、パスワードを含む登録メールがジャンクフォルダー/スパムフォルダーに移動することです。これは、SPF、DKIMなどが適切に設定されているにもかかわらずです。 2か月前、マンドリルを使用してメールを送信し、受信トレイに確実に届くようにすることを決めましたが、1日あたり1〜2人がメールを受け取ったと言っていますnotメールを受け取っています。それは私を困惑させます。自分のパスワードを定義できれば、パスワードをメールで待ったり、完全に取得したりする必要はありません。これは私の最初の懸念をさらに際立たせます。

お時間をいただきありがとうございます！

Stephane · Answer

開発者は、パスワード登録、電子メール検証、ロボット検出の3つの異なるプロセスを1つに混合しようとしています。残念ながら、これにより、セットアップ全体のセキュリティと復元力が本来よりも低くなります。

電子メールはクリアテキストであり、今日では永遠に存続し、いくつかのインデックスに含まれ、多くの場合、途中で複数のサーバーに長期間保持されることがほぼ保証されています。電子メールで誰かにパスワードを送信した場合、あなたはそれを非常に脆弱にしていると確信しています。電子メールは、明示的に保護しない限り安全ではありません（S/MIMEまたはPGP）。
メールは同期プロセスではありません。メールがターゲットに到達するための最小時間はありません。実際、メールが最終的なメールサーバーを通過するまでに数分かかることがよくあります。これにより、プロセス全体が遅くなり、エンドユーザーに不便になります。
メールの信頼性はそれほど高くありません。ご存知のように、メールはさまざまな理由で、誰にも通知されずに失われる可能性があります。そのため、初期接続情報などの重要でタイムクリティカルな情報を送信するための非常に貧弱な媒体になっています。
ロボット検出の場合、このプロセスは恐ろしく非効率的です。このプロセスを回避するために簡単に使用できる大量の使い捨てメールサービス（またはキャッチオールメールドメイン）があります。

現在、これを行う「正しい」方法はありません。最も効果的に機能する方法は、必要なセキュリティのレベルと使いやすさに対する重み付けに大きく依存します。銀行のWebサイトのセキュリティを設計することは同じではありません。クッキングレシートリポジトリよりも。

ただし、システムを設計するときはこれらのことを覚えておくことが重要です（そして一貫性を保つことは、私の意見では、あなたが抱えている問題です）。

ターゲットオーディエンスは何ですか。これにより、ユーザーにとって登録プロセスをどの程度複雑にできるかがわかります。
ユーザーにとってあなたのウェブサイトへの登録の価値は何ですか？これにより、彼らにどれだけの努力が期待できるかがわかります。
登録の価値は何ですか。登録の詳細を確認するためにどの程度の労力を費やすべきかが示されているはずです。
潜在的に敵対的な第三者の登録の価値は何ですか。ユーザー情報が安全であることを確認するためにどれだけの努力が必要かを教えてくれるはずです。

[〜＃〜] owasp [〜＃〜] には、安全な認証プロセスの要素を説明するチートシートがあります。彼らの認証へのガイドは主題に少し軽いですが、それはそれを正しく行う（またはそれを間違って行わない）方法についていくつかの良い要素をもたらします。

rosenfeld · Answer

これは私に尋ねると複雑な問題です。

サインアッププロセスの登録フォームに誰かがパスワードとユーザー名を事前に入力してすぐに機能することを許可する場合、何らかの理由でユーザーに通知するときに問題が発生します。提供された電子メールのメッセージ。これが発生する理由はいくつかあります。

ユーザーが間違った電子メール（タイプミスまたはその他の理由）を通知した。
メッセージはSPAMフォルダーに送られます。
あなたのシステムは、ユーザーがメッセージを送信することを承認されていません。一部の電子メールプロバイダーは、ほとんどのメッセージを保護するために、メッセージを配信するための手順を説明する電子メールで自動的に返信するシステムを備えていますスパム。たぶん、ユーザーはいくつかの送信者からのこれらのステップを必要としないためにいくつかの例外を設定する必要があるでしょう。
メールボックスがいっぱいです。

理由が何であれ、ユーザーがアプリケーションにアクセスできるようにするためにアプリケーションが電子メールの検証を必要とする場合、システムがユーザーにメッセージを配信できない可能性は低くなります。無効なユーザーに複数の電子メールを送信すると、電子メール配信システムに自動的にスパムのフラグが付けられる可能性が高くなる可能性がありますが、これは望ましくありません。

考慮すべき別の問題があります。タイプミスが原因でユーザーが別の有効な電子メールを提供した場合はどうなりますか？次に、これらの迷惑なメッセージをすべて受け取る別のユーザーがいます。または、他のユーザーが望めば、そのアカウントを引き継ぐこともできます。これらは、電子メールの検証が必要な理由の一部です。

したがって、ユーザー認証の1つの方法は、サインアッププロセスの最初のステップでユーザーの電子メールアドレスを要求することです。アプリケーションに登録するユーザーの邪魔にならないように、他に何も要求しないでください。メールアドレスだけです。次に、生成されたランダムトークンのリンクが数分間有効になります。ユーザーがリンクをクリックすると、登録の次のステップに移動し、その電子メールに確認済みのフラグが付けられます。

このアプローチで考慮すべき点は、誰かが意図的にまたは意図せずにこれを使用して、ユーザーが要求していないサインアップを続行するように求める迷惑なメッセージをスパムすることです。それを防ぐ方法はわかりませんが、これらのメッセージをレート制限することをお勧めします。たとえば、トークンは10分間有効で、有効な間、システムは別のトークンを電子メールで送信しません。これらのユーザーは、10分ごとにメッセージに悩まされる可能性がありますが、そのようなケースが発生した場合は処理したいと思うかもしれません。

回復のためにパスワードを電子メールに送信する理由はまったくありません。代わりにトークンを使用する必要があります。その後、アプリケーションはパスワードを要求できます。ユーザーの電子メールアドレスが有効であれば、ユーザーを認証するためにパスワードは実際には必要ないことに注意してください。パスワードを提供しなくても、サインインするときに常にトークンを要求できます。

サインアップの完全なフォームを前もって表示したい場合は、メッセージを配信できるようにするために、ユーザーに電子メールアドレスの確認を要求する可能性もあります。この方法では、システムは未確認の電子メールアドレスにメッセージを送信しようとすることはありません。ユーザーがアプリケーションを使用しているときはいつでも、通知アイコンが表示され、メールアドレスがまだ確認されていないことをユーザーに思い出させることができます。 Eメール。

また、認証のためにユーザー名の代わりに電子メールを提供できるように電子メールアドレスに一意の制約を設定する場合、ユーザー名は実際には必要ないことに注意してください。アカウントごとに複数の電子メールをサポートするために、電子メールアドレスを別のテーブルに保持したい場合があります。