安全なパスワードのリセットについて知りたかったすべての情報。 パート2

二要素認証

読んだものすべて 最初の部分 という事実に基づく識別に関連する 依頼者は知っています。 彼は自分の電子メール アドレスを知っており、それにアクセスする方法 (つまり、電子メール パスワード) を知っており、秘密の質問の答えも知っています。

「知識」は認証要素の XNUMX つとみなされます。 他の XNUMX つの共通要素は、 あなたが持っているものたとえば、物理デバイス、および あなたは誰ですか指紋や目の網膜など。

ほとんどの場合、特に Web アプリケーションのセキュリティについて話している場合は、生物学的識別を実行することは不可能です。そのため、2 要素認証 (XNUMX 要素認証、XNUMXFA) では、通常、XNUMX 番目の属性である「所有しているもの」が使用されます。 この XNUMX 番目の要素の一般的なバリエーションの XNUMX つは、たとえば、物理トークンです。 RSA セキュリティ ID:

物理トークンは、企業の VPN や金融サービスの認証によく使用されます。 サービスに対して認証するには、パスワードとトークンのコード (頻繁に変更されます) の両方を PIN と組み合わせて使用​​する必要があります。 理論的には、攻撃者を特定するには、パスワードを知っていること、トークンを持っていること、そしてトークンの PIN も知っている必要があります。 パスワード リセットのシナリオでは、パスワード自体は明らかに不明ですが、トークンの所有はアカウントの所有権を証明するために使用できます。 もちろん、他のセキュリティ実装と同様に、 「フールプルーフ」を提供するものではありません, しかし、参入障壁は確実に高くなります。

このアプローチの主な問題の 2 つは、実装のコストとロジスティクスです。 私たちは物理的なデバイスを各クライアントに引き渡し、新しいプロセスを教えることについて話しています。 さらに、ユーザーはデバイスを携帯する必要がありますが、物理トークンの場合は必ずしもそうであるとは限りません。 もう XNUMX つのオプションは、SMS を使用して認証の XNUMX 番目の要素を実装することです。これは、XNUMXFA の場合、リセット プロセスを実行する人がアカウント所有者の携帯電話を所有していることの確認として機能します。 Google のやり方は次のとおりです。

有効にする必要もあります 二段階認証, ただし、これは、次回パスワードをリセットするときに、携帯電話が認証の XNUMX 番目の要素になる可能性があることを意味します。 私の iPhone を例としてこれを説明しましょう。その理由はすぐに明らかになるでしょう。

アカウントのメール アドレスを特定した後、Google は 2FA が有効になっていると判断し、SMS 経由でアカウント所有者の携帯電話に送信される確認を使用してアカウントをリセットできます。

次に、リセット プロセスの開始を選択する必要があります。

このアクションにより、登録されたアドレスに電子メールが送信されます。

このメールにはリセット URL が含まれています。

リセット URL にアクセスすると、SMS が送信され、Web サイトはそれを要求します。

SMS は次のとおりです。

ブラウザに入力すると、古典的なパスワード リセットの領域に戻ります。

これはおそらく少し冗長に聞こえるかもしれませんが、そのとおりですが、リセットを実行する人がアカウント所有者の電子メール アドレスと携帯電話にアクセスできることをフォームで確認します。 ただし、電子メールだけでパスワードをリセットするよりも XNUMX 倍安全です。 ただし、問題もあります...

問題はスマートフォンに関連しています。 以下に示すデバイスは、認証要素を XNUMX つだけ認証できます。SMS は受信できますが、電子メールは受信できません。

ただし、このデバイスは SMS を受信できます и パスワードリセットメールを受信します:

問題は、私たちは電子メールを認証の最初の要素、SMS (またはトークン生成アプリケーション) を XNUMX 番目の要素とみなしているのですが、現在ではそれらが XNUMX つのデバイスに組み合わされていることです。 もちろん、これは、誰かがあなたのスマートフォンにアクセスした場合、このすべての利便性は、私たちが再び同じチャネルに戻るという事実に帰着することを意味します。 この XNUMX 番目の要素「あなたが持っているもの」は、最初の要素も持っていることを意味します。 そして、電話機に PIN がある場合、すべては単一の XNUMX 桁の PIN によって保護されます。 и 彼はブロックされました。

はい、Google の 2FA 機能は確かに追加の保護を提供しますが、絶対確実というわけではなく、完全に自律的な XNUMX つのチャネルに依存するわけではありません。

ユーザー名によるリセットとメールアドレスによるリセット

電子メールアドレスによるリセットのみを許可する必要がありますか? それともユーザーも名前でリセットできるようにすべきでしょうか? ユーザー名によるリセットの問題は、無効なユーザー名をユーザーに通知する方法がないことです。 開示せずに 他の誰かがその名前のアカウントを持っている可能性があります。 前のセクションでは、電子メールのリセットにより、その電子メールの正当な所有者が、システム内での存在を公に公開することなく常にフィードバックを受信できるようになりました。 これはユーザー名だけでは実行できません。

つまり、簡単な答えは「電子メールのみ」です。 ユーザー名だけでリセットしようとすると「どうしたの？」と思われる場合がありますが、 または アカウントの存在を明らかにすることになります。 はい、これは単なるユーザー名であり、メール アドレスではありません。はい、誰でも (利用可能な) ユーザー名を選択できますが、ユーザーは名前を再利用する傾向があるため、間接的にアカウント所有者を明らかにする可能性が依然として十分にあります。

では、ユーザー名を忘れた場合はどうなるのでしょうか? ユーザー名が直ちに電子メール アドレスではないと仮定すると (これはよくあることです)、プロセスはパスワード リセットの開始方法と似ています。電子メール アドレスを入力し、その存在を公開せずにこのアドレスにメッセージを送信します。 唯一の違いは、今回のメッセージにはユーザー名のみが含まれており、パスワード リセット URL が含まれていないことです。 そうしないと、このアドレスにはアカウントがないと電子メールで通知されます。

本人確認と電子メールアドレスの正確性

パスワードのリセットの重要な側面、そしておそらく 最も 重要な点は、リセットしようとしている人の身元を確認することです。 これは本当にアカウントの正当な所有者なのでしょうか、それとも誰かがアカウントをハッキングしようとしたり、所有者に迷惑をかけようとしているのでしょうか?

明らかに、電子メールは最も便利で最も一般的な本人確認チャネルです。 これは絶対確実ではなく、高度な識別の信頼性が必要な場合には、アカウント所有者のアドレスでメールを受信できるだけでは不十分な場合が多くあります (これが 2FA が使用される理由です)。スタート地点のリセット処理です。

電子メールが信頼性を提供する役割を果たす場合、最初のステップは電子メール アドレスが実際に正しいことを確認することです。 誰かがシンボルを間違えた場合、当然ながらリセットは開始されません。 登録時の電子メール認証プロセスは、アドレスが正しいことを確認する信頼できる方法です。 誰もが実際にその動作を見たことがあるでしょう。サインアップすると、クリックする固有の URL が記載されたメールが送信されます。これにより、あなたがそのメール アカウントの本当の所有者であることが確認されます。 このプロセスが完了するまでログインできないため、アドレスを確認する動機が確実に得られます。

セキュリティの他の多くの側面の場合と同様に、このモデルは、ユーザーの ID に対する信頼性と比較してセキュリティの度合いを高める代わりに、ユーザビリティを低下させます。 これは、ユーザーが登録を高く評価し、プロセスに別のステップ (有料サービス、銀行取引など) を喜んで追加するサイトでは許容されるかもしれませんが、ユーザーがアカウントを「XNUMX つのアカウント」と認識すると、そのようなことはユーザーを反発させる可能性があります。たとえば、単に投稿にコメントする手段として を使用します。

リセットプロセスを開始した人の特定

明らかに、リセット機能を悪意を持って使用する理由があり、攻撃者はさまざまな方法でリセット機能を使用する可能性があります。 リクエストの送信元を検証するために使用できる XNUMX つの簡単なトリック (このトリック 通常 works) は、要求者の IP アドレスをリセットするという提案を含む手紙への追加です。 受信者に提供します いくつか リクエストの送信元を特定するための情報。

以下は、現在 ASafaWeb に構築しているリセット関数の例です。

「詳細を見る」リンクをクリックすると、ユーザーはサイトに移動します。 ip-address.com、リセットの要求者の場所や組織などの情報を提供します。

もちろん、自分の身元を隠したい人は、自分の実際の IP アドレスを難読化するさまざまな方法がありますが、これは要求者の部分的な識別を追加する便利な方法です。 ほとんどの 場合によっては、これにより、誰がパスワード リセット リクエストを完了するのかが正確にわかります。

メール変更通知

この投稿には、コミュニケーションという XNUMX つのテーマが貫かれています。 悪意のある目的で使用される可能性のあるものを明らかにすることなく、プロセスの各ステップで何が起こったのかをアカウント所有者にできる限り知らせます。 パスワードが実際に変更された状況にも同じことが当てはまります- 所有者に通知してください！

パスワードを変更する理由としては、次の XNUMX つの原因が考えられます。

1. ユーザーが新しいパスワードを必要としたため、ログイン後にパスワードを変更する
2. ユーザーが忘れたためにログインせずにパスワードをリセットする

この投稿は主にリセットに関するものですが、最初の投稿に通知することで、正当な所有者に知られずに誰かがパスワードを変更するリスクが軽減されます。 どうしてこんなことが起こるのでしょうか？ 非常に一般的なシナリオは、正当な所有者のパスワード (別のソースから漏洩した再利用されたパスワード、キーロギングによって取得されたパスワード、推測しやすいパスワードなど) を取得し、その後、攻撃者がそれを変更することを決定し、所有者をブロックすることです。 電子メール通知がなければ、実際の所有者はパスワードの変更に気づきません。

もちろん、パスワードをリセットする場合は、所有者がすでにプロセスを自分で開始している（または上記の本人確認ツールをバイパスしている）はずです。 すべきではない 彼にとっては驚くべきことでしたが、電子メールによる確認は肯定的なフィードバックとなり、追加の検証となります。 さらに、上記のシナリオとの統一性も提供します。

ああ、それがまだ明らかではない場合のために言っておきますが、 新しいパスワードをメールで送信しないでください。 笑われる方もいるかも知れませんが、 このようなことが起こる:

ログ、ログ、ログ、さらにいくつかのログ

パスワード リセット機能は、攻撃者にとって魅力的です。攻撃者は、他人のアカウントへのアクセスを取得したいか、単にアカウント/システム所有者に迷惑をかけたいかのどちらかです。 上記で説明した慣行の多くは、悪用の可能性を減らしますが、悪用を防ぐことはできません。また、意図しない方法で機能を使用しようとする人々を阻止することもできません。

悪意のある動作を検出するには、ログ記録は非常に貴重な習慣です。 非常に詳細なログ記録。 失敗したログイン試行、パスワードのリセット、パスワードの変更 (つまり、ユーザーがすでにログインしているとき) など、何が起こっているかを理解するのに役立つあらゆるものをキャプチャします。 これは将来とても役に立ちます。 個別でもログで修正 パーツ たとえば、優れたリセット機能には、Web サイト経由でのリセットの開始 (間違ったユーザー名または電子メールによるリセット要求とログイン試行のキャプチャ)、リセット URL での Web サイトへのアクセスのキャプチャ (間違ったユーザー名または電子メールの使用の試みを含む) が含まれる必要があります。トークン)、セキュリティの質問に対する回答の成功または失敗を記録します。

ロギングとは、ページが読み込まれたという事実を記録するだけでなく、可能な限り多くの情報を収集することを意味します。 機密でない場合。 みんな、 パスワードを記録しないでください。 ログには、許可されたユーザーの ID を登録する必要があります (許可されたユーザーは許可されます)。 変更する 既存のパスワード、またはリセットしようとしています 他人のパスワード ログイン後)、使用しようとするユーザー名または電子メール アドレス、および使用しようとするリセット トークン。 ただし、IP アドレスや、可能であればリクエスト ヘッダーなどをログに記録することも価値があります。 これにより、再作成できるだけでなく、 その ユーザー (または攻撃者) がやろうとしていることだけでなく、 誰が 彼はそんな人だ。

他の出演者への責任の委任

これらすべてが膨大な量の作業であると思われるのは、あなただけではありません。 実際、アカウントを操作するための信頼できるシステムを構築するのは簡単な作業ではありません。 技術的に難しいというわけではなく、機能がたくさんあるというだけです。 単なるリセットではなく、サインアップ、パスワードの安全な保存、複数回の不正なログイン試行の処理などのプロセス全体が必要です。 それでも ASP.NETメンバーシッププロバイダーのような既製の機能を使用するというアイデアを推進していますそれ以外にも、さらに多くのことを行う必要があります。

現在、その手間を喜んで軽減し、すべてを XNUMX つのマネージド サービスに抽象化するサードパーティ ベンダーが数多くあります。 これらのサービスには、OpenID、OAuth、さらには Facebook も含まれます。 一部の人々 このモデルに対する限りない信頼 (OpenID は確かに Stack Overflow で非常に成功しています)、しかし他のものでは 文字通り悪夢だと思う.

OpenID のようなサービスは開発者の問題の多くを解決することは間違いありませんが、新たな問題が追加されることも確かです。 彼らには何か役割があるのでしょうか？ はい、しかし、認証サービスプロバイダーのサービスが大量に使用されているわけではないことは明らかです。 銀行、航空会社、さらには店舗さえも独自の認証メカニズムを実装していますが、これには明らかに十分な理由があります。

悪意のあるリセット

上記の各例の重要な点は、古いパスワードは役に立たないとみなされることです。 アカウント所有者の身元を確認した後。 これは重要です。なぜなら、アカウントがリセットされる可能性があるからです。 до ID チェックを行うと、あらゆる種類の悪意のある活動が行われる機会が与えられる可能性があります。

例を次に示します。誰かがオークション サイトで入札しており、入札プロセスの終わりに近づいて、リセット プロセスを開始して競合他社をブロックし、入札から除外します。 明らかに、不適切に設計されたリセット機能を悪用すると、深刻なマイナスの結果につながる可能性があります。 無効なログイン試行によるアカウントのブロックも同様の状況であることに注意してください。ただし、これについては別の投稿で説明します。

上で述べたように、電子メール アドレスを知るだけで任意のアカウントのパスワードをリセットできる機能を匿名ユーザーに与えると、これはサービス拒否攻撃の準備ができた状況になります。 それは違うかもしれない DoS攻撃、これについては以前お話しましたが、アカウントへのアクセスをブロックするには、よく考えられていないパスワード リセット機能を使用するよりも手っ取り早い方法はありません。

最も弱いリンク

単一のアカウントを保護するという観点から見ると、上に書いたことはすべて素晴らしいことですが、保護しているアカウントを取り巻くエコシステムを常に念頭に置く必要があります。 例を挙げてみましょう。

ASafaWeb は、AppHarbor が提供する素晴らしいサービスでホストされています。 ホスティング アカウントをリセットするプロセスは次のとおりです。

ステージ1：

ステージ2：

ステージ3：

ステージ4：

これまでの情報をすべて読んだ後、理想的な世界のどの側面を少し異なる方法で実装すればよいかは、すでに簡単に理解できます。 ただし、私がここで言いたいのは、AppHarbor で ASafaWeb のようなサイトを公開し、優れたセキュリティの質問と回答を考え出し、XNUMX 番目の認証要素を追加し、残りをルールに従って実行したとしても、それは変わらないということです。プロセス全体の中で最も弱い部分がすべてを打ち破ることができるという事実。 誰かが私の情報を使用して AppHarbor で認証に成功した場合、その人は ASafaWeb アカウントのパスワードを必要なパスワードに変更できるようになります。

重要なのは、セキュリティ実装の強度を総合的に考慮する必要があるということです。たとえそれが AppHarbor へのログインなどの表面的なプロセスであっても、システムのすべてのエントリ ポイントで脅威をモデル化する必要があります。 これにより、ASafaWeb のパスワード リセット プロセスにどれだけの労力を費やす必要があるかがわかります。

すべてを一緒に入れて

この投稿には多くの情報が含まれているため、シンプルな視覚的スキームにまとめたいと思います。

これらの各項目について最も詳細なログを記録する必要があることに注意してください。 それだけです、簡単です！

結果

私の投稿は包括的であるように見えますが、追加の内容がたくさんあります。 できた レスキュー電子メール アドレスの役割、アカウントに関連付けられた電子メールにアクセスできなくなった状況 (たとえば、仕事を辞めた) などを含めますが、簡潔にするために省略しました。 前に述べたように、リセット機能はそれほど複雑ではありません。ただ、それについてはさまざまな観点があります。

リセットはそれほど複雑ではありませんが、多くの場合、誤って実装されます。 上記では、実装例をいくつか見てきました。 缶 問題を引き起こす可能性があり、間違ったリセットが行われるケースはさらに多くあります。 本当に 問題を引き起こした。 最近判明したのは、 87ドル相当のビットコインを盗むためにパスワードリセットが使用された。 これは深刻なマイナスの結果です。

したがって、リセット機能には注意してください。 脅威をシミュレートする また、機能をデザインするときは、他の誰かがかぶる可能性が高いので、黒い帽子を脱がないでください。

広告の権利について

VDSina 安価に提供します レンタルサーバー 日払いで、各サーバーは 500 Mbps のインターネット チャネルに接続され、DDoS 攻撃から無料で保護されます。

出所： habr.com