クライアントの1人からセキュリティ要件のリストが送られてきました。そのうちの1つは、登録にパスワードの設定が含まれていないことです。完了すると、一時パスワードがユーザーに送信され、ユーザーは最初のログイン時に一時パスワードを変更する必要があります。
私はこのフローをユーザーとして見つけたと思いますが、何がいいのかわかりません。ユーザーに実際のメールを使用するよう強制する場合、一般的な方法は、使用するメールに検証リンクを送信し、リンクのURLにアクセスするまでアカウントを非アクティブにすることです。
それで、新しく登録されたユーザーに一時的なパスワードを割り当てることには、実際のセキュリティ上の利点がありますか、それとも巧妙にしようとするITマネージャーだけですか?
あなたが説明する手順は、異なるコンテキストに適用される2つの異なる手順を融合したもののようです。
1。対象者の登録
登録は特定の個人向けであり、定義済みの物理的IDがあり、ユーザーが選択したパスワードの設定を許可しないプロセスで発生する場合があります。例としては、ある展示会で出会い、名刺を渡した人を「登録」する場合があります。あなたは彼のメールアドレスを知っていますが、登録が行われるとき、ユーザーはそこにいません。そのような状況では、彼にシステムに最初にログインする方法を送信する必要があります(少なくともある程度の認証が必要です-その人のためだけに全員のアカウントを作成する必要はありません)。彼自身のパスワードを選択することによる手順。
電子メールで送信され、最初の使用時に変更する必要がある(アプリケーションによって適用される)初期パスワードは、そのコンテキストに対処する1つの方法です。セキュリティの観点から、パスワードを選択できるページに移動する「一意の登録リンク」を送信すると、まったく同じになります。
これは理想的な状況ではなく、最初の資格情報は保護されずに移動する必要があります。最初の使用時にパスワード変更を強制することは緩和策です:はい、攻撃者could初期パスワード/検証リンクを傍受しますが、その後、彼自身がパスワードを選択する必要があり、少なくとも意図したユーザーは気づきます問題(メールを受信できない、またはログインできない)。
2。「誰でも」の登録
登録を使用するほとんどの展開済みWebアプリは、異なるコンテキストで機能します。いくつかの商品のWebベースのベンダーを検討してください(Amazonを考えてみてください)。ここでは、新しいユーザーとしてanybodyを受け入れます。ユーザーが自分のコマンドを追跡でき、他の人のコマンドを表示できないようにする必要があるため、ユーザーを「登録」する必要があります。
このような状況では、ユーザーは最初の登録時に利用できます。ユーザーはそれを開始し、その時点でキーボードのすぐ後ろにいて、HTTPSのカバーの下で選択したパスワードを入力できます。 Webアプリcanはうるさくないため、この種の登録を受け入れます。設計上、anybodyは登録する権利があります。
それでもメールで送信される「検証リンク」が必要ですが、非常に明確な目的のために、検証リンクはemail addressが本物であることを確認するために使用されます。その通信を傍受する攻撃者はあなたをだます可能性があります(つまり、彼が「所有していない」電子メールアドレスで登録します-ただし、そのアドレスに送信された電子メールを傍受できるため、ある程度所有しています)が、そのような攻撃者最初のコンテキストと同じものを攻撃しないでください。最初のコンテキストでは、攻撃者はログインする資格のあるユーザーになりすまします。 2番目のコンテキストでは、攻撃者はisとにかくログインする資格がありますが、他の誰かの電子メールアドレスを提供することに成功しました。
概要
実行している登録の種類に応じて、電子メールで1回限りの初期パスワードを送信することは、良いことでも悪いことでもあります。誰でもできる古典的なWebベースのアカウント作成では、これは悪いことです。特定の個人の登録については、初期パスワードからのパスワード変更の実施が適切です理由この場合、すでに電子メールで送信する必要があり、これはセキュリティ上の問題です(単に選択し、リスクを軽減する必要があります)。
セキュリティの観点からは、そのような行為は悪いものです。まず、パスワードはプレーンテキストでメールで送信されます。第二に、パスワードはアプリケーションに「知られている」。
ただし、開発の観点からは、このフローにより実装が簡単になります。別の「アクティベーション」フローは必要ありません。