シナリオ
1人の顧客がユーザーの問題に直面しています。彼らは(ウェブ)サービスを年に数回使用しており、資格情報を頻繁に忘れます。標準のパスワード回復手順がありますが、それらの多くは、毎回カスタマーサービスに電話するだけです(所定のパスワードを生成するように要求します)。これにはいくつかの悪い影響があります:
ご了承ください:
質問
これらの問題を解決するために、ユーザーがユーザーごとに一意のIDを生成するように求められている場合、このIDをURLに追加して、そのユーザーを自動的に認証することができます。例えば:
http://www.example.com?user=abcdefg12345
ユーザーは、このIDを好きな場所に保存することを決定できます(デスクトップ上のリンク、ブラウザーのお気に入り、ポストイットにそれを書き留めます)が、お客様自身はその責任を負いません(「覚えておく」機能を提供できないため、法律の)。
私は認証トークン(前述のように、ユーザー名+パスワードタプルの代わりにCookieとして保存されます リクエストごとにユーザー名/パスワードの代わりに認証トークンを使用するのはなぜですか? )ではなく、URLパラメーターについて話しているのではありません。
仮定:
他に考えられないセキュリティ上の懸念はありますか?これにより認証が弱くなりますか?
私が考えることができる考えられる問題は、URLがブラウザの履歴に保存されていることです...
[〜#〜]編集[〜#〜]
もう少しコンテキスト:顧客は、ユーザーに関連付けられた固定(変更不可)トークンの独自のリストを保持します。彼らが彼のサービスを使用する必要がある直前に、彼は彼らに言及されたリンク(バッチで生成された個人化された電子メール)ですべての電子メールを送るでしょう。私の例では、プロトコルはHTTPですが、実際にはHTTPSです(これを制御できない場合でも)。
追加の質問:このトークンは一時的に役立ちますか?新しい電子メールが送信されるたびに、新しいトークンが生成されます(有効期限は比較的短く、1週間または2週間です)。
大きなランダムトークンのエントロピーは、トークンが認証の安全なメカニズムであることを示唆していますが、それに関連する多くの問題があります。
あなたが指摘したように、顧客にパスワードを変更するためにカスタマーサービスに電話をかけることは2つの重要な問題を持っています:
カスタマーサービスによるパスワードのリセットを許可すると、アプリケーションのセキュリティにどのように影響するかを検討します。
パスワードを変更する必要があるお客様は、既存のWebアプリケーションを使用してパスワードのリセットを要求する必要があります。これにより、アカウントが登録されている電子メールと、オプションで一連のセキュリティ質問(独自のリスク評価に応じて)を要求する場合があります。次に、ランダムトークンを含むパスワードリセットリンクがその電子メールアドレスに送信されます。このリンクは1回だけ有効で、使用しない場合はしばらくすると期限切れになります。ユーザーがリンクをクリックすると、認証されます。ほとんどのWebアプリでは、この時点でユーザーがパスワードを設定します。あなたのケースでは、とにかくパスワードを忘れてしまうので、ユーザーがパスワードの設定をスキップできるようにすることをお勧めします。
カスタマーサービスに電話してパスワードをリセットする場合、パスワードリセット機能を使用するように指示する必要があります。カスタマーサービスの担当者が電話に留まり、手順をお客様に説明する場合がありますが、重要な点はお客様が自分でリセットを行います。 顧客が自分でパスワードをリセットすると、再度電話をかける可能性が低くなります。
これは、パスワードをGETパラメータとして渡すこととほぼ同じですが、これは不適切です。ここで説明します: GETとPOST Webアプリケーションのセキュリティの違いはありますか?
また、サンプルURLではHTTPSを使用していません。ネットワークを介して平文でパスワードを送信することも、明らかな理由で悪いことです。
次に、侵害された場合にユーザーはトークンを変更できますか?彼らはこのトークンを失うことはありませんか?つまり、パスワードを書き留めることもできます。
別の方法として、HTTPS経由の基本認証を使用できます。これは標準の認証手法であり、 https:// user:[email protected]/ などのURLの形式で記述できます。ブックマークとして保存されることはないと思いますが、ほとんどのブラウザーは「これらの資格情報を記憶する」機能を提供する必要があります。
提案されたスキームは基本的にOWASP 2番目に最も危険なWebアプリケーションのセキュリティ問題に対応します: 壊れた認証とセッション管理 。 OWAPSサイトは問題を十分に説明しています:
航空会社の予約アプリケーションはURLの書き換えをサポートし、URLにセッションIDを入れます: http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii
サイトの認証されたユーザーが、友人にセールについて知らせたいと考えています。彼は自分のセッションIDも提供していることを知らずに上記のリンクに電子メールを送信します。彼の友人がリンクを使用するとき、彼らは彼のセッションとクレジットカードを使用します。
また、ユーザーが入力した各URLは、ブラウザメーカーや優先検索エンジンに送信される可能性があることも考慮してください( Google Chromeプライバシーポリシー を参照)。
これは amccormackの答え の拡張です。
お客様がメールアドレスを入力してログインを開始できるようにします。ユーザーがメールアドレスを入力したら、それを使用してユーザーがログインを許可されていることを確認し、一時的なトークンをユーザーのメールアドレスに送信しますこれは、適切なナンスを含むWebリンクの形式、またはユーザーが次のフォーム(ウィザードスタイルのログイン)のフィールドにコピーする必要があるキーの形式である可能性があります。入力したトークンがその電子メールアドレスに送信されたトークンと一致し、それがまだ有効であることを確認します。グレイリストの場合、最初の数時間は必ず有効にするようにしてください。また、トークンを再利用できないように、1回限りの使用を許可してください。
この場合、ユーザーはサービスに特別なことを覚える必要はなく(自分のメールアドレスとそのメールアカウントへのアクセスのみが必要です)、このスキームは他の純粋なリセットパスワードよりも安全性が高くなります。あなたが思いつくことができる電子メール方式。
また、将来的には、SMS(または考えられる他の任意の配信チャネル)を介したトークン配信を許可することで、これを拡張できます。トークン配信コード以外のすべてに最小限の変更を加えます。