🙅🏽 👨🏼‍🌾 🐀 パスワードを安全にリセットすることについて知りたいことすべて。パート2 👇🏽 👩🏾‍✈️ 🕚

二要素認証

最初の部分で読んだものはすべて、要求者が知っていることに基づく識別に関係していました。彼は自分の電子メールアドレスを知っており、それにアクセスする方法を知っており（つまり、自分の電子メールパスワードを知っています）、セキュリティに関する質問への回答を知っています。

「知識」は1つの認証要素としてカウントされます。 2つの他の一般的な要因があるあなたが持っているものなどの物理的なデバイスとして、そしてあなたが誰であるか、指紋や網膜など、。

ほとんどの場合、特にWebアプリケーションのセキュリティについて話す場合、生物学的識別を実行することはほとんど実行可能ではありません。そのため、2要素認証（2FA）は通常、2番目の属性である「持っているもの」を使用します。この第二の要因の1つの一般的なバリエーションは、以下のような物理的なトークンであるRSAのSecurID：

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

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

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

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

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

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

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

リセットされたURLにアクセスすると、SMSが送信され、Webサイトは次の入力を求めます。

これはSMSです：

ブラウザに入力した後、従来のパスワードリセットの領域に戻ります。

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

問題はスマートフォンにあります。以下に示すデバイスは、認証の1つの要素のみを認証できます。SMSは受信できますが、電子メールは受信できません。

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

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

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

ユーザー名でリセットするか、メールでリセットする

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

したがって、答えは短いです。電子メールのみです。ユーザー名だけでリセットしようとすると、ユーザーが何が起こったのか疑問に思うことがあります。または、アカウントの存在を開示します。はい、これは単なるユーザー名であり、メールアドレスではありません。はい、誰でも任意の（利用可能な）ユーザー名を選択できますが、ユーザーが再利用する傾向があるため、アカウント所有者を間接的に開示する可能性が高くなります。名前。

では、誰かがユーザー名を忘れるとどうなりますか？ユーザー名がすぐにメールアドレスではないことを認めた場合（これは頻繁に発生します）、プロセスはパスワードのリセットを開始する方法と似ています。メールアドレスを入力し、その存在を明らかにせずにこのアドレスにメッセージを送信します。唯一の違いは、今回のメッセージにはユーザー名のみが含まれ、パスワードリセットURLは含まれないことです。それか、メールにこのアドレスのアカウントがないことが記載されています。

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

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

明らかに、電子メールはあなたの身元を確認するための最も便利で最も一般的な方法です。誤った取り扱い（「ばかから」）から保護されておらず、高い識別の信頼性が必要な場合（2FAが使用される理由）、アカウント所有者のアドレス宛ての手紙を受け取る単純な機能では不十分な場合が多くありますが、ほとんどの場合、それが出発点です。プロセスをリセットします。

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

セキュリティの他の多くの側面と同様に、このようなモデルは、ユーザーのIDに関連してセキュリティを強化する代わりに、使いやすさを低下させます。これは、ユーザーが高く評価し、プロセスの別の段階（有料サービス、銀行など）を喜んで追加するサイト、登録では許容できる場合がありますが、ユーザーがアカウントを「使い捨て」と認識して使用する場合、そのようなことはユーザーを遠ざける可能性がありますたとえば、単に投稿にコメントする手段として。

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

明らかに、リセット機能の悪用には理由があり、攻撃者はさまざまな方法でリセット機能を使用できます。リクエストの発信元を確認するために使用できる簡単なトリックの1つ（このトリックは通常は機能します）は、リクエスターのIPアドレスリセットを電子メールに追加することです。これは、受信者と提供していくつかの要求の送信元を特定するための情報を。

これは、現在ASafaWebに埋め込んでいるリセット機能の例です。

「詳細」リンクをクリックすると、ユーザーはip-adress.comに移動し、リセットを要求している人の場所や組織などの情報が提供されます。

もちろん、IDを非表示にしたい場合は、実際のIPアドレスをわかりにくくする方法がたくさんありますが、これはリクエスターの部分的なIDを追加する便利な方法であり、ほとんどの場合、誰がパスワードリセットリクエストを実行するかについての良いアイデアが得られます。

メールによる変更通知

この投稿には、コミュニケーションという1つのトピックが含まれています。悪意を持って使用される可能性のあるものを明らかにすることなく、プロセスの各段階で何が起こっているかについて、アカウント所有者に可能な限り伝えます。パスワードが実際に変更された場合も同じことが当てはまります。所有者に通知してください。

パスワードを変更する理由は2つあります。

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

この投稿は主にリセットに関するものですが、最初のケースの通知は、正当な所有者の知らないうちに誰かがパスワードを変更するリスクを軽減します。これはどのように起こりますか？非常に一般的なシナリオは、正当な所有者のパスワード（別のソースから漏洩した再利用されたパスワード、キーロギングによって取得されたパスワード、簡単に推測できるパスワードなど）を取得した後、攻撃者がそれを変更することを決定し、所有者をブロックすることです。電子メール通知がない場合、現在の所有者はパスワードの変更を認識しません。

もちろん、パスワードがリセットされた場合、所有者はすでにプロセスを開始する必要があります（または上記のID検証ツールをバイパスする必要があります）ので、変更はすべきではありません彼には驚きですが、確認メールは肯定的なフィードバックと追加の確認になります。さらに、上記のシナリオとの一貫性を提供します。

ああ、それがまだ明らかでない場合は、新しいパスワードを投稿しないでください！これは少し笑うかもしれませんが、これは起こります：

ログ、ログ、ログ、その他のログ

パスワードリセット機能は侵入者にとって魅力的です。攻撃者は他の人のアカウントにアクセスしたい、または単にアカウント/システム所有者に不便をかけたいのです。上記の方法の多くは乱用の可能性を減らすことができますが、それを防ぐことはできず、人々が意図しない方法で機能を使用しようとすることを確実に妨げることはありません。

ロギングは、悪意のある動作を認識するための非常に貴重な方法であり、非常に詳細なロギングを意味します。ログインの失敗した試行、パスワードのリセット、パスワードの変更（つまり、ユーザーがすでにログインしている場合）、および何が起こっているのかを理解するのに役立つほとんどすべての試みを記録します。将来的には非常に役立つでしょう。別々の部分もログに記録しますたとえば、適切なリセット機能には、Webサイトを介したリセットの開始（要求をキャプチャし、間違ったユーザー名または電子メールでリセットのログイン試行を行う）、リセットURLによるWebサイトへのアクセスの記録（誤った使用の試行を含む）を含める必要があります。トークン）、セキュリティの質問への回答の成功または失敗をログに記録します。

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

他のパフォーマーへの責任の委任

これが膨大な量の作業だと思うなら、あなたは一人ではありません。実際、堅牢なアカウント管理システムを構築することは簡単な作業ではありません。技術的に重いということではなく、多くの機能を備えているだけです。リセットだけでなく、登録プロセス全体、パスワードの安全な保管、複数回の誤ったログイン試行の処理などがあります。一方で私は、ASP.NETのメンバーシッププロバイダーのようなアウトオブボックスの機能を使用してのアイデアを推進しています、それを超えて行われることがたくさんはまだあります。

今日、多くのサードパーティベンダーが、苦痛を取り除き、すべてを1つのマネージドサービスに抽象化しています。これらのサービスには、OpenID、OAuth、さらにはFacebookが含まれます。人によってはこのモデルを信じるのに制限はありませんが（OpenIDは実際にStack Overflowで非常に成功しています）、それでも他の人は文字通り悪夢と見なしています。

間違いなく、OpenIDのようなサービスは多くの開発者の問題を解決しますが、間違いなく新しい問題を追加しています。彼らには果たすべき役割がありますか？はい。ただし、認証サービスプロバイダーの大規模な使用は明らかに見られません。銀行、航空会社、さらには店舗もすべて独自の認証メカニズムを実装しており、これには明らかに非常に正当な理由があります。

悪意のある排出

上記の各例の重要な側面は、アカウント所有者のIDが確認された後でのみ、古いパスワードが役に立たないと見なされることです。本人確認の前にアカウントをリセットできると、あらゆる種類の悪意のあるアクティビティが発生するため、これは重要です。

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

上で述べたように、匿名ユーザーがアカウントの電子メールアドレスを知っているだけでアカウントのパスワードをリセットできるようにすることは、サービス拒否攻撃の既成の状況です。同じDoSではない可能性があります、これについてはよく話しますが、よく考えられていないパスワードリセット機能を使用するよりも、アカウントへのアクセスをブロックするより速い方法はありません。

最も弱いリンク

1つのアカウントを保護するという観点からは、上記のすべてが優れていますが、保護しているアカウントを取り巻くエコシステムについて常に覚えておく必要があります。例を挙げましょう

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

ステージ1：

ステージ2：

ステージ3：

ステージ4：

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

重要なのは、保護実装の堅牢性を全体的に考慮する必要があるということです。たとえば、AppHarborシステムに入るなどの表面的なプロセスであっても、システムの各エントリポイントに対する脅威をシミュレートする必要があります。これにより、ASafaWebパスワードのリセットプロセスにどれだけの労力を費やす必要があるかがわかります。

すべてを一緒に入れて

この投稿には多くの情報が含まれているので、簡単な視覚的なアウトラインに集中したいと思います。

これらの各項目について、可能な限り詳細にログに記録することを忘れないでください。それだけです、それは簡単です！

結果

私の投稿は包括的であるように見えますが、含めることができる追加の資料がたくさんありますが、簡潔にするために省略しました。レスキューメールアドレスの役割、アカウントに関連付けられたメールにアクセスできなくなる状況（たとえば、あなたは仕事を辞めます）など。さっきも言ったように、リセット機能はそれほど難しくはなく、見方が多いだけです。

リセットはそれほど難しくはありませんが、誤用されることがよくあります。私たちは、実装がどこ上記の例のカップルを見てきましたができ問題につながるが、誤ったリセットはより多くのユースケースがある実際の問題を引き起こしたが。最近、次のことが明らかになりましたパスワードのリセットは、87,000ドル相当のビットコインを盗むために使用されました。これは深刻な否定的な結果です！

したがって、リセット機能に注意し、さまざまなポイントで脅威をシミュレートし、機能を設計するときは、他の誰かがそれを着用する可能性が高いため、黒い帽子を脱がないでください！

パスワードを安全にリセットすることについて知りたいことすべて。パート2