web-dev-qa-db-ja.com

メール確認リンクでユーザーを認証しても安全ですか?

ユーザーがウェブサイトに登録すると、アカウントをアクティブにするために電子メールを確認する必要があります。

確認リンクをクリックすると、アカウントをアクティブにするためのワンタイムハッシュによってユーザーが識別されます。

ユーザーをすぐに認証しても安全ですか、それともアクティベート後にログイン/パスワードでサインインする必要がありますか?

提案された登録フロー:

  1. 登録フォームにログイン/メール/パスワードを記入
  2. ハッシュ付きワンタイムリンクでメールを確認する
  3. 電子メールが確認された(そしてアカウントがアクティブ化されなかった)場合、ユーザーを認証し、彼のアカウントへのアクセスを許可します

現在の登録フロー:

  1. 登録フォームにログイン/メール/パスワードを記入
  2. ハッシュ付きワンタイムリンクでメールを確認する
  3. 正しく確認された場合、ユーザーはメールアドレスまたはログイン名とパスワードを入力する必要があります

サイドノート:

  1. 電子メールにアクセスしている間、パスワードをリセットすることが可能です
  2. 登録フォームには、ログイン/メール/パスワードのみが含まれています
11
PeterM

メールを確認する理由によって異なります。その電子メールが後でパスワードのリセットに使用される場合、提案されたワークフローには重大なセキュリティ上の問題があります。次のシナリオを検討してください。

  • アリスは新しいアカウントを作成し、うっかりボブのメールを書きます(たとえば、彼女はメールをコピーして貼り付け、間違った行を使用しているとします)。
  • 邪悪なボブはメールを見て、アカウントを確認し、電子メールと異なる場合はアリスのログイン名を書き留めてログアウトします。
  • アリスは後で接続しようとし、すべてが正常に機能していることを確認します-彼女は検証が自動であると想定し、通常はしばらくの間自分のアカウントを使用しています
  • しばらくして、ボブはアリスのアカウントを使用して接続を試み、パスワードのリセットを求めます=>登録されたメールを所有しているため、パスワードの変更に成功しました
  • ボブは現在、アリスのアカウントを所有しており、彼女に代わって何でもできます!

わかりました、アリスは自分のアカウントを作成するときにそれほど用心深くありませんでしたが、提案されたワークフローは彼女を本当に保護しませんでした:

それが、私が好むワークフローが次の理由である。

  • ユーザーがログイン、パスワード、電子メールで新しいアカウントを作成できるようにします(ログインの可能性があります。できません)。>アカウントはアクティブ化されずに作成され、一定の期間(たとえば2日)以内にアクティブ化されない場合は破棄されます。
  • 特定のメールに固有の確認リンクを送信します
  • リンクは---(loginフォームを開きます-ユーザー名は事前に入力され、読み取り専用である必要があります。ユーザーが正常にログインすると、アカウントが検証され、リンクが無効になり、ユーザーはセッションを開始します。 3回試行してもパスワードが正しくない場合は、接続が切断されます。
  • ユーザーが検証されていないアカウントを使用して接続しようとすると、検証メールがそのアドレスに送信され、アカウントを検証するためにまだn日/時間あるというメッセージが表示され、ユーザーに提案する新しいメールアドレスでアカウントを再作成します。その場合、古い検証リンクはすぐに無効になります。

前のシナリオが発生した場合、ボブはアリスのアカウントを検証できず、後で自分のアカウントを盗むこともできません。

12
Serge Ballesta

「提案された登録フロー」では、アカウントを作成したばかりの人がリンクをクリックした人であると想定しています。この仮定は一般的に真実であり、このリスクを冒すだけの人々がいます。その後、これは、セキュリティとユーザビリティの間でどのバランスを求めているかという問題です(興味深い議論の主題:D)。

これの悪い点は、あなたの仮定が間違っている場合、誰かがログインし、これからフルアクセスを持つパスワードをアカウントにリセットし、ユーザーのメールアカウントを変更することさえできるということです。

「私の現在の登録フロー」を使用すると、セキュリティを強化しながら、ユーザーが数分前に行ったのと同じように、ユーザーに再度ログインするように強制するだけで、ユーザーに少し迷惑をかける危険を冒します。

私が行う方法は、登録時にユーザーに直接ログインして、ユーザーが実行できることを制限しながらセッションを開くことです。彼が自分のアカウントをアクティブにする必要があるよりも完全な機能を必要とする場合。メールのワンタイムトークンリンクをクリックした後、ウェブサイトにリダイレクトされます。開いているセッションがある場合はログインします(開いているセッションがあると、誰かが登録からメールを受け取る可能性があります。今は低いです)そうでない場合、彼は再度ログインする必要があります(彼のセッションがその間に期限切れになったため、これが私のユーザーではない可能性が高くなります)。

これがお役に立てば幸いです。また、公開した内容に何らかの意味があることを願っています。

ここで述べている問題は、セキュリティを最小限にして(少し)使いやすさを向上させるか、その間に何かを見つけるかということです。

2

これは、登録フォームに機密データが含まれているかどうか、および新しく作成されたアカウントが第三者にとって(それ自体または正当なユーザーになりすまして)何らかの価値があるかどうかによって異なります。

問題は、ユーザーが自分のメールアドレスを入力しているときに間違えた場合、登録リンクが未知の人に送信される可能性があることです。

  • 提案された登録フローでは、この不明な受信者は新しく作成されたアカウントにアクセスできます。
  • 現在の登録フローでは、このリンクはこの受信者にはほとんど役に立ちません。彼が実行できる唯一のアクションは、電子メールアドレスの「検証」です。

したがって、提案されている登録フローは、エンドユーザーに使いやすさの改善をもたらす可能性がありますが、セキュリティが若干低下する可能性があります。

2
WhiteWinterWolf

現在のフローは、次の理由で安全でないと見なすことができます。

  1. 他人の電子メールへのアクセスを(制限されていても)持つ敵は、それらに代わってアカウントを作成および使用できます。
  2. ここでの認証は、メールのセキュリティに完全に依存しています。メール、これが最も弱いリンクであり、それにアクセスすることで敵がアクセスすることができます。

提案されたフローでは、アカウントを作成した人とメールへのアクセス権を持つ人が同じであることを確認しているため、上記の問題は軽減されています。

あなたが言及した元のフローを使用する特定のアプリケーションを見てきました。彼らはそれを、受け入れられた電子メールをいくつかのドメインに制限する受け入れられたリスクと見なします。元のフローはユーザーフレンドリーで、セキュリティが少しトレードオフされています。

1
hax

それは場合によります。

電子メールが安全でないことは誰もが知っています。電子メールを安全にするためにできることはありますが、私が知っていることから、電子メールを使用する人はごくわずかであり、送信者と受信者の両方のアカウントで設定する必要があります。

@WhiteWinterWolfが言っているように、あなたはその電子メールを所有している誰にでもアカウントへのアクセスを与えています。昨日だけ、私は自分の電子メールアドレスを誤って入力しました。10年以上使用していて、その間に10,000回以上入力したに違いありませんが、それでも間違いがありました。したがって、そのような状況で発生する可能性がある場合、それはさらに多くの状況で発生する可能性があります。

最後に、あなたのランダムはどれくらい良いですか?推測できますか?私はあなたが使っている言語を知りませんが、あなたが思うほどランダムではないランダム関数があります。あなたが保護を加えることができるとき、あなたはそのランダムな機能にあなたのすべての信仰を入れてもいいですか?

また、これはUXではないことを知っていますが、ユーザーエクスペリエンスの点でユーザーに再度ログインしてもらうことにそれほど大きな損失はありませんが、予防策として、メール認証ページで登録ページによって生成されたCookieを確認することができます。登録と電子メール認証が同じブラウザで行われたことを示し、そのCookieが存在する状態でログインする必要をなくします。

1
Topher Brink

ほとんどのWebサイトでは、ユーザーはアカウントをアクティブ化した後にパスワードを入力する必要があります。それも必要ですか?

たくさん

誰かがあなたの電子メールを読むことができる場合、彼らはこの方法であなたのアカウントを引き継ぐことはできませんこれは事前共有された秘密に依存するため、パスワード

とても良い習慣です。

パスワードの変更などの主要なアクション(GitHubのSudoモードを参照)を実行するためにパスワードを要求するのと同様です。誰かがセッションをハイジャックしたり、単にコンピュータにアクセスしたりできる場合、提供されていないパスワードを必要とするため、多くのことはできません。

1