OpenID / OAuth / Facebookと比較したBrowserID / Personaの欠点は何ですか？
Mozillaは BrowserID/Persona （ announcement 、 background ）と呼ばれる新しいサービスで稼働しました。 OpenID、OAuthおよびFacebookなどの現在のシングルサインオンソリューションを置き換えることを目的としています。
1つの利点は、 ブラウザへの将来の統合 がフィッシングリスクを軽減することです。また、IDプロバイダーは、誰かがログインしたサイトについて通知されないため、プライバシーの観点からは優れています。
OpenID/OAuth/Facebookと比較したBrowserID/Personaの問題は何ですか？
アイデアは好きですが、私も多くの質問を未解決のままにしています。私の認証経験をこの新しいスキームに適用しようと書いたので、これをいかなる形のバッシングとも見なさないでください。
私は心配しています（順不同）：
- 秘密鍵の不正使用
- リッチクライアントサポート（Outlook、Notesなど）
- 複数のコンピューターから使用する
- 秘密鍵の保護または暗号化（クライアント上）
- 鍵生成リクエストの認証
- プライバシー
詳細は以下。最初に1行の要約（太字の斜体）といくつかの説明。
1.秘密鍵の不正使用
秘密キーは、さまざまなセキュリティレベルでクライアントによって保護されます。
秘密鍵が私の同意なしに使用されることを心配しています。認証しようとすると、署名操作が行われます。使用する前にプロンプトを表示する必要があります。そうしないと、悪意のあるスクリプトがブラウザにログオンチケットに署名して送信してしまう可能性があります。不正スクリプトは、ウィジェット、追加、またはその他のXSSから来る可能性があります。このメカニズムの実装は、ブラウザごとに、また同じブラウザの異なるプラットフォームや異なるバージョンなどでも異なります。多少一貫性のないビジュアルでは、ユーザーはログオン要求を承認するように誘惑されるリスクが高くなります。
2.リッチクライアントサポート（Outlook、Notesなど）
Webメールアカウントで動作するように設計されていました。エンタープライズ「ファット」メールクライアントはやや取り残されています。
ブラウザーIDを機能させるには、それをサポートするブラウザーが必要です。その間、一部のbrowserid.orgは、「JavaScriptに実装された標準のHTML5技術と暗号化ルーチンを使用して、不足している機能を実装するJavaScriptシム」を発行しました。
ファットメールクライアント（Outlook、Notes、Thunderbird）を使用する企業環境のユーザーは、プロトコルをこれらのクライアントにも実装する必要があるため、後期採用者になります。 OutlookがFirefoxと、またはIEとThunderbirdでキーストアを共有しないことは言うまでもありません。
3.複数のコンピューターから使用する
スキームには中央権限がないため、秘密鍵が急増します。
そして、移動性の問題があります。使用するすべてのコンピューターに登録（秘密鍵を生成）する必要があります。インターネットキオスクまたは借りたコンピューターで秘密キーを削除するにはどうすればよいですか？ 1台のコンピューターでも、盗まれたコンピューターに格納されているキーをどのようにして取り消すのですか？ 1人のユーザーには複数の署名キーが有効であるため（私のコンピューターにはそれぞれ独自の有効な秘密キーがあるため）、サービスプロバイダーの観点からは、既知の機関によって署名されたアクセストークンはすべて有効である必要があります。
4.秘密鍵の保護または暗号化（クライアント上）
キーへのアクセスは認証される必要があります。これにより、パスワードが画面に表示されます。
パスワード（悪意のある再利用を制限する）で保護できますが、どこかでパスワードを変更した場合、ブラウザー/クラウドベースの同期ネットワークを使用しない限り同期されません。パスワードを覚えておくと、このスキームの目的が多少損なわれます。同じパスワードが複数のWebサイトの認証に使用されるように、すべてのキーを保護するために同じパスワードが使用される可能性があります。
5.キー生成リクエストの認証
攻撃者がフィッシングに使用できる、アクセス要求とキー生成の間にギャップがあります。
電子メールプロバイダー/認証局がCSRFの問題をどのように処理するかは不明です。鍵生成の要求が正当であることを彼らはどのように知るのでしょうか？スパムフォルダーは証明書生成リクエストで満たされますか？または、キーはDKIM電子メールサーバーでのみ発行されますか？サーバーへのSMTP経路で要求が傍受された場合、それを変更できますか？
6.プライバシー
タグを使用すると、browserid.orgは同じOriginポリシーを破ることができます。
また、scriptidタグを使用してbrowserid.jsを含めると、同じOriginポリシーをバイパスできます。 BrowserID.orgは、ユーザーが行うすべてのログオン試行について（権限を持っています）認識します。または、スクリプトを自分でホストし（自己完結型であると想定）、セキュリティの欠陥が見つかった場合はアップグレードする必要があります。
スタック交換では BrowserIdとWebID の詳細な比較も行われます。そこで議論されたように、BrowserIdは WebID （W3CのW3C Incubator Group）に非常に近いです。ここでは、通常両方のプロトコルを保護するために必要ないくつかのポイントを示します。これらのポイントは、公開鍵暗号化が通常行われる方法とは非常に異なるためです。
- キーの不正なスクリプト使用。これは、BrowserIDの担当者が非常に慎重に実装する必要があることに同意します。 WebIDは13年間使用されている組み込みのブラウザー証明書に依存しているため、その一部はずっと前に処理されたと思います:-)
- 必要な場合リッチクライアントサポート、WebIDを使用します。 TLSレイヤーが必要なだけです-サーバー側で少し調整しました。すべてのオペレーティングシステムとすべてのプログラミング言語にTLSが組み込まれています。
- 複数のコンピューターからの使用：BrowserIDとWebIDの両方で、各コンピューターに1つずつ、任意の数の証明書を持つことができます。これは問題ありません。 WebIDについては、このビデオを参照してください WebIDの作成と4分での使用
クライアントでの秘密キーの暗号化：すべての最近のコンピューターには、パスワードとキーを保存し、パスワードで保護されたキーチェーンが付属しています。
ここで、セキュリティを改善するためにOSベンダーが取り組むことができることがたくさんあります。 OSXで私は特別なパスワードを求められ、さまざまなツールにキーチェーンへのアクセスを多かれ少なかれ簡単に与えることができます。もちろん、キーチェーンは決して秘密鍵を渡すべきではありません。もちろん、公開鍵の配布はまったく問題ありません:-)
もちろん、デスクトップの場合はさらに進んで、ビデオに示すように暗号キーを使用できます Cryptokeys、WebIDおよびInternet Cafes -ただし、UIを多少改善するためにブラウザーベンダーが必要になります。ここには、秘密鍵がコピーされていないことを保証するハードウェアトークンがあります。とにかく、BrowserIDの場合、これをキーチェーンに統合するか、キーチェーンに保存されているx509証明書をワイヤ経由で送信するJavaScriptの方法を見つける必要があります。
- キー生成リクエストの認証：電子メールの使用は実用的ですが、本質的に安全ではありません。それでも人々はそれを使用しており、BrowserIDの利点は、TLSにアップグレードする必要なく、これで動作することです。 WebIDはすべてTLSに対応しているため、そのまま商用レベルのセキュリティを利用できます。
- プライバシー：私自身はJavaScriptがあまり得意ではなく、学ぶべきことのリストに載せています-Scalaを今すぐ楽しんでください。とにかく、私はこのJavaScriptの問題についてBrowserIdでコメントすることはできませんが、よりよく理解したいと思います。現在、WebIDにはJavaScriptが含まれていないため、同じポリシーに対処する必要はありません。上記のビデオで示されているように、IDの選択はブラウザで直接行われます。
ああ、神様！このコメントを投稿するには、ここでもう一度アカウントを作成する必要があります。 FacebookがBlogosphereを破壊したのも不思議ではありません。そこで必要なのは1つのパスワードだけであり、必要なものすべてにコメントできます。
採択された回答の6点への回答を新規回答として提出しています...
1.秘密鍵の不正使用
Javascript BrowserID実装の場合、秘密鍵は、login.persona.orgドメインの下の local storage に格納されます。したがって、不正なスクリプトにアクセスするには、そのドメインで不正なスクリプトをホストする必要があります。他の場所でホストされているスクリプトは、制限された PostMessage -based APIを介して間接的にのみキーにアクセスできます。
2.リッチクライアントサポート（Outlook、Notesなど）
BrowserIDは、任意のメールアカウントまたはメールクライアントで機能します。 JavaScriptシムは、ネイティブ実装なしでbrowsersをサポートするためのものです。メールクライアントに何も追加する必要はありません。
3.複数のコンピューターから使用する
ここで指摘する重要なことは、キーの寿命が短いことです。インターネットキオスクを使用している場合、キーは1時間のみ有効です。自分のデバイスを使用している場合、キーは1日間有効です。 login.persona.orgでまだ認証されている場合は、有効期限が切れると、必要に応じて新しいものが生成されます。バックアップの必要はありません。
秘密鍵を消去したい場合は、Cookieを消去するだけです（これにより、ローカルストレージも消去されます-キーが保存されている場所）。
コンピュータが盗まれた場合、攻撃者が鍵を使用できる小さなウィンドウが存在しますが、login.persona.orgでパスワードを変更する限り、login.persona.orgは無効になり、泥棒は侵入しません新しいキーを取得できる。
4.秘密鍵の保護または暗号化（クライアント上）
IDプロバイダーによって署名された新しいキーを取得するには、そのキーで認証される必要があります。認証の有効期限が切れた場合は、もう一度パスワードを入力する必要があります。これは、Webの標準であると思われるCookieベースのセッションに似ています。
プライベートキーは有効期間が短いため、それほど価値がありません。その点で、X.509クライアント証明書よりもCookieの方が共通しています。
5.キー生成リクエストの認証
IDプロバイダーは、ユーザーが認証されているため、リクエストが正当であることを認識しています。フォールバックIDプロバイダーは、電子メールアドレスの所有権を確認した後でのみ鍵に署名します（標準では、「クリックするランダムトークンを使用してリンクをユーザーに送信します」）。
証明書の生成/署名は、JavaScript APIを介してブラウザーとIDプロバイダーの間で行われます。メールの送信に基づいていないため、ユーザーは、フォールバックIDプロバイダーがアカウントの作成時に送信する「メールアドレスを確認してください」というメッセージ以外のメールを受信しません。
6.プライバシー
APIが十分に安定すると、他のユーザーがinclude.jsを自分でホストできるようになります。現時点では、これをお勧めしません。
Persona.orgがログインしたサイトを確認できるもう1つのポイントは、https://verifier.login.persona.org/verifyのオンライン検証ツールです。データ形式が決まったら、アサーション自体を確認することをお勧めします（たとえば、オープンソースライブラリを使用）。persona.orgはこのデータを取得しなくなります。
BrowserIDは、完全に分散されたプロトコルとして設計され、真のプライバシーを実現します。ただし、ネイティブサポートの現在の不足を回避するための一元化されたフォールバックも提供します。
代替手段のsomeと比較した現在の形式のBrowserIDの欠点の1つは、コア機能を超えるものは何も難しいことです。 OpenID URLはリンクを提供できます。たとえば、BrowserIDから表示名やプロフィール写真を取得するのは困難です（ただし、BrowserIDからメールアドレスが提供されるため、Gravatarから取得できます）。
リストに追加するもう1つの競合プロトコル：WebID： http://webid.info/
BrowserId/Personaの詳細については、- Daniel が BrowserId/PersonaとWebID の関連するQ＆Aに貢献していることがわかりました。 （私は彼にここに投稿するよう説得しようとしましたが、彼はそうするように提案しました。）
フェデレーションIDのセキュリティ、プライバシー、およびユーザビリティの要件 Michael HackettとKirstie HawkeyによるWebIDとMozilla Personaの比較を提供します。当時はまだBrowserIDと呼ばれていました。
表1に記載されている主な違いは次のとおりです。
- ペルソナキーは有効期間が短いため、パスワードで保護する必要があります。 WebIDキーは長期間有効ですが、パスワードで保護されたプロファイルから簡単に無効にすることができます。
- 現在のPersonaの実装は標準のブラウザーウィンドウを使用しているため、なりすましを見つけるのは困難です（ブラウザーがネイティブのPersonaサポートを取得すると変更される可能性があります）。 WebIDはブラウザのネイティブ証明書選択UIを使用しているため、フィッシングの可能性はありません。
- 所有者の電子メール/ URIに対する制御が失われると、ペルソナとWebIDの両方のIDが危険にさらされる可能性があります。
- ペルソナIdPは、IDを使用するSPを認識していません。 WebID IdPは、IDを使用するすべてのSPを知っています。
- ペルソナSPにIdPの公開キーのキャッシュがあり、ブラウザーに有効な証明書がまだある場合でも、IDを確認することができます。WebIDプロファイルにアクセスできる必要があります。そうでない場合、IDは使用できません。
- ペルソナは優れたUXデザインを備えていますが、WebIDはその逆です。
詳細については、論文を読むことをお勧めします。オンラインで無料で利用でき、デジタルライブラリへのアクセスは必要ありません。