Stack Overflowは、特定の技術的な質問だけではなく、一般的な問題のバリエーションを解決するための一般的なガイドラインを提供するリソースであるべきだと考えています。
1.サブトピックを提案する 2.このテーマに関する良い記事を投稿する 3.公式回答の編集
[1]: http://en.wikipedia.org/wiki/OpenID
[3]: http://en.wikipedia.org/wiki/Form-based_authentication [4]: https://en.wikipedia.org/wiki/Uniform_Resource_Locator
ここでは、ログインとパスワードを入力するHTMLフォームを作成し、その値をサーバー側のスクリプトにPOSTして認証を行う方法をすでに知っていると仮定します。以下のセクションでは、健全で実用的な認証のパターンと、最も一般的なセキュリティの落とし穴を回避する方法について説明します。 HTTPS を使うか使わないか? 接続がすでに安全でない限り(つまり、SSL/TLS を使用して HTTPS でトンネルを掘った場合)、ログイン・フォームの値は平文で送信され、ブラウザとウェブ・サーバ間の回線を盗聴している人は、通過するログイン情報を読むことができます。この種の盗聴は政府によって日常的に行われていますが、一般的には、「所有されている」盗聴についてはこのように言う以外にありません。HTTPS を使用してください。 要するに、ログイン時の盗聴/パケット盗聴から守るための唯一の 実用的な 方法は、HTTPS や他の証明書ベースの暗号化スキーム(例えば [TLS][1])、あるいは実証済みでテスト済みのチャレンジ・レスポンス・スキーム(例えば [Diffie-Hellman][2]ベースの SRP)を使用することです。それ以外の方法では、盗聴している攻撃者に簡単に回避されてしまいます。 もちろん、少し非現実的な方法でもよいのであれば、何らかの二要素認証方式を採用することもできます(例:Google Authenticatorアプリ、物理的な「冷戦スタイル」のコードブック、RSAキージェネレータのドングルなど)。正しく適用されていれば、保護されていない接続でも機能しますが、開発者が2要素認証を実装してもSSLを実装しないとは考えにくいでしょう。 JavaScriptの暗号化/ハッシュ化を自分で行う (しない)。 WebサイトにSSL証明書を設定するにはコストがかかり、技術的にも難しいと思われているため、開発者の中には、セキュリティ保護されていない回線に平文のログイン情報を流すことを避けるために、ブラウザ内で独自のハッシュ化や暗号化を行いたいと考える人がいます。 これは立派な考えですが、上記のいずれかと組み合わせなければ本質的に意味がありません([セキュリティ上の欠陥][3]となる可能性もあります)。つまり、強力な暗号化で回線を保護するか、試行錯誤を重ねたチャレンジ・レスポンス・メカニズムを使用するかのいずれかです(チャレンジ・レスポンス・メカニズムが何か分からない場合は、デジタル・セキュリティにおいて最も証明が難しく、設計が困難で、実装が最も難しい概念の1つであることを知っておいてください)。 パスワードをハッシュ化することは、確かにパスワードの公開に対して効果的ではありますが、リプレイ攻撃、中間者攻撃/ハイジャック(ブラウザに届く前の安全でないHTMLページに攻撃者が数バイトを注入することができれば、JavaScriptでハッシュ化をコメントアウトすることができます)、ブルートフォース攻撃(ユーザー名、ソルト、ハッシュ化されたパスワードの両方を攻撃者に渡すことになります)などには弱いです。 CAPTCHA against humanity (人類に対する認証) [CAPTCHA][4]は、ある特定のカテゴリーの攻撃を阻止することを目的としています。それは、人間が操作しない、自動化された辞書/ブルートフォースによる試行錯誤です。しかし、CAPTCHA を使用しなくてもシームレスに対処できる方法があります。特に、適切に設計されたサーバーサイドのログインスロットリングスキームがあります。 CAPTCHA の実装は同じようには作られていないことを知っておいて下さい。人間が解くことができないことが多 く、ほとんどの CAPTCHA はボットには効果がなく、全ての CAPTCHA は第三世界の安価な労働力には効果がなく ([OWASP][5]によると、現在の搾取率は 500 回のテストで 12 ドルだそうです)、国によっては技術的に 違法な実装もあります([OWASP Authentication Cheat Sheet][6]参照)。CAPTCHA を使わなければならない場合は、Google の [reCAPTCHA][7] を使ってください。なぜなら、定義上 OCR ハードであり (すでに OCR で分類されている書籍のスキャンデータを使用しているため)、ユーザーフレンドリーであるように努力しているからです。 個人的には、CAPTCHAはうっとうしいと思う傾向があり、ユーザーが何度もログインに失敗し、スロットリングの遅延が最大になったときの最後の手段としてのみ使用します。CAPTCHAは、ユーザーが何度もログインに失敗し、スロットリングの遅延が最大になったときの最後の手段としてのみ使用します。 パスワードの保存とログインの確認について 近年、大々的に報道されたハッキングやユーザーデータの漏洩事件を経て、ようやく常識になったかもしれませんが、これは言わずにはいられません。データベースにパスワードを平文で保存しないでください。ユーザーデータベースは日常的にハッキングされたり、漏洩したり、SQLインジェクションで不正に取得されたりしていますが、もし生の平文のパスワードを保存していたら、ログインのセキュリティは即刻終わりです。 では、パスワードを保存できない場合、ログインフォームからPOSTされたログイン名とパスワードの組み合わせが正しいかどうかをどうやってチェックするのでしょうか?その答えは「鍵導出関数」[24]を使ったハッシュ化です。新しいユーザーが作成されたり、パスワードが変更されたりするたびに、パスワードをArgon2、bcrypt、scrypt、PBKDF2などのKDFに通して、平文のパスワード("correcthorsebatterystaple")を長くてランダムに見える文字列に変換します。ログインを確認するには、入力されたパスワードに対して同じハッシュ関数を実行し、今度はソルトを渡して、得られたハッシュ文字列をデータベースに保存されている値と比較します。Argon2、bcrypt、scryptでは、ハッシュと一緒にソルトも保存されます。より詳しい情報はsec.stackexchangeの[記事][23]をご覧ください。 ソルトが使用される理由は、ハッシュ自体では十分ではなく、[レインボーテーブル][8]からハッシュを保護するために、いわゆる「ソルト」を追加する必要があるからです。ソルトは、完全に一致する2つのパスワードが同じハッシュ値として保存されるのを効果的に防ぎ、攻撃者がパスワード推測攻撃を実行する際にデータベース全体が一度にスキャンされるのを防ぎます。 ユーザーが選択したパスワードは十分な強度を持たず(つまり、通常は十分なエントロピーを含んでいない)、ハッシュにアクセスできる攻撃者によってパスワード推測攻撃が比較的短時間で完了する可能性があるため、パスワードの保存に暗号ハッシュを使用すべきではありません。これがKDFが使用される理由です。KDFは効果的に["stretch the key"][25]を行い、攻撃者がパスワードを推測するたびに、ハッシュアルゴリズムを複数回、例えば10,000回繰り返し、攻撃者がパスワードを推測するのが10,000回遅くなることを意味しています。 セッションデータ - 「You are logged in as Spiderman69」**。 サーバがログイン名とパスワードをユーザデータベースと照合し、一致するものを見つけたら、システムはブラウザが認証されたことを記憶する方法が必要になります。この事実は、サーバー側のセッションデータにのみ保存されるべきです。
セッションデータについてよく知らない方のために、その仕組みを説明します。ランダムに生成された1つの文字列が、期限切れのクッキーに保存され、サーバーに保存されているデータの集合体(セッションデータ)を参照するために使用されます。もしあなたがMVCフレームワークを使っているなら、これは間違いなくすでに処理されているでしょう。 可能な限り、セッションクッキーがブラウザに送信される際には、secureとHTTP Onlyのフラグが設定されていることを確認してください。HttpOnlyフラグは、XSS攻撃によってクッキーが読み取られるのをある程度防ぐことができます。secure フラグは、クッキーが HTTPS 経由でのみ返送されることを保証し、ネットワーク・スニッフィング攻撃から保護します。クッキーの値は予測可能であってはなりません。存在しないセッションを参照するクッキーが提示された場合には、「セッションの固定化」9を防ぐために、その値は直ちに置き換えられるべきです。
PART II: How To Remain Logged In - The Infamous "Remember Me" Checkbox
一方で、ユーザーがその扱い方を理解している場合には、従来のログインと同様に全く安全です。一方で、公共のコンピュータで使用してログアウトを忘れたり、ブラウザのクッキーが何であるかやその削除方法を知らなかったりするような不注意なユーザーの手にかかると、セキュリティ上の大きなリスクとなります。 個人的には、定期的にアクセスするウェブサイトにはパーシステント・ログインを使用したいと思っていますが、安全に取り扱う方法を知っています。あなたのユーザーが同じことを知っていると確信しているなら、良心の呵責を感じずに持続的ログインを使用することができます。そうでない場合は、ログイン認証情報に無頓着なユーザーは、ハッキングされても自業自得であるという考え方を支持することになるでしょう。私たちは、ユーザーの家に行って、モニターの端に並べられたパスワードを書いたポストイットを剥がすようなことはしませんからね。 もちろん、どんなアカウントでもハッキングされては困るシステムもあります。そのようなシステムでは、持続的なログインを正当化することはできません。 そのようなシステムでは、永続的なログインを正当化することはできません。 もし永続的なログインクッキーを実装することに決めたら、次のようにします。 1.まず、このテーマに関するParagon Initiativeの記事を読むのに時間をかけてください。多くの要素を正しく理解する必要がありますが、この記事ではそれぞれをうまく説明しています。 2.2. よくある落とし穴をもう一度言いますが、 永続的なログイン・クッキー(トークン)をデータベースに保存せず、そのハッシュだけを保存してください! ログイン・トークンはパスワードと等価なので、攻撃者がデータベースを手に入れた場合、あたかも平文のログインとパスワードの組み合わせのように、トークンを使ってあらゆるアカウントにログインできてしまいます。そのため、持続的なログイン・トークンを保存する際には、ハッシュ化(https://security.stackexchange.com/a/63438/5002 によると、弱いハッシュでもこの目的には問題ありません)を使用してください。
PART III: 秘密の質問の使用
「秘密の質問」を実装してはいけません。秘密の質問」機能は、セキュリティのアンチパターンです。MUST-READリストのリンク番号4の論文を読んでください。この件については、サラ・ペイリンに聞いてみてください。彼女のYahooメールアカウントは、以前の大統領選挙中にハッキングされましたが、それは彼女のセキュリティ質問の答えが...だったからです。「ワシラ高校」だったからです。 ユーザーが指定した質問であっても、ほとんどのユーザーがどちらかを選択する可能性が高いです。
- 母親の旧姓や好きなペットなどの「標準的な」秘密の質問
- 自分のブログやLinkedInのプロフィールなど、誰でも知っているような簡単なトリビア
- パスワードを推測するよりも簡単に答えられる質問。まともなパスワードであれば、想像しうるすべての質問です。 **結論として、セキュリティ質問は、事実上すべての形態やバリエーションにおいて本質的に安全ではなく、いかなる理由であれ、認証スキームに採用すべきではありません。 セキュリティ質問が世の中に存在する本当の理由は、電子メールにアクセスできずに再アクティベーションコードを入手できないユーザからのサポートコールを数回分節約できるという便利なものです。これは、セキュリティとサラ・ペイリンの評判を犠牲にしています。その価値はあるか?たぶんないでしょう。
PART IV: Forgotten Password Functionality
ユーザーのパスワードを忘れたり紛失したりしたときに、セキュリティ質問を絶対に使ってはいけない理由はすでに述べました。さらに、この分野では少なくとも2つのよくある落とし穴を避ける必要があります。 1.1. 忘れたパスワードを自動生成された強力なパスワードにリセットしてはいけません。このようなパスワードは覚えておくのが難しいので、ユーザーはパスワードを変更するか、モニターの端にある明るい黄色のポストイットなどに書き留めておかなければなりません。新しいパスワードを設定する代わりに、ユーザーにすぐに新しいパスワードを選んでもらえばいいのです。(ただし、ユーザーがパスワードマネージャーを使って、書き留めないと覚えられないようなパスワードを保存・管理している場合は例外です)。) 2.失ったパスワードのコード/トークンを常にハッシュ化してデータベースに保存する。AGAIN、このコードもPassword Equivalentの一例ですので、攻撃者がデータベースを手に入れた場合に備えて、ハッシュ化しなければなりません。紛失したパスワードコードが要求された場合は、平文のコードをユーザーのメールアドレスに送信し、ハッシュ化してデータベースに保存し、オリジナルは捨ててください。パスワードや永続的なログイントークンのように。 最後の注意点として、「失われたパスワードのコード」を入力するインターフェースは、少なくともログインフォーム自体と同じくらい安全であることを常に確認してください。非常に長い「失われたパスワードコード」(例えば、16文字の大文字と小文字を区別する英数字)を生成することは良いスタートですが、ログインフォーム自体に行うのと同じスロットリングスキームを追加することを検討してください。
PART V: パスワードの強度をチェックする
まず最初に、この小さな記事を読んで現実を確認してください。The 500 most common passwordsという記事があります。 このリストは、あらゆるシステムで最も一般的なパスワードの正統なリストではないかもしれませんが、強制的なポリシーが存在しない場合に、人々がどれほど不適切なパスワードを選択するかを示す良い指標となっています。さらに、最近盗まれたパスワードの公開された分析結果と比較すると、このリストは恐ろしく身近なものに見えます。 つまりパスワード強度の最低要件がない場合、ユーザーの2%が最も一般的なパスワードの上位20個のうちの1つを使用している。つまり、攻撃者が20回試行すれば、Webサイトの50個のアカウントのうち1個がクラック可能になるということです。 これを阻止するには、パスワードのエントロピーを計算し、閾値を適用する必要があります。 米国国立標準技術研究所(NIST)のSpecial Publication 800-63には、非常に優れた提案がまとめられています。 それを、辞書やキーボードレイアウトの分析(例えば、「qwertyuiop」は悪いパスワードである)と組み合わせれば、18ビットのエントロピーのレベルで、「選択されていないパスワードの99%を拒否」13することができます。 単にパスワードの強度を計算し、ユーザーに強度メーターを見せるだけでは、良いことではあるが不十分である。 強制的に実施しない限り、多くのユーザーはそれを無視するでしょう。 また、高エントロピーのパスワードの使いやすさについては、Randall MunroeのPassword Strength xkcdを強くお勧めします。 トロイ・ハントのHave I Been Pwned APIを利用して、ユーザーのパスワードを、公的なデータ漏洩の際に漏洩したパスワードと照合してみましょう。
PART VI: Much More - Or: Preventing Rapid-Fire Login Attempt
まず、数字を見てみましょう。パスワードの回復速度 - あなたのパスワードはどのくらい耐えられるか。 そのリンク先の表に目を通す時間がなければ、ここにそのリストがあります。 1.脆弱なパスワードを解読するには、そろばんで解いていても事実上時間がかかりません 2.大文字小文字を区別しない場合、英数字の9文字のパスワードを解読するのに、事実上時間がかかりません。 3.3. 8文字以下の複雑な記号と文字と数字の大文字と小文字のパスワードを解読するのに、時間はかからない(デスクトップPCは7文字までの全キースペースを数日から数時間で検索できる)。 4.**しかし、6文字のパスワードを解読するには、1秒間に1回しか試みられないとすると、膨大な時間がかかります**。 では、この数字から何がわかるのでしょうか?それは、大量の連続したログイン試行(ブルートフォース攻撃)を防ぐことは、それほど難しいことではないということです。しかし、正しい方法で防ぐことは、見かけほど簡単ではありません。 一般的には、ブルートフォース攻撃(および辞書攻撃)に対して効果的な3つの選択肢があります(ただし、すでに強力なパスワードポリシーを採用しているため、問題にはなりません)。
- N回失敗した後にCAPTCHAを提示する(非常に煩わしく、効果がないことも多いですが、ここでは繰り返しになります)。
- N回失敗するとアカウントをロックし、電子メールによる認証を要求する(これはDoS攻撃が起こるのを待っているようなものです)。
- そして最後に、login throttling:つまり、N回失敗した後、試行の間に時間的な遅延を設定することです(はい、DoS攻撃はまだ可能ですが、少なくともその可能性ははるかに低く、実行するにはより複雑です)。 ベストプラクティス1:失敗した回数に応じて増加する短い遅延時間を設定する、というものです。
- 1回の試行失敗=遅延なし
- 2回の失敗=2秒の遅延
- 3回の失敗=4秒の遅延
- 4回の失敗=8秒の遅延
- 5回の試行失敗=16秒の遅延
- などとなります。 この方式でDoS攻撃を行うと、結果的にロックアウト時間が以前のロックアウト時間の合計よりもわずかに大きくなるため、非常に実用的ではありません。 明確にするために、この遅延はブラウザにレスポンスを返すまでの遅延ではありません。これは、特定のアカウントまたは特定のIPアドレスからのログイン試行がまったく受け入れられない、または評価されないタイムアウトまたは屈折期間のようなものです。つまり、正しい認証情報であればログインが成功し、正しくない認証情報であれば遅延時間が増加することはありません。 ベストプラクティス2: N回失敗した後に有効になる中程度の長さの遅延時間を設定します。
- 1-4回の試行失敗 = 遅延なし
- 5回失敗した場合、15~30分の遅延 この方式でDoS攻撃を行うことは、現実的ではありませんが、確実に可能です。また、このような長い遅延は、正当なユーザーにとって非常に迷惑なものであることにも注意が必要かもしれません。忘れっぽいユーザーには嫌われてしまいます。 ベストプラクティス#3: 2つのアプローチを組み合わせることで、以下のように、N回の試行失敗後に有効となる固定の短い遅延時間を設けることができます。
- 1-4回の試行失敗 = 遅延なし
- 5回以上の試行失敗=20秒の遅延 または、一定の上限を設けて遅延時間を長くしていく方法。
- 1回の試行失敗=5秒の遅延
- 2回の試行失敗=15秒の遅延
- 3回以上の試行失敗=45秒の遅延 この最終的なスキームは、OWASP best-practices suggestions(MUST-READリストのリンク1)から引用したもので、確かに制限的な面があるとしても、ベストプラクティスとみなされるべきです。 しかし、経験則から言うと、パスワードポリシーが強力であればあるほど、ユーザーに遅れを取らせないようにする必要があります。強力な(大文字と小文字を区別する英数字+必須の数字と記号)9文字以上のパスワードを要求する場合は、スロットリングを有効にする前に、ユーザーに2~4回の遅延のないパスワード試行を行うことができます。 この最終的なログイン・スロットリング・スキームをDoS攻撃することは、非常に現実的ではありません。また、最後の仕上げとして、永続的な(クッキー)ログイン(および/またはCAPTCHAで検証されたログインフォーム)を常に通過させることで、正当なユーザーは攻撃が進行している間も遅延することはありません。このようにして、非常に非現実的なDoS攻撃が、非常に*非現実的な攻撃になります。 さらに、管理者アカウントは最も魅力的なエントリーポイントであるため、より積極的なスロットリングを行うことは理にかなっています。
PART VII: Distributed Brute Force Attacks
余談ですが、より高度な攻撃者は、「活動を分散させる」ことでログイン・スロットルを回避しようとします。
- ボットネット上で試行回数を分散させ、IPアドレスのフラグ立てを防ぐ
- 1人のユーザーを選んで50,000件の最も一般的なパスワードを試すのではなく(スロットリングがあるのでできません)、最も一般的なパスワードを選んで50,000人のユーザーに試すのです。このようにして、CAPTCHAやログインスロットルのような最大試行回数を回避するだけでなく、最も一般的なパスワードの1番は49.995番よりもはるかに可能性が高いため、成功する確率も高くなります。
- 各ユーザーアカウントへのログイン要求を、例えば30秒間隔で行うことで、レーダーをかいくぐる。 ここでのベストプラクティスは、システム全体のログイン失敗回数を記録し、サイトのログイン失敗回数の連続した平均値をベースにして、すべてのユーザーに課す上限値を決めることです。 抽象的すぎますか?言い換えてみましょう。 過去3ヶ月間、あなたのサイトでは1日平均120回の不正ログインが発生していたとします。この平均値をもとに、システムはグローバルリミットをその3倍、つまり24時間で360回の失敗を想定しています。そして、すべてのアカウントで失敗した試行回数の合計が1日以内にその数を超えた場合(あるいは、加速率を監視して計算された閾値をトリガーとした方が良いでしょう)、システム全体のログインのスロットリングが有効になります - つまり、すべてのユーザーに短い遅延が発生します(ただし、クッキーログインやバックアップCAPTCHAログインは例外です)。 私はまた、分散ブルートフォース攻撃から逃れるために、より詳細で、トリッキーな落とし穴を回避する方法についての実に良い議論を含む質問を投稿しました。
PART VIII: Two-Factor Authentication and Authentication Providers
認証情報は、悪用されたり、パスワードを書き留めて紛失したり、鍵付きのノートパソコンを盗まれたり、ユーザーがフィッシングサイトにログイン情報を入力したりすることで、漏洩する可能性があります。 二要素認証は、電話、SMSメッセージ、アプリ、ドングルなどから受け取る使い捨てのコードなど、帯域外の要素を使用することで、ログインをさらに保護することができます。2ファクタ認証サービスを提供しているプロバイダーもあります。 認証は、シングル・サインオン・サービスに完全に委ねることができ、認証情報の収集は別のプロバイダーが行う。これにより、問題を信頼できるサードパーティに押し付けることができる。GoogleとTwitterは標準ベースのSSOサービスを提供しており、Facebookは同様の独自のソリューションを提供している。
MUST-READ LINKS About Web Authentication
1.OWASP Guide To Authentication / OWASP Authentication Cheat Sheet。 2.Dos and Don'ts of Client Authentication on the Web (very readable MIT research paper) 2. 3.ウィキペディア: HTTP クッキー 3. 4.フォールバック認証のための個人的な知識の質問。Facebook時代のセキュリティに関する質問(非常に読みやすいバークレーの研究論文)。
認証情報を100%安全に送信するには、SSLを使用するのが現実的です。パスワードのハッシュ化にJavaScriptを使用することは安全ではありません。クライアントサイドでのパスワードハッシュ化によくある落とし穴。
データベースにパスワードを平文で保存することは絶対にやめましょう。自分のサイトのセキュリティを気にしていなくてもです。ユーザーの中には、オンライン銀行口座のパスワードを再利用する人がいるとします。そこで、ハッシュ化したパスワードを保存し、元のパスワードは捨てます。そして、そのパスワードがアクセスログやアプリケーションログに表示されないようにしてください。OWASP は、新しいアプリケーションの最初の選択肢として、Argon2の使用を推奨しています。これが使用できない場合は、代わりに PBKDF2 または scrypt を使用する必要があります。そして最後に、上記のどれも利用できない場合は、bcryptを使用します。 ハッシュはそれだけでは安全ではありません。例えば、同一のパスワードは同一のハッシュを意味します。このため、ハッシュルックアップテーブルは、一度に多くのパスワードをクラックするのに有効な手段となります。代わりに、ソルトされたハッシュを保存する。ソルトとは、ハッシュ化する前にパスワードに付加される文字列のことで、ユーザーごとに異なる(ランダムな)ソルトを使用します。ソルトは公開値なので、ハッシュと一緒にデータベースに保存することができます。これについてはこちらを参照してください。 これは、ユーザーに忘れたパスワードを送ることができないことを意味します(ハッシュしか持っていないため)。ユーザーを認証しない限り、ユーザーのパスワードをリセットしてはいけません(ユーザーは、保存された(検証された)メールアドレスに送られたメールを読むことができることを証明する必要があります)。
セキュリティ質問は安全ではありません - 使用を避けてください。なぜでしょうか?セキュリティ質問でできることは、パスワードの方が優れています。このWikiの@Jens Roland answerの PART III: Using Secret Questions を読んでください。
ユーザーがログインすると、サーバーはユーザーにセッションクッキーを送信します。サーバはクッキーからユーザ名やIDを取得できますが、他の誰もそのようなクッキーを生成することはできません(TODOではその仕組みを説明しています)。 ユーザーを自動ログインさせたい場合は、永続的なクッキーを設定することができますが、それはフルセッションのクッキーとは異なるものでなければなりません。ユーザーが自動ログインしたことを示す追加のフラグを設定することができ、機密性の高い操作のために実際にログインする必要があります。これは、お客様にシームレスでパーソナライズされたショッピング体験を提供しつつ、お客様の財務情報を保護したいショッピングサイトに人気があります。例えば、アマゾンに再訪問すると、ログインしているように見えるページが表示されますが、注文(または配送先住所やクレジットカードなどの変更)をしようとすると、パスワードの確認を求められます。 一方、銀行やクレジットカードなどの金融系のWebサイトは、機密データしか持っていないので、自動ログインやセキュリティの低いモードを許可してはいけません。
まず最初に、この回答はこの質問に最適なものではないという強い注意点があります。絶対にトップの答えではないはずです
先に、Mozillaが提案しているBrowserID(正確にはVerified Email Protocol)について触れておきますが、これは将来的に認証に対するより良いアプローチへのアップグレードパスを見つけるための精神です。
こんな風にまとめてみます。
1.1.Mozillaは、この問題の良い解決策を見つけることに適した価値観を持つ非営利団体である。
2.今日の現実は、ほとんどの Web サイトがフォームベースの認証を使用していることです。
3.フォームベース認証には大きな欠点があり、それはフィッシングのリスクが高まることです。ユーザーは、ユーザーエージェント(ブラウザ)が管理する領域ではなく、遠隔地のエンティティが管理する領域に機密情報を入力するよう求められます。
4.4. ブラウザは暗黙のうちに信頼されているので(ユーザーエージェントの全体的な考え方は、ユーザーの代わりに行動することです)、この状況を改善することができます。
5.ここでの進展を妨げている主な力は、デプロイメントのデッドロックです。解決策は、それ自体である程度の利益をもたらすステップに分解されなければなりません。
6.インターネットのインフラに組み込まれている、アイデンティティを表現するための最もシンプルな分散型の方法は、ドメイン名です。
7.7. アイデンティティを表現する第2レベルとして、各ドメインは独自のアカウントセットを管理する。
8.account@
domain "という形式は簡潔であり、広範囲のプロトコルおよび URI スキームで サポートされている。このような識別子は、もちろん、電子メールアドレスとして最も一般的に認識されています。
9.9. 電子メール・プロバイダは、すでにオンライン上の事実上の主要な ID プロバイダである。現在のパスワード・リセット・フローでは、通常、そのアカウントの関連する電子メール・ アドレスを管理していることを証明できれば、そのアカウントを管理することができる。
10.Verified Email Protocolは、ドメインAにアカウントを持っていることをドメインBに証明するプロセスを合理化するために、公開鍵暗号方式に基づく安全な方法を提供するために提案された。
11.Verified Email Protocolに対応していないブラウザ(現在は全てのブラウザ)に対して、MozillaはクライアントサイドのJavaScriptコードでプロトコルを実装するshimを提供しています。
12.Verified Email Protocolに対応していないメールサービスでは、第三者が信頼できる仲介者として、ユーザーのアカウント所有権を確認したことを表明することができます。この機能は、アップグレードパスを可能にするためだけのものであり、電子メールサービスがこれらのアサーションを自ら提供することがはるかに望ましいのです。
13.Mozilla は、このような信頼できる第三者のように振る舞う独自のサービスを提供しています。Verified Email Protocol を実装しているサービスプロバイダ(つまり、 依拠当事者)は、Mozilla の主張を信頼するかどうかを選択することができます。モジラのサービスは、確認リンク付きの電子メールを送信するという従来の方法で、ユーザーのアカウント所有権を確認します。
14.14. サービス提供者は、当然のことながら、提供したい他の認証方法に加えて、このプロトコルをオプションとして提供することができる。
15.ここで求められている大きなユーザーインターフェースの利点は、「IDセレクター」です。ユーザがサイトを訪問し、認証を選択すると、ブラウザには、サイトで自分を識別するために使用できる電子メールアドレス(「個人用」、「仕事用」、「政治活動用」など)の選択肢が表示されます。
16.この取り組みの一環として求められているもう一つの大きなユーザーインターフェースの利点は、ブラウザがユーザーのセッションについてより詳しく知ることができる、つまり、主に現在誰としてサインインしているかを、ブラウザのクロームに表示することができることです。
17.このシステムは分散型であるため、Facebook、Twitter、Googleなどの大手サイトへのロックインを回避することができます。誰もが自分のドメインを所有することができるので、自分のIDプロバイダーとして機能します。
これは厳密には「ウェブサイトのフォームベース認証」ではありません。しかし、フォームベースの認証という現在の常識から、ブラウザでサポートされる認証という、より安全なものに移行するための取り組みです。