セキュリティの観点から、OAuth、OpenID、Facebook Connectなどは狂っていませんか？
私は常にAPIを使用しており、OAuthやOpenIDなどは自家製方法よりもはるかに優れていると主張するWeb開発者と協力しています。ユーザーにとって使いやすいだけでなく、セキュリティのためにも、すべてのサイトがこれらを使用しているようです。私はそれがより安全であると毎日聞いていますが、いくつかの理由で信じるのは非常に難しいと思います：
ハッカーが何らかの方法で1つのサイトにパスワードを取得した場合、ハッカーが現在アクセスしているサイトの大部分にアクセスできることがわかります。
フィッシングが10倍簡単になります。非常に多くの人々が同じログインを使用してそれを繰り返しているため、人々は実際にすべてを読んでURLをチェックする可能性が低くなっています。
安全ではない理由をもう少し挙げていただけますか、それとも安全である理由を説明していただけますか？ユーザーがサービスのロゴをクリックしてログインするのではなく、3つのフィールド（ユーザー名、パスワード、電子メール）にログインするのではなく、TwitterやGoogleなどの3つのフィールドを統合するのに苦労する理由がわかりません。 FBなど）、ユーザー名/パスワードを入力し、[送信]をクリックし、[承認]をクリックします。
==更新==
リクエストごとに私の質問を拡張します。
上記の2つの点について、＃1は、ハッカーがどのように取得するかは関係ありません。正確にそれを拡張する方法がわかりません。あなたはそれを総当たりしたり、推測したり、忘れたパスワードを使用したり、一般的な質問に対して辞書攻撃を行ったりすることができます。しかし、あなたがそれをやったとしても、1000サーバーにアクセスするための1つのパスワードは遠いです1000個の異なるサイトにアクセスするには、1000個のパスワードよりも安全性が低くなります。私は個人的に私の友人や家族のパスワードのいくつかを推測でき、病気はあらゆる種類のアカウントにアクセスできます。私はそれらを探す必要すらありませんでした。ログインしているだけでウェブを閲覧できます...私がハッカーだった場合、これらのパスワードの多くは非常に簡単に解読できます。私の友人のパスワードには、pepsi、tina（誕生年）、123456、その他の愚かなパスワードがあります。でも私のお気に入りはtomcruisesucks LOLです。
＃2ポイントの場合、さらに拡張するには、 http://wired.com 、 http://klout.com 、 http://Twitter.com 、 http://thenextweb.com そして、それらはすべてTwitterログインを持っています。私は（ほとんどの場合）サイトを信頼しているので、正直なところ、ログインするために表示されるポップアップウィンドウのURLを確認していません。そのポップアップウィンドウは、サーバーまたは悪意のある従業員のいずれかに乗っているハッカー、またはボットがTwitterを介して複数の人がこの偽のアプリにログインする人に送信している偽のアプリサイトだけで簡単にハッキングされた可能性がありますが、 Twitterログイン。
人々はもう見ない同じログインページを見るのに慣れています。このスレッドが十分に人気が出たら、偽のアプリへのリンクを全員に送信することで、TwitterまたはFBで非常に簡単なテストを簡単に行うことができます。保証します。ログイン画面を表示する場合は、たとえば http://bankofamerica.com または http://Paypal.com と言います。なぜここにいるのか、 、なぜこの情報が必要なのか、など。何度も何度もログインするのに使用したのと同じサイトは、実際には非常に悪い。
それは私の拡張された議論のポイントです;）
日常のWebサイトには本当に良い解決策はないと思います（たとえば、ユーザーが受け入れる銀行のような注目度の高いサイトではなく、経済的に2要素認証が許可されています）。可能な限り悪影響が少ないソリューションしか選択できません。
残念ながら人々は膨大な数のパスワードを覚えるのが苦手です。その結果、異なるサービスで同じパスワードを再利用するか、紙に書き留めるかパスワードマネージャに書き留めます。はい、サイト名を含むパスワードシステムを作成することをお勧めします。
しかし、人々は怠惰です。パスワードの再利用は、すべてのアプリケーションの脆弱性がパスワードを明らかにすることを意味するため、中央アカウントよりも悪いです。
Stendhal ゲームでは、アカウントのハッキングのほとんどは家族が行っています。それはゲームにとって特別なことだと思います。次のグループは、ユーザー名/パスワードのランダムな推測です。しかし、メールアカウントへのアクセスを取得することに基づくハッキングの試みがいくつかあります。電子メールを使用した自動パスワードリセットは許可されていませんが、多くのウェブサイトでは許可されています。 Twitterの上級管理職がハッキングされた 有効期限が切れたHotmailメールアカウントとパスワードの再利用。
したがって、電子メールを介してパスワードのリセットを許可することを検討する場合、認証プロセスを大企業に委任することによる追加のリスクはほとんどありません。それらのすべては、攻撃者にとってより困難にするための対策を講じています（不審なアクティビティ、ログイン履歴、ログインに関する警告の場合の携帯電話メッセージによる回復他の郡からの試みなど）。これらを自分のサイトに実装するのは大変な作業です。
個人的には、これらの会社の1つを信頼するよりも、 アカウントマネージャー アプローチ（ 仕様 ）を優先した方がいいでしょう。さらに、フィッシングの問題もありません。残念ながら、プロジェクトは進展していないようです。
最終的に、StendhalがOpenIDとローカルアカウントの両方をサポートし、ユーザーに決定させることにしました。
セキュリティの観点からすると、ほとんどの場合、メカニズムを試してテストすることは、独自のメカニズムを導入するよりも優れています。実装エラーは、優れたセキュリティ概念が破られる最も一般的な方法の1つです。
使いやすさの観点から、私はoauthをわずかに好みます。それは使いやすいだけなので、エンドユーザーにとっては大きなメリットです。技術者でない平均的なユーザーは、明白なセキュリティに気を取られているため、セキュリティ機能の侵入を最小限に抑えることは、多数のユーザーがいるサイトにとっては有利です。
フィッシングリスクはそれほど大きくはありません-とにかくメールの送信元に注意を払う必要はありません:-)
OAuthのようなシステムの利点は次のとおりです。
- ユーザーのログイン資格情報を保存するデータベースは世界中に少なくなっています。 Twitterのようなサービスを考えると、これは、ユーザー名とパスワードがTwitterだけに知られ、Amazon、LinkedIn、ニューヨークタイムズ、およびサービス上に構築された他のすべてのアプリケーションには知られていないことを意味します。
- @Roryが言うように、システムは広く使用されており、テストされて（うまくいけば）適切な範囲で保護されています。
これらの利点はどちらもあなたのポイント1に対処します：OK、これらのサービスはすべて同じパスワードを使用しますが、いずれもTwitterアカウントを使用する必要があるため、とにかく使用する必要があります。さまざまな保護対策を備えたさまざまな場所で。
基本的な欠点は、すべてのログインUIに影響する欠点と同じです。誰もがそのような外観のログインUIを作成し、それを使用して資格情報を取得できます。
特定のシナリオと脅威モデルがなければ、質問に答えることは困難です。
しかし、1つの明らかな勝利は、古典的な OAuthユースケース です。ユーザーは、あるWebサイトに別のWebサイトのパスワードを提供することに驚くほど意欲的であることがわかりました。 ShelfariなどのソーシャルネットワーキングサイトへのGoogleパスワード。そして、カルシーが指摘するように、彼らはシェルファリがそのパスワードで何をしたかをひどく驚いたことがあり、シェルファリが完全に偽装できるため、Googleが悪用を簡単に止めることができませんでした。
現在、OAuthを使用すると、ShelfariのようなアプリはAPI経由でユーザーの連絡先データベースに部分的にしかアクセスできず、ShelfariはGoogleが簡単に取り消すことができるAPIキーを使用します。
現実の世界では、ユーザーは複数のサイトでパスワードを再利用する可能性が非常に高いため、＃1の攻撃は、多くの場所でそのまま機能する可能性があります。実際、ユーザーが重要なOpenIDサイトにもっと良いパスワードを使用したり、2要素認証を使用したりすることを期待できます。
＃2については、OpenIDログインのポイントは、他のWebサイトにログインしていることに気付いたときに、ログインしていないと思われるサイトで実行されることが珍しいことです。一方、OpenIDやOAuthを使わずにサイトをTwitterのように見せ、そのサイトにリンクして、ユーザーにログインしてパスワードを取得するように説得することは、すでに簡単です。人々が常にTwitterにログインしている場合（たとえば、OAuthまたはOpenIDを介して他のサイトの場合）、彼らはまだログインしていない理由を尋ねる可能性があります。
書いた this 連携IDについて。
基本的には、集中化されたリスクの問題または王国への鍵について話している。これは password managers にも当てはまりますが、少数のIDおよび認証システムのセキュリティ保護は、何百もの弱いパスワード（または同じ弱いパスワードを100回）にするよりもはるかに簡単で効果的です。 GoogleのようなOpen-IDプロバイダーは2要素認証を提供しています。電話のソフトトークンが気に入らない場合は、Yubikey USBハードウェアトークンも多くのOpen-IDプロバイダーでサポートされています。制御と監査も大幅に改善されました。パスワードを使用したすべてのアプリケーションを知っていますか？私もダメ。しかし、多くのOpen-IDプロバイダーには、そのIDへのアクセスを許可したすべてのサイトがあり、アクセスの取り消しはワンクリックプロセスです。
Facebookのようなものを使用するビジネスの観点からoAuthは、すべてのソーシャルデータへのアクセス、分析、口コミ化の可能性の増加を提供します。認証を開発するためにプログラマーに支払うよりも速くて安価であることを追加してください何らかの形のフェデレーテッド認証を使用した機能は、私にとっては簡単なことのようです。
OpenIDアカウントにGoogleを使用しています。 OpenIDを使用していないほとんどすべてのWebサイトで、電子メールを介してパスワードをリセットできます。そのため、誰かが私のGmailアカウントのパスワードを入手した場合、とにかく失敗します。
1 password stored in 1000 serversを使用すると、1 password stored in 1 server which authenticates 999 serversよりも安全性が低くなり、1000 password for 1000 serversよりも安全性が低くなります。
ただし、後者は実用的ではなく、人々は1000台のサーバーの1000個のパスワードを記憶することができません。パスワードマネージャーを使用することが唯一の方法です。そして、パスワードマネージャーはどこに立っていますか？
1 password stored using 1-way encryption in 1000 serversは1 master password for a password manager which stores 1000 passwords in cleartext or 2-way encryption for 1000 serversより安全性が低く、1 password stored in 1-way encryption in 1 server which authenticates 999 serversは1000 password stored using 1-way encryption in 1000 serversより安全性が低くなります。
したがって、OAuth/OpenIDはより安全で便利で実用的です。パスワードマネージャーなしで1000個のパスワードを使用することは非現実的であり、それらのパスワードはプレーンテキストで保存するか双方向暗号化を使用する必要があるため、パスワードマネージャーの使用は安全性が低くなります。
1つの方法OAuthおよびOpenIDは、セキュリティを向上させることで、パスワードを入力する必要が少なくなります。新しいアカウントをOAuth/OpenIDにリンクすることは、私がIDプロバイダーにリダイレクトされるだけです。 IDプロバイダーには常にログインしています。パスワードプロンプトの代わりに、はい/いいえのプロンプトが表示されるだけです。このやり取り全体でパスワードが移動することはありません。
これにより、単に通過するのではなく、実際にパスワードの入力を求められた場合に、より自覚することができます。
したがって、＃2は実際には問題ではありません。
＃2は完全に真実ですが、主に連邦IDの問題ではなく、この場合はさらに重要です。
（実際に）信頼できないコンテンツに埋め込まれたallログインフォームでも同様の問題が発生します。特に、使用されている認証が最も安全でないためです（シークレットは単にブラウザ、そして運が良ければサーバーはあなたの便宜のためにSSLを下に置きます。
これと他のほとんどのフィッシング攻撃を修正するには、次の2つが必要です。
ユーザー認証のための安全なインターフェース、例えばサーバーコンテンツの一部ではなく、URLバーからのドロップダウンダイアログ。
悪意のある可能性のあるサーバー（SRPなど）に秘密を公開しない、ネイティブに実装された認証プロトコル（JavaScriptなどのサーバーコンテンツではない）
ところで、私は数年前にNSSにSRPを実装し、他のユーザーはGUI拡張機能も実装しました。スマートカードがユビキタスにならない限り、これは行く方法です： http://trustedhttp.org/wiki/TLS-SRP_in_NSS
人間は常に責任を肩から譲りたいと願っています（全員ではありません）。セキュリティは大きな責任であり、ほとんどの企業は、コアビジネスに集中し、セキュリティについて心配するのではなく、製品を顧客に提供したいと考えています。
単一障害点は間違いなくセキュリティの観点から心配する必要がありますが、巨額の資金を手に入れ、優れたセキュリティエンジニアがいるため、人々は大企業を信頼したいと考えています（厳密にはそうではありません！）。優れたエンジニアは、優れたセキュリティ慣行を意味します。さらに、彼らは人々に彼らの背中を見せません（うまくいけば！）。
フィッシングは間違いなく大きな問題であり、セキュリティコミュニティはかなり長い間この問題に取り組んできました。 @Rakkhiが述べたように、フィッシング問題を解決するYubikey、Fido U2Fなどの最近のソリューションは、セキュリティを強化するのに役立つ可能性があります。
私たちが期待できる唯一のことは、ユーザーがパスワードを選択して入力する必要がなく、パスワードを安全に認証できる新しいデザインのシフトです。