当サイトでは、ユーザーの個人情報（フォームから提供）に基づいたシミュレーションをユーザーに提供しています。ログイン/パスワードアカウントの作成を強制することなく、後でシミュレーション結果に戻ることができるようにしたいと思います。
私たちは、彼らが結果を取り戻すことができるリンクを含む電子メールを彼らに送ることを考えました。ただし、個人データが危険にさらされているため、当然、このURLを保護する必要があります。
そのため、URLでトークン（文字と数字の40文字の組み合わせ、またはMD5ハッシュなど）を渡し、SSLを使用する予定です。
最後に、次のようなメールが届きます。
こんにちは、https：//www.example.com/load_simulation？token = uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXnで
結果を取得して ください
あなたはそれについてどう思いますか？それは十分に安全ですか？トークンの生成について何をアドバイスしますか？httpsリクエストでURLパラメータを渡すのはどうですか？
回答:
SSLは、転送中のクエリパラメータを保護します。ただし、電子メール自体は安全ではなく、電子メールは宛先に到達する前に任意の数のサーバーに沿ってバウンスする可能性があります。
また、Webサーバーによっては、完全なURLがログファイルに記録される場合があります。データの機密性によっては、IT担当者がすべてのトークンにアクセスできないようにする場合があります。
さらに、クエリ文字列を含むURLがユーザーの履歴に保存され、同じマシンの他のユーザーがURLにアクセスできるようになります。
最後に、これを非常に安全でないものにしているのは、URLが、サードパーティのリソースを含むすべてのリソースに対するすべてのリクエストのRefererヘッダーで送信されることです。したがって、たとえばGoogle Analyticsを使用している場合は、URLトークンをGoogleに送信します。
私の意見では、これは悪い考えです。
そのためにクッキーを使います。ワークフローは次のようになります。
ここで、ユーザーは別のマシンで別のブラウザーを使用したいと考えています。この場合、「転送」ボタンを提供します。ユーザーがこのボタンをクリックすると、「トークン」を取得します。彼女は別のコンピューターでこのトークンを使用してCookieをリセットできます。このようにして、ユーザーはトークンを転送する安全性を決定します。
SSLは転送中のデータの内容を保護しますが、URLについてはよくわかりません。
とにかく、攻撃者がそのURLトークンを再利用するのを軽減する1つの方法は、各トークンが1回だけ使用できるようにすることです。正当なユーザーがリンクを引き続き使用できるようにCookieを設定することもできますが、最初のアクセス後は、Cookieを持っている人に対してのみ機能します。
ユーザーの電子メールが危険にさらされ、攻撃者が最初にリンクを取得した場合、まあ、あなたはうんざりしています。しかし、ユーザーにはさらに大きな問題もあります。
電子メールは本質的に安全ではありません。誰かがそのリンクをクリックしてデータにアクセスできる場合、あなたは実際にはそれを保護していません。
トークンはSSLを介して渡されるときに安全です。あなたが抱える問題は、URLを表示できることで、人々（意図されていない人々）が利用できることです。
SSNのような個人情報の場合、メールでURLを送信することはないと思います。むしろ、サイトのユーザー名とパスワードを作成してもらいたいと思います。あなたと彼らにとって危機に瀕しているその種の情報で電子メールを危険にさらすのは簡単すぎます。誰かのアカウントが侵害された場合、それは実際にそのせいであるという疑問になります。厳密にCYAの観点から見ると、安全性が高いほど優れています。
深刻なプライバシーの問題がある状況では、それほど安全だとは思いません。（おそらくクリアテキストの）電子メールでURLを送信しているという事実は、はるかに弱いリンクです。その後、トークンに対するブルートフォース攻撃のリスクが発生します。これは（実際の認証メカニズムの構造が欠如しているため）、適切に構築されたユーザー名とパスワードの設定よりも脆弱である可能性があります。
ちなみに、httpsリクエストのパラメータにはまったく問題はありません。
そのままでは悪い考えです。簡単な使い方でセキュリティを怖がらせます。前に述べたように、SSLはサーバーとクライアントブラウザ間の情報転送のみを保護し、中間者攻撃のみを防止します。電子メールは非常に危険で安全ではありません。
情報にアクセスするためのユーザー名とパスワードの認証が最適です。
私は多かれ少なかれクッキーのアイデアが好きです。Cookie情報も暗号化する必要があります。また、攻撃の可能性を制限するために、ソルトとキーフレーズに加えて$ _SERVER ['HTTP_USER_AGENT']を使用してトークンを生成する必要があります。検証に使用するために、クライアントに関する機密性の低い情報をCookieにできるだけ多く保存します。
キーフレーズは簡単に使用できるようにCookieに保存できますが、Cookieも盗まれる可能性があることに注意してください=（。
クライアントが提供したキーフレーズを入力できるようにすることをお勧めします。キーフレーズは、データとともにデータベースにも保存されます。
または、ユーザーが$ _SERVER ['HTTP_USER_AGENT']パラメータが異なる別のマシンを使用している場合や、単にCookieを見逃している場合に、キーを使用できます。そのため、Cookieを転送または設定できます。
また、機密データがデータベースで暗号化されていることを確認してください。あなたは、決して知らない ;）
ハッカーがデータベースにアクセスした場合、多くの個人情報を自由に提供できることをご存知ですか？
その後、これはアイデアとして悪くはないと思います。MD5またはSHA1はハッシュに対してあまり安全ではないため、使用しません。それらは非常に簡単に「復号化」できます（暗号化ではないことはわかっています）。
それ以外の場合は、電子メールのようなパスワードでは送信されない2番目の情報を使用する可能性があります。理由は非常に単純です。誰かがユーザーの電子メールにアクセスできる場合（セッションを強制終了しない場合はhotmailを使用すると非常に簡単です）、ユーザーが送信したすべての情報にアクセスできます。
HTTPSは、サイトからエンドユーザーに送信されるデータを保護および暗号化することに注意してください。他に何もありません、それを安全なトンネルとしてとってください。これ以上のことはありません。
私があなたの考えを理解していることから、理論的には誰かがランダムな40文字の文字列またはMD5ハッシュを入力して、他の誰かの詳細を取得することができます。これはほとんどあり得ないかもしれませんが、一度だけ発生する必要があります。
より良い解決策は、ユーザーにトークンを送信してから、名前、郵便番号、社会保障番号、またはこれらの組み合わせなどの詳細の一部を入力するようにユーザーに依頼することです。