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

最近、安全なパスワード リセット機能がどのように機能するべきかについてもう一度考える時間がありました。最初にこの機能を構築していたときでした。 ASafaWebそして、他の人が同じようなことをするのを手伝ったとき。 XNUMX 番目のケースでは、リセット機能を安全に実装する方法の詳細がすべて記載された正規リソースへのリンクを彼に提供したいと思いました。 しかし、問題は、そのようなリソースが存在しないことです。少なくとも、私にとって重要と思われるすべてを説明したリソースは存在しません。 そこで、自分で書くことにしました。

ご存知のとおり、忘れたパスワードの世界は、実際には非常に神秘的なものです。 完全に受け入れられるさまざまな観点がたくさんありますが、かなり危険な観点もたくさんあります。 おそらく、あなたもエンド ユーザーとしてこれらのそれぞれに何度も遭遇したことがあるでしょう。 そこで、これらの例を使用して、誰が正しく実行し、誰が正しく実行していないのか、アプリで機能を正しく実行するには何に焦点を当てる必要があるのか​​を示していきます。

パスワードの保存: ハッシュ、暗号化、および (息を呑む!) プレーン テキスト

パスワードを保存する方法を議論する前に、忘れたパスワードをどうするかを議論することはできません。 パスワードは、次の XNUMX つの主なタイプのいずれかでデータベースに保存されます。

1. シンプルなテキスト。 パスワード列があり、プレーンテキスト形式で保存されます。
2. 暗号化されています。 通常は対称暗号化 (暗号化と復号化の両方に XNUMX つのキーが使用されます) を使用し、暗号化されたパスワードも同じ列に格納されます。
3. ハッシュ化。 一方向プロセス (パスワードはハッシュ化できますが、デハッシュ化はできません)。 パスワード、 期待したいと思います、その後に塩が続き、それぞれが独自の列に表示されます。

最も単純な質問に直行しましょう。 パスワードをプレーンテキストで保存しないでください。 一度もない。 単一の脆弱性 注射、XNUMX つの不注意なバックアップ、またはその他数十の単純な間違いの XNUMX つ - それで終わり、ゲームオーバー、すべてのパスワード - つまり、申し訳ありませんが、 すべてのクライアントのパスワード パブリックドメインになります。 もちろん、これは非常に高い可能性を意味します すべてのパスワード 他のシステムにあるすべてのアカウントから。 そしてそれはあなたのせいになります。

暗号化は優れていますが、弱点もあります。 暗号化の問題は復号化です。 これらの奇妙に見える暗号を平文に変換して戻すことができます。そうすれば、人間が判読できるパスワードの状況に戻ります。 これはどうして起こるのでしょうか? パスワードを復号化するコードに小さな欠陥が入り込み、パスワードが公開されてしまいます。これは XNUMX つの方法です。 ハッカーは、暗号化されたデータが保存されているマシンにアクセスします。これが XNUMX 番目の方法です。 もう XNUMX つの方法は、やはりデータベースのバックアップを盗むことであり、暗号化キーも誰かが入手しますが、暗号化キーは多くの場合非常に安全に保管されていません。

そして、これがハッシュ化につながります。 ハッシュの背後にある考え方は、それが一方向であるということです。 ユーザーが入力したパスワードとそのハッシュされたバージョンを比較する唯一の方法は、入力をハッシュして比較することです。 レインボー テーブルのようなツールからの攻撃を防ぐために、プロセスにランダム性を持たせます (私の記事を読んでください) 投稿する 暗号化ストレージについて)。 最終的には、正しく実装されていれば、ハッシュされたパスワードが再びプレーン テキストになることはないと確信できます (さまざまなハッシュ アルゴリズムの利点については、別の投稿で説明します)。

ハッシュと暗号化に関する簡単な議論: パスワードをハッシュするのではなく暗号化する必要がある唯一の理由は、パスワードを平文で表示する必要がある場合です。 これは決して望んではいけません少なくとも標準的なウェブサイトの状況では。 これが必要な場合は、何か間違ったことをしている可能性があります。

警告！

投稿本文の下には、ポルノウェブサイト「AlotPorn」のスクリーンショットの一部が含まれている。 きれいにトリミングされているため、ビーチで見えないものはありませんが、それでも問題が発生する可能性がある場合は、下にスクロールしないでください。

必ずパスワードをリセットしてください 決して 彼に思い出させないでください

関数を作成するように頼まれたことがありますか リマインダー パスワード？ 一歩下がって、このリクエストを逆に考えてみましょう。なぜこの「リマインダー」が必要なのでしょうか? ユーザーがパスワードを忘れたためです。 私たちが本当にやりたいことは何でしょうか？ 彼が再度ログインできるよう手伝ってください。

「リマインダー」という言葉が（しばしば）口語的な意味で使われていることは承知していますが、私たちが本当にやろうとしているのは、 ユーザーが再びオンラインになれるよう安全に支援します。 セキュリティが必要なため、リマインダー (ユーザーにパスワードを送信するなど) が適切でない理由は XNUMX つあります。

1. 電子メールは安全ではないチャネルです。 HTTP 経由で機密情報を送信しないのと同様 (HTTPS を使用します)、トランスポート層が安全でないため、電子メールで機密情報を送信すべきではありません。 実際、これは、安全でないトランスポート プロトコルを介して単に情報を送信するよりもはるかに悪いです。メールはストレージ デバイスに保存され、システム管理者がアクセスでき、転送および配布され、マルウェアにアクセスできることが多いためです。 暗号化されていない電子メールは、非常に安全性の低いチャネルです。
2. いずれにせよ、パスワードにアクセスできるべきではありません。 ストレージに関する前のセクションをもう一度読んでください。パスワードのハッシュ (適切な強力なソルトを使用) が必要です。つまり、いかなる方法でもパスワードを抽出してメールで送信できないようにする必要があります。

例を挙げて問題を説明してみましょう usoutdoor.com: 一般的なログイン ページは次のとおりです。

明らかに、最初の問題はログイン ページが HTTPS 経由で読み込まれないことですが、サイトではパスワードの送信 (「パスワードの送信」) も要求されます。 これは、上記の用語の口語的な使用例である可能性があるため、さらに一歩進めて、何が起こるかを見てみましょう。

残念ながら、見た目はあまり良くありません。 問題があることを確認する電子メールが送信されます。

これにより、usoutdoor.com の XNUMX つの重要な側面がわかります。

1. このサイトはパスワードをハッシュ化しません。 良くても暗号化されていますが、平文で保存される可能性が高くなります。 これに反する証拠は見当たりません。
2. このサイトは、安全でないチャネルを通じて長期パスワード (戻って何度でも使用できます) を送信します。

これで、リセットプロセスが安全な方法で行われたかどうかを確認する必要があります。 これを行う最初のステップは、要求者にリセットを実行する権利があることを確認することです。 言い換えれば、この前に身元チェックが必要です。 要求者が実際にアカウント所有者であることを最初に確認せずに身元が確認された場合に何が起こるかを見てみましょう。

ユーザー名のリストとその匿名性への影響

この問題は視覚的に説明するのが最も分かりやすいです。 問題：

見える？ 「このメールアドレスにはユーザーが登録されていません。」というメッセージに注意してください。 そのようなサイトが確認した場合、問題は明らかに発生します 可用性 ユーザーはそのような電子メールアドレスで登録されています。 ビンゴ - あなたの夫/上司/隣人のポルノフェチを発見しました!

もちろん、ポルノはプライバシーの重要性を示すかなり象徴的な例ですが、個人を特定の Web サイトに関連付けることの危険性は、上で説明した潜在的に厄介な状況よりもはるかに広範囲に及びます。 危険の XNUMX つはソーシャル エンジニアリングです。 攻撃者がサービスに該当する人物を照合できた場合、攻撃者は情報を入手し、それを使用し始めることができます。 たとえば、犯罪行為を行うために、Web サイトの代表者を装った人物に連絡し、追加情報を要求する可能性があります。 スピアフィッシング.

このような行為は、グループ クエリを実行し、その応答を調べるだけで、Web サイト上のユーザー名または電子メール アドレスのコレクション全体の存在を確認できる「ユーザー名の列挙」の危険性も高めます。 全従業員の電子メール アドレスのリストと、スクリプトを作成するための数分はありますか? そうすれば、問題が何であるかがわかります。

代替案は何ですか? 実際、これは非常にシンプルで、見事に実装されています。 エントロペイ:

ここで、Entropay はシステム内の電子メール アドレスの存在についてはまったく開示していません。 このアドレスを所有していない人へ..。 もし、あんたが 自分の このアドレスがシステムに存在しない場合は、次のようなメールが届きます。

もちろん、誰かが と思うウェブサイトに登録したこと。 しかし、これは当てはまらないか、別の電子メール アドレスから実行しました。 上に示した例は、両方の状況を適切に処理します。 もちろん、アドレスが一致すると、パスワードを簡単にリセットできる電子メールが届きます。

Entropay が選択したソリューションの微妙な点は、本人確認が以下に従って実行されることです。 Eメール オンライン認証の前に。 一部のサイトでは、ユーザーに秘密の質問への回答を求めます (これについては以下で詳しく説明します)。 до リセットがどのように始まるのか。 ただし、これの問題は、何らかの形式の識別情報 (電子メールまたはユーザー名) を提供しながら質問に回答する必要があることです。そのため、匿名ユーザーのアカウントの存在を明らかにせずに直感的に回答するのはほぼ不可能になります。

このアプローチでは、 小さな 存在しないアカウントをリセットしようとすると、すぐにフィードバックが得られないため、使いやすさが低下します。 もちろん、これが電子メール送信の重要な点ですが、実際のエンドユーザーの観点から見ると、間違ったアドレスを入力した場合、電子メールを受信したときに初めて知ることになります。 これは彼にいくらかの緊張を引き起こすかもしれませんが、これはこのようなまれなプロセスのために支払う小さな代償です。

トピックから少し外れますが、ユーザー名または電子メール アドレスが正しいかどうかを明らかにするログイン支援機能にも同じ問題があります。 資格情報の存在を明示的に確認するのではなく（たとえば、「ユーザー名は正しいが、パスワードが間違っています」など）、常に「ユーザー名とパスワードの組み合わせが無効です」というメッセージでユーザーに応答します。

リセットパスワードの送信とリセットURLの送信

次に説明する必要がある概念は、パスワードをリセットする方法です。 一般的なソリューションは XNUMX つあります。

1. サーバー上で新しいパスワードを生成し、電子メールで送信する
2. リセットプロセスを簡単にするために、一意の URL を記載したメールを送信してください

にもかかわらず 多くのガイド、最初の点は決して使用しないでください。 これの問題は、それが存在することを意味するということです 保存されたパスワード、いつでも戻って再度使用できます。 安全でないチャネル経由で送信されたため、受信箱に残っています。 受信トレイはモバイル デバイスと電子メール クライアント間で同期されている可能性があり、さらに、オンラインの Web 電子メール サービスに非常に長期間保存される可能性があります。 ポイントは、 メールボックスは長期保管の信頼できる手段とは見なされません.

しかし、これに加えて、最初の点には別の深刻な問題があります。 可能な限り単純化します 悪意のあるアカウントをブロックする。 Web サイトのアカウントを所有している人の電子メール アドレスを知っている場合は、パスワードをリセットするだけでいつでもその人をブロックできます。 これは、銀の大皿で提供されるサービス拒否攻撃です。 このため、リセットは、要求者の権利の検証が成功した後にのみ実行する必要があります。

リセット URL とは、次の Web サイトのアドレスを意味します。 リセットプロセスのこの特定のケースに特有の。 もちろん、ランダムである必要があり、推測が容易であってはならず、リセットを容易にするアカウントへの外部リンクが含まれていてはなりません。 たとえば、リセット URL は単に「Reset/?username=JohnSmith」のようなパスであってはなりません。

リセット URL としてメールで送信できる一意のトークンを作成し、ユーザーのアカウントのサーバー レコードと照合して、アカウント所有者が実際にパスワードをリセットしようとしている人物と同一であることを確認したいと考えています。 たとえば、トークンは「3ce7854015cd38c862cb9e14a1ae552b」で、リセットを実行したユーザーの ID およびトークンが生成された時刻とともにテーブルに保存されます (詳細は後述)。 電子メールの送信時には、「Reset/?id=3ce7854015cd38c862cb9e14a1ae552b」のような URL が含まれており、ユーザーがダウンロードすると、ページでトークンの存在を確認するプロンプトが表示され、その後、ユーザーの情報が確認され、トークンの変更が許可されます。パスワード。

もちろん、上記のプロセスでは (できれば) ユーザーが新しいパスワードを作成できるため、URL が HTTPS 経由でロードされることを確認する必要があります。 いいえ、 HTTPS 経由の POST リクエストで送信するだけでは十分ではありません、新しいパスワード フォームが攻撃されないように、このトークン URL はトランスポート層セキュリティを使用する必要があります。 MITM ユーザーが作成したパスワードは安全な接続を介して送信されました。

また、リセット URL については、リセット プロセスが一定の間隔内 (たとえば XNUMX 時間以内) に完了できるように、トークンの時間制限を追加する必要があります。 これにより、リセット時間枠が最小限に抑えられ、リセット URL の受信者はその非常に小さな時間枠内でのみ動作できるようになります。 もちろん、攻撃者はリセット プロセスを再度開始することができますが、別の一意のリセット URL を取得する必要があります。

最後に、このプロセスが使い捨てであることを確認する必要があります。 リセット プロセスが完了したら、リセット URL が機能しなくなるようにトークンを削除する必要があります。 前の点は、攻撃者がリセット URL を操作できる非常に小さなウィンドウを確実に確保するために必要です。 さらに、もちろん、リセットが成功すると、トークンは必要なくなります。

これらの手順の一部は過度に冗長に見えるかもしれませんが、使いやすさを妨げるものではありません。 実は 安全性が向上しますが、そのような状況はまれであると期待されます。 99% の場合、ユーザーは非常に短い時間内にリセットを有効にし、近い将来にパスワードを再度リセットすることはありません。

CAPTCHAの役割

ああ、CAPTCHA、誰もが嫌がるセキュリティ機能です。 実際、CAPTCHA は保護ツールというよりも、人であるかロボット (または自動スクリプト) であるかを識別するツールです。 その目的は、フォームの自動送信を回避することです。 缶 セキュリティを突破する試みとして使用される可能性があります。 パスワード リセットのコンテキストでは、CAPTCHA は、ユーザーにスパムを送信したり、アカウントの存在を確認しようとしたりするために、リセット機能を総当たりで実行することはできないことを意味します (もちろん、「」のセクションのアドバイスに従っている場合は不可能です)。身元確認）。

もちろん、CAPTCHA 自体は完璧ではありません。 ソフトウェアの「ハッキング」と十分な成功率 (60 ～ 70%) を達成した前例は数多くあります。 さらに、私の投稿に示されている解決策があります。 自動化された人間による CAPTCHA ハッキングでは、各 CAPTCHA を解決して 94% の成功率を達成するために、人々に XNUMX セント未満の金額を支払うことができます。 つまり、脆弱ではありますが、参入障壁が（わずかに）高くなります。

PayPal の例を見てみましょう。

この場合、CAPTCHA が解決されるまでリセット プロセスを開始することはできません。 理論的に プロセスを自動化することは不可能です。 理論的には。

ただし、ほとんどの Web アプリケーションにとって、これはやりすぎであり、 絶対的に正しい ユーザビリティの低下を表します。人々は単に CAPTCHA を好まないのです。 さらに、CAPTCHA は、必要に応じて簡単に戻ることができるものです。 サービスが攻撃を受け始めた場合 (この場合にログ記録が役立ちますが、詳細は後ほど説明します)、CAPTCHA を追加するのはこれ以上に簡単なことではありません。

秘密の質問と答え

検討したすべての方法により、電子メール アカウントにアクセスするだけでパスワードをリセットできました。 「ただ」とは言いましたが、もちろん、他人の電子メール アカウントにアクセスすることは違法です。 すべきである 複雑なプロセスになる。 しかし いつもそうではない.

実際、上記のリンクはサラ・ペイリンの Yahoo! のハッキングに関するものです。 XNUMX つの目的があります。 まず、(一部の) 電子メール アカウントをハッキングすることがいかに簡単であるかを示し、次に、悪質な秘密の質問が悪意を持って使用される可能性があることを示しています。 ただし、これについては後で説明します。

XNUMX% 電子メール ベースのパスワード リセットの問題は、リセットしようとしているサイトのアカウントの整合性が、電子メール アカウントの整合性に XNUMX% 依存することです。 あなたのメールにアクセスできるすべての人 電子メールを受信するだけでリセットできるあらゆるアカウントにアクセスできる。 このようなアカウントにとって、電子メールはオンライン生活の「すべてのドアへの鍵」です。

このリスクを軽減する XNUMX つの方法は、セキュリティの質問と回答のパターンを実装することです。 すでに見たことがあるはずです。自分だけが答えられる質問を選択してください 持っている 答えがわかっていれば、パスワードをリセットするときにパスワードを求められます。 これにより、リセットを試みている人が確かにアカウント所有者であるという確信が高まります。

サラ・ペイリンの話に戻ります。間違いは、彼女の秘密の質問に対する答えが簡単に見つけられることでした。 特にあなたがそのような重要な公人である場合、母親の旧姓、学歴、または誰かが過去に住んでいた可能性のある場所に関する情報は、それほど秘密ではありません。 実際、そのほとんどは誰でも見つけることができます。 サラに起こったことは次のとおりです。

ハッカーのデビッド・カーネルは、ペイリンの大学や生年月日などの経歴に関する詳細を見つけ、Yahoo! の忘れたパスワード回復機能を使用することで、ペイリンのアカウントにアクセスしました。

まず、これはYahoo!側の設計ミスです。 — このような単純な質問を指定することで、同社は本質的に秘密の質問の価値を妨害し、したがってシステムの保護を妨害したことになります。 もちろん、電子メール アカウントのパスワードをリセットすることは常に困難です。所有者に電子メールを送信することで所有権を証明できないためです (XNUMX 番目のアドレスが必要です)。しかし、幸いなことに、現在ではそのようなシステムを作成する用途はあまりありません。

セキュリティの質問に戻りましょう。ユーザーが独自の質問を作成できるようにするオプションがあります。 問題は、これによって次のような非常に明白な疑問が生じることです。

空は何色？

秘密の質問を個人を特定するために使用すると、人々を不快にさせる質問 人々 (コールセンターなど):

クリスマスに私は誰と一緒に寝ましたか?

または、率直に言って愚かな質問:

「パスワード」の綴りはどうなりますか?

秘密の質問に関しては、ユーザー自身を守る必要があります。 言い換えれば、秘密の質問はサイト自体が決定する必要があります。あるいは、もっと良いのは、セキュリティの質問を尋ねることです。 シリーズ ユーザーが選択できるセキュリティの質問。 そして選ぶのは簡単ではありません 1; 理想的には、ユーザーは XNUMX つ以上の秘密の質問を選択する必要があります アカウント登録時、これは XNUMX 番目の識別チャネルとして使用されます。 複数の質問があると、検証プロセスの信頼性が高まり、ランダム性 (常に同じ質問が表示されるわけではありません) を追加する機能も提供され、さらに、実際のユーザーがパスワードを忘れた場合に備えて多少の冗長性も提供されます。

適切な秘密の質問とは何ですか? これは、次のようないくつかの要因によって影響されます。

1. 彼は〜に違いない 簡単な — 質問は明確かつ明確でなければなりません。
2. 答えは 特定の — 人によって答えが異なる質問は必要ありません
3. 考えられる答えは次のとおりです。 多様な - 誰かに好きな色を尋ねると、考えられる答えのごく一部が得られます
4. 検索 答えは複雑でなければなりません - 答えが簡単に見つかる場合 任意の （高い地位にある人々を思い出してください）、それなら彼は悪いです
5. 答えは 永遠の そのうちに - 誰かに好きな映画を尋ねると、XNUMX 年後には答えが変わっているかもしれません

偶然ですが、「良い質問をすることに特化した」という Web サイトがあります。 GoodSecurityQuestions.com。 質問の中には、非常に優れているように見えるものもあれば、上記のテストの一部、特に「検索のしやすさ」テストに合格しないものもあります。

PayPal がセキュリティの質問をどのように実装しているか、特にサイトが認証にどのような取り組みを行っているかを説明します。 上ではプロセスを開始するためのページ (CAPTCHA 付き) を見てきましたが、ここでは電子メール アドレスを入力して CAPTCHA を解決した後に何が起こるかを示します。

その結果、ユーザーは次のような手紙を受け取ります。

ここまではすべて正常ですが、このリセット URL の背後に何が隠されているかを次に示します。

そこで、秘密の質問が登場します。 実際、PayPal ではクレジット カード番号を確認してパスワードをリセットすることもできるため、多くのサイトがアクセスできない追加のチャネルがあります。 応答せずにパスワードを変更することはできません 両方 秘密の質問（またはカード番号がわからない）。 たとえ誰かが私の電子メールを乗っ取ったとしても、私に関するもう少し個人情報を知らない限り、私の PayPal アカウントのパスワードをリセットすることはできません。 何の情報ですか？ PayPal が提供する秘密の質問のオプションは次のとおりです。

学校と病院の質問は検索のしやすさの点で少し微妙かもしれませんが、その他の質問はそれほど悪くありません。 ただし、セキュリティを強化するために、PayPal では追加の ID が必要です。 変更 セキュリティの質問への答え:

PayPal は、安全なパスワード リセットの非常にユートピア的な例です。PayPal は、ブルート フォース攻撃の危険性を軽減するために CAPTCHA を実装し、XNUMX つの秘密の質問を要求し、答えを変更するためだけに別の種類の完全に異なる ID を要求します。はすでにサインインしています。 もちろん、これはまさに私たちが行っていることです 期待される PayPalから; 多額の資金を扱う金融機関です。 これは、すべてのパスワード リセットで次の手順に従う必要があるという意味ではありません (ほとんどの場合、これはやりすぎです)。しかし、これはセキュリティが重要な問題である場合の良い例です。

秘密の質問システムの便利な点は、すぐに実装しなくても、リソース保護のレベルで必要になった場合に後で追加できることです。 この良い例は Apple です。Apple はつい最近このメカニズムを実装しました。 【2012年に書いた記事】。 iPad でアプリケーションの更新を開始すると、次のリクエストが表示されました。

次に、セキュリティの質問と回答のペアをいくつか選択できる画面と、レスキュー用の電子メール アドレスを選択できる画面が表示されました。

PayPal に関しては、質問は事前に選択されており、そのうちのいくつかは実際に非常に優れています。

XNUMX つの質問と回答のペアはそれぞれ、考えられる異なる質問のセットを表しているため、アカウントを構成する方法はたくさんあります。

秘密の質問に答える際に考慮すべきもう XNUMX つの側面は、ストレージです。 データベース内にプレーン テキスト データベースを置くと、パスワードとほぼ同じ脅威が生じます。つまり、データベースが公開されると即座に値が明らかになり、アプリケーションが危険にさらされるだけでなく、同じセキュリティの質問を使用するまったく異なるアプリケーションが危険にさらされる可能性があります (ここでも同様です)。 アサイーベリーの質問）。 XNUMX つのオプションは安全なハッシュ (強力なアルゴリズムと暗号学的にランダムなソルト) ですが、ほとんどのパスワード保存ケースとは異なり、応答がプレーン テキストとして表示されるのには十分な理由がある可能性があります。 典型的なシナリオは、生電話オペレーターによる本人確認です。 もちろん、この場合にもハッシュが適用できます (オペレーターは、クライアントが指定した応答を入力するだけで済みます)。ただし、最悪の場合、秘密の応答は、たとえそれが単なる対称暗号化であっても、あるレベルの暗号ストレージに置かれなければなりません。 。 要約: 秘密は秘密のように扱いましょう！

セキュリティの質問と回答の最後の側面は、ソーシャル エンジニアリングに対してより脆弱であるということです。 他人のアカウントのパスワードを直接抽出しようとすることは別のことですが、パスワードの作成 (一般的な秘密の質問) について会話を始めることはまったく異なります。 実際、あなたは、秘密の質問を引き起こす可能性のある人生のさまざまな側面について、疑いを抱かずに誰かと非常にうまくコミュニケーションをとることができます。 もちろん、秘密の質問の本質は、それが誰かの人生経験に関係しているため、記憶に残るということであり、問​​題はそこにあります。 人々は自分の人生経験について話すのが大好きです。 これに関してできることはほとんどありませんが、セキュリティ質問のオプションを選択して、 少ない おそらくソーシャルエンジニアリングによって引き出される可能性があります。

[つづく。]

広告の権利について

VDSina 信頼できるものを提供します 日払いのサーバー、各サーバーは 500 メガビットのインターネット チャネルに接続されており、DDoS 攻撃から無料で保護されています。

出所： habr.com