🐃 💃 🤳🏽 パスワードを安全にリセットすることについて知りたいことすべて。パート1 🤽🏼 🏑 👨🏽‍🏫

最近、セキュアパスワードリセット機能がどのように機能するかを再考する時間がありました。最初にこの機能をASafaWebに組み込んでいたとき、次に他の人が同様のことをするのを手伝ったときです。 2番目のケースでは、リセット機能の安全な実装のすべての詳細を含む正規のリソースへのリンクを彼に提供したいと思いました。しかし、問題は、そのようなリソースが存在しないことです。少なくとも、私にとって重要と思われるすべてを説明するリソースがあります。それで自分で書くことにしました。

ほら、パスワードを忘れた世界は実はかなり不思議です。多くの異なる、完全に受け入れられる視点と非常に危険な視点がたくさんあります。エンドユーザーとして何度もそれらのそれぞれに遭遇した可能性があります。したがって、これらの例を使用して、誰が正しく実行しているか、誰が正しく実行していないか、およびアプリケーションに関数を適切に実装するために何に焦点を当てるべきかを示します。

パスワードの保存：ハッシュ、暗号化、および（ooh！）プレーンテキスト

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

シンプルなテキスト。プレーンテキストで保存されるパスワード列があります。
. ( ), .
. ( , ); , , , .

最も簡単な質問でそれをまっすぐにしましょう：パスワードをプレーンテキストで保存しないでください！決して。 1回の注入の脆弱性、1回の不注意によるバックアップ、またはその他の数十の単純な間違いの1つ（ゲーマー、すべてのパスワード）、つまり、申し訳ありませんが、すべての顧客のパスワードがパブリックドメインになります。もちろん、これは、他のシステムのすべてのアカウントのすべてのパスワードがパブリックドメインになる可能性が非常に高いことを意味します。そして、それはあなたのせいになります。

暗号化の方が優れていますが、弱点があります。暗号化の問題は復号化です。あなたはそれらのクレイジーに見える暗号を取り、それらをプレーンテキストに戻すことができます、そしてそれが起こったとき、私たちは読み取り可能なパスワードで状況に戻ります。これはどのように起こりますか？小さな欠陥がパスワードを復号化するコードに侵入し、パスワードを公開します。これは1つの方法です。ハッカーは、暗号化されたデータが保存されているマシンにアクセスできます。これは2番目の方法です。もう1つの方法は、データベースのバックアップを盗むことです。暗号化キーも取得されますが、これは非常に安全でないことがよくあります。

そして、それは私たちにハッシュをもたらします。ハッシュの背後にある考え方は、それが一方向で行われるということです。ユーザーが入力したパスワードをハッシュされたバージョンと比較する唯一の方法は、入力されたパスワードをハッシュして比較することです。レインボーテーブルなどのツールによる攻撃を防ぐために、saltを使用してプロセスにランダム性を追加します（全体像については、暗号化ストレージに関する私の投稿を読んでください）。最終的に、正しく実装されていれば、ハッシュ化されたパスワードが二度とプレーンテキストになることはないと自信を持って想定できます（さまざまなハッシュアルゴリズムの利点については別の投稿で説明します）。

ハッシュと暗号化についての簡単な説明：パスワードをハッシュするのではなく暗号化する必要がある唯一の理由は、パスワードをプレーンテキストで表示する必要があり、少なくとも標準では表示したくない場合です。ウェブサイト。あなたがそれを必要とするならば、あなたはおそらく何か間違ったことをしているでしょう！

注意！

以下の投稿のテキストは、ポルノウェブサイトAlotPornのスクリーンショットの一部です。きちんとトリミングされているので、ビーチで見ることができないものはありませんが、それでも問題が発生する可能性がある場合は、ページを下にスクロールしないでください。

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

パスワードリマインダー 機能を作成するように求められたことはありますか？一歩下がって、この要求について逆に考えてください。なぜこの「リマインダー」が必要なのですか？ユーザーがパスワードを忘れたため。私たちは本当に何をしたいですか？彼が再びログインするのを手伝ってください。

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

— . , HTTP ( HTTPS), , . , , , , , , , . — .
. — ( ), .

例としてusoutdoor.comの問題を説明しましょう：これは典型的なログインページです：

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

残念ながら、見た目はそれほど良くありません。そして電子メールは問題を確認します：

これは、usoutdoor.comの2つの重要な側面を示しています。

このサイトはパスワードをハッシュしません。せいぜい暗号化されていますが、プレーンテキストで保存されている可能性があります。反対の証拠は見当たりません。
このサイトは、セキュリティで保護されていないチャネルを介して長期パスワードを送信します（戻って何度も使用できます）。

これを念頭に置いて、リセットプロセスが安全な方法で実行されているかどうかを確認する必要があります。これを行うための最初のステップは、リクエスターがリセットを実行する権利を持っていることを確認することです。つまり、その前にIDチェックが必要です。リクエスターが実際にアカウントの所有者であることを最初に確認せずに、IDが確認されたときに何が起こるかを見てみましょう。

ユーザー名の一覧表示とその匿名性への影響

この問題は視覚的に最もよく示されています。問題：

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

もちろん、ポルノはプライバシーの重要性のかなり標準的な例ですが、特定のWebサイトに人を関連付ける危険性は、上記の潜在的に恥ずかしい状況よりもはるかに広いです。危険の1つは社会工学です。攻撃者がその人をサービスと照合できる場合、攻撃者は使用を開始できる情報を入手できます。たとえば、彼はWebサイトのスポークスパーソンを装った人に連絡し、スピアフィッシングを試みるために詳細情報を要求する場合があります。

このような方法では、「ユーザー名の列挙」の危険性も高まります。この場合、簡単なグループクエリを使用して、ウェブサイト上のユーザー名またはメールアドレスのコレクション全体の存在を確認し、それらへの応答を調べることができます。すべての従業員の電子メールアドレスのリストと、スクリプトを作成するための数分はありますか？次に、問題が何であるかがわかります。

代替手段は何ですか？実際、これは非常に単純で、Entropayで適切に実装されています。

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

もちろん、誰かが自分がWebサイトに登録したと思う状況は受け入れられます。しかし、そうではないか、別のメールアドレスから実行しました。上に示した例は、両方の状況をうまく処理します。もちろん、アドレスが一致すると、パスワードのリセットを簡単にするメールが届きます。

Entropayソリューションの微妙な点は、オンライン検証の前に電子メールを介してID検証が行われることです。一部のサイトでは、ユーザーに秘密の質問をする前に（これについては以下で詳しく説明します）リセットを開始する方法。ただし、これに伴う問題は、何らかの形式のID（メールまたはユーザー名）を提供しながら質問に回答する必要があることです。これにより、匿名のユーザーアカウントの存在を明らかにせずに、直感的に回答することはほとんど不可能になります。

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

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

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

次に説明する必要がある概念は、パスワードをリセットする方法に関連しています。2つの一般的な解決策があります。

サーバーで新しいパスワードを生成し、それを電子メールで送信する
リセットプロセスを簡素化するために、一意のURLを記載したメールを送信します

多くのチュートリアルにもかかわらず、最初のポイントは決して使用しないでください。その問題は、いつでも返して再利用できる保存されたパスワードがあることを意味します。保護されていないチャネルを介して送信され、受信トレイに残ります。受信トレイはモバイルデバイスと電子メールクライアントに同期される可能性があります。さらに、受信トレイはWeb電子メールサービスに非常に長期間オンラインで保存できます。重要なのは、メールボックスを長期保存用の信頼できる媒体と見なすことはできないということです。

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

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

リセットURLとして電子メールで送信し、ユーザーアカウントに対してサーバーレコードと照合できる一意のトークンを作成して、アカウントの所有者が実際にパスワードをリセットしようとしているのと同じ人物であることを確認します。 ..。たとえば、トークンは「3ce7854015cd38c862cb9e14a1ae552b」の形式にすることができ、リセットするユーザーのユーザーIDとトークンが生成された時刻とともにテーブルに格納されます（これについては以下で詳しく説明します）。メールを送信するときは、「Reset /？id = 3ce7854015cd38c862cb9e14a1ae552b」のようなURLが含まれ、ユーザーがそれを読み込むと、ページはトークンの存在を要求し、その後、ユーザーの情報を確認してパスワードの変更を許可します。

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

また、リセットURLの場合、トークンの時間制限を追加して、リセットプロセスを特定の間隔（たとえば1時間以内）で実行できるようにする必要があります。これにより、リセットウィンドウが最小限に抑えられ、このリセットURLの受信者はこの非常に小さなウィンドウ内でのみ動作できます。もちろん、攻撃者はリセットプロセスを再開できますが、別の一意のリセットURLを取得する必要があります。

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

これらの手順の一部は過度に冗長に見えるかもしれませんが、まれであると思われる状況ではありますが、使いやすさをまったく妨げず、実際にセキュリティを強化します。99％の場合、ユーザーは非常に短い時間内にリセットを実行し、近い将来にパスワードを再度リセットすることはありません。

CAPTCHAの役割

ああ、CAPTCHA、私たち全員が嫌うのが大好きな治療法！実際、CAPTCHAは、識別ほどの保護を意味しません。あなたは人間またはロボット（または自動化されたスクリプト）です。その目的は、自動フォーム送信を回避することです。もちろん、セキュリティ違反の試みとして使用される可能性があります。パスワードをリセットする場合、CAPTCHAは、リセット機能をブルートフォースでクラックして、ユーザーにスパムを送信したり、アカウントの存在を確認したりすることはできないことを意味します（もちろん、本人確認のセクションのアドバイスに従った場合、これは不可能です）。

もちろん、CAPTCHA自体は理想的ではありません。そのソフトウェアの「ハッキング」と十分な成功率（60-70％）の達成には多くの前例があります。さらに、自動化された人々によるCAPTCHAのハッキングについての私の投稿に示されている解決策があります。そこでは、各CAPTCHAを解決し、94％の成功率を得るのに数分の1セントを支払うことができます。つまり、脆弱ですが、（わずかに）侵入の障壁が高くなります。

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

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

ただし、ほとんどのWebアプリケーションでは、これはやり過ぎであり、間違いなく使いやすさが低下します。人々はCAPTCHAが好きではありません。また、CAPTCHAは、必要なときに簡単に再訪できるものです。サービスが攻撃され始めた場合（ここではログ記録が役立ちますが、後で詳しく説明します）、CAPTCHAを追加するのは簡単ではありません。

秘密の質問と回答

私たちが調べたすべての方法で、電子メールアカウントにアクセスするだけでパスワードをリセットすることができました。私は「ただ」と言いますが、もちろん、他人のメールアカウントに不法にアクセスすることは難しいに違いありません。ただし、これが常に当てはまるとは限りません。

実際、SarahPalinのYahoo!のハッキングに関する上記のリンク2つの目的を果たします。まず、（一部の）電子メールアカウントをハッキングするのがいかに簡単であるかを示し、次に、悪いセキュリティの質問が悪意を持って使用される可能性があることを示します。しかし、後でこれに戻ります。

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

このリスクを軽減する1つの方法は、セキュリティに関する質問と回答のパターンを実装することです。あなたが以前にそれらを見たことがあることは間違いありません：あなただけが答えなければならない質問を選んでください答えを知ってください。その後、パスワードをリセットすると、尋ねられます。これにより、リセットしようとしている人が実際にアカウントの所有者であるという確信が高まります。

サラ・ペイリンに戻ると、間違いは彼女のセキュリティに関する質問への答えが簡単に見つけられるということでした。特に、あなたがそのような重要な人物である場合、あなたの母親の乙女の名前、学歴、または誰かが過去に住んでいた可能性のある場所に関する情報はそれほど秘密ではありません。実際、そのほとんどはほとんど誰でも見つけることができます。そして、それはサラで起こりました：

ハッカーのDavidKernellは、大学や生年月日などの背景情報を見つけ、Yahoo！アカウントのパスワード回復機能を使用して、Palinのアカウントにアクセスしました。

これは主にYahoo!側の設計上の欠陥です。 -これらの簡単な質問を指摘することにより、会社は本質的に秘密の質問の価値を妨害し、したがってシステムの保護を妨害しました。もちろん、所有者に電子メールを送信して所有権を確認することはできないため（2番目のアドレスがないと）、電子メールアカウントのパスワードのリセットは常に困難ですが、幸いなことに、今日そのようなシステムを作成する方法は多くありません。

秘密の質問に戻る-ユーザーが独自の質問を作成できるようにするオプションがあります。問題は、結果がひどく明白な質問になるということです：

空は何色ですか？

人がセキュリティの質問を使用して特定するときに、人を厄介な立場に置く質問（例：コールセンター）：

クリスマスに誰と一緒に寝ましたか？

またはまったく愚かな質問：

「パスワード」の綴りはどうですか？

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

良いセキュリティの質問は何ですか？これはいくつかの要因の影響を受けます。

それはする必要があります短い-質問は明確かつ明瞭でなければなりません。
答えは具体的でなければなりません-1人がさまざまな方法で答えることができる質問は必要ありません
考えられる答えはさまざまです-誰かの好きな色について尋ねると、考えられる答えのごく一部が得られます
— ( , ),
— - ,

たまたま、GoodSecurityQuestions.comという良い質問のウェブサイトがあります。いくつかの質問は非常に良いようですが、他の質問は上記のテストのいくつか、特に「検索のしやすさ」テストに合格しません。

PayPalでセキュリティに関する質問がどのように実装されているか、特にサイトが特定するためにどれだけの労力を費やしているかをお見せしましょう。上に（CAPTCHAを使用して）プロセスを開始するためのページが表示されましたが、ここでは、電子メールアドレスを入力してCAPTCHAを解決した後に何が起こるかを示します。

その結果、ユーザーは次の文字を受け取ります。

これまでのところ、これは正常ですが、このリセットされたURLの背後にあるものは次のとおりです。

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

学校や病院の質問は、検索のしやすさの点で少し疑わしいかもしれませんが、残りはそれほど悪くはありません。ただし、セキュリティを向上させるために、PayPalではセキュリティの回答を変更するために追加のIDが必要です。

PayPalは、安全なパスワードリセットの非常にユートピア的な例です。CAPTCHAを実装してブルートフォースのリスクを軽減し、2つの秘密の質問を必要とし、回答を変更するためだけに別の種類のまったく異なるIDを必要とします。これはユーザーがすでにサインインした後です。もちろん、これはPayPalに期待されることです。大量のお金を扱う金融機関です。これは、すべてのパスワードのリセットがこれらの手順に従う必要があることを意味するわけではありません（ほとんどの場合、やり過ぎです）が、セキュリティが深刻なビジネスである場合の良い例です。

秘密の質問のシステムの便利さは、すぐに実装しなかった場合、リソース保護のレベルで必要な場合は後で追加できることです。この良い例は、このメカニズムを最近実装したばかりのAppleです[2012年に作成]。iPadでアプリの更新を開始すると、次のリクエストが表示されました。

次に、秘密の質問と回答の複数のペア、およびレスキューメールアドレスを選択できる画面が表示されました。

PayPalに関しては、質問は事前に選択されており、それらのいくつかは実際にはかなり良いです：

質問と回答の3つのペアはそれぞれ、考えられる質問の個別のセットを表すため、アカウントを構成する方法は十分にあります。

セキュリティに関する質問への回答に関して考慮すべきもう1つの側面は、ストレージです。 DBでプレーンテキストを見つけると、パスワードの場合とほぼ同じ脅威が発生します。つまり、データベースを開示すると、その意味が即座に明らかになり、アプリケーションだけでなく、同じセキュリティの質問を使用する完全に異なるアプリケーションも危険にさらされます（これもベリーの質問です）。 acai）。 1つのオプションは、安全なハッシュ（強力なアルゴリズムと暗号的にランダムなソルト）ですが、ほとんどのパスワードストレージの場合とは異なり、応答がプレーンテキストとして表示されるのには十分な理由があります。典型的なシナリオは、電話によるライブオペレーターによる本人確認です。もちろん、この場合、ハッシュも適用できます（オペレーターは、クライアントによって指定された応答を入力するだけです）が、最悪の場合、対称暗号化であっても、秘密の答えは暗号化ストアのあるレベルにある必要があります。要約すると、秘密を秘密として扱ってください！

そして、秘密の質問と回答の最後の側面-それらは社会工学に対してより脆弱です。他の人のアカウントのパスワードを直接引き出すことを試みることは1つのことですが、その教育についての会話（一般的な秘密の質問）を打ち出すことはまったく別のことです。実際、疑いを持たずに、セキュリティ上の問題を構成する可能性のある生活の多くの側面について、非常に現実的に誰かとコミュニケーションをとることができます。もちろん、秘密の質問の本質は、それが誰かの人生経験に関連しているということです、それでそれは覚えられています、そしてこれはまさに問題です-人々は彼らの人生経験について話すのが大好きです！社会工学によって引き出される可能性が低くなるようにセキュリティ質問オプションを選択することによってのみ、それについてできることはほとんどありません。

[つづく。]

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