The Security of OpenID Authentication 2.0
- 1. WAS Forum Developers Day 2008 The Security of OpenIDThe Security of OpenID Authentication 2.0Authentication 2.0 Toru YamaguchiToru Yamaguchi id:ZIGOROuid:ZIGOROu <<zigorou@cpan.orgzigorou@cpan.org>>
- 2. AboutAbout -- 自己紹介自己紹介 名前名前 山口山口 徹徹 (31)(31) 所属所属 サイボウズ?ラボ株式会社サイボウズ?ラボ株式会社 ブログブログ http://http://d.hatena.ne.jp/ZIGOROud.hatena.ne.jp/ZIGOROu// その他その他 http://http://search.cpan.org/~zigorousearch.cpan.org/~zigorou/ (CPAN)/ (CPAN) http://http://blogbattler.comblogbattler.com// ((個人活動、有志個人活動、有志))
- 3. AgendaAgenda -- 今日話すこと今日話すこと OpenID Authentication ProtocolOpenID Authentication Protocol OverviewOverview Security of OpenIDSecurity of OpenID
- 4. OpenIDOpenID Authentication ProtocolAuthentication Protocol TerminTerminologyology InitiaInitiation & Discoverytion & Discovery Authentication form for OpenIDAuthentication form for OpenID The threeThe three discorverydiscorvery Communication TypeCommunication Type DirectDirect CommunicationCommunication Indirect CommunicationIndirect Communication ProtocolProtocol MessagesMessages associateassociate checkid_setupcheckid_setup,, checkid_immediatecheckid_immediate check_authenticationcheck_authentication VerificationVerification assertionassertion
- 5. Terminology (1)Terminology (1) -- 用語用語 (1)(1) IdentifierIdentifier URIURI またはまたは XRIXRI Claimed IdentifierClaimed Identifier これから認証されるこれから認証される IdentifierIdentifier UserUser--AgentAgent BrowserBrowser OpenIDOpenID Provider (OP)Provider (OP) 認証サーバー認証サーバー OPOP Endpoint URLEndpoint URL 認証プロトコルメッセージの送信先認証プロトコルメッセージの送信先URLURL
- 6. TerminologyTerminology (2)(2) -- 用語用語 (2)(2) RRelying Party (RP)elying Party (RP) 実際に実際に OpenIDOpenID 認証を利用するウェブサービス認証を利用するウェブサービス OPOP IdentifierIdentifier OPOP を識別するを識別する Identifier (Identifier (つまりつまり URI or XRI)URI or XRI) UserUser--Supplied IdentifierSupplied Identifier Claimed IdentifierClaimed Identifier またはまたは OP IdentifierOP Identifier 実際にユーザから提供されうる実際にユーザから提供されうる IdentifierIdentifier の総称の総称 OP Local IdentifierOP Local Identifier OPOP上でのユーザの上でのユーザのIdentifierIdentifierで、独自のドメインをで、独自のドメインをIdentifierIdentifierとすとす る場合と特に区別して呼ぶ。またる場合と特に区別して呼ぶ。またdelegate (delegate (別の別のIdentifierIdentifierの認証の認証 に委譲することに委譲すること)) の際に最終的に依存するの際に最終的に依存するIdentifierIdentifierでもある。でもある。
- 7. Protocol Overview (1)Protocol Overview (1) -- 概要概要 (1(1)) Initiation & DiscoveryInitiation & Discovery RPRP はユーザに認証フォームを提供はユーザに認証フォームを提供 ユーザは認証フォームにユーザは認証フォームに UserUser--SuppliedSupplied IdentifierIdentifier を入力するを入力する RPRP はは discoverydiscovery を実行してを実行して UserUser--SuppliedSupplied IdentifierIdentifier を認証する為のを認証する為の OPOP のの OP EndpointOP Endpoint URLURL ((と必要な場合と必要な場合 OP Local Identifier)OP Local Identifier) を見を見 つける。つける。
- 8. ProtocolProtocol Overview (2)Overview (2) -- 概要概要 (2)(2) Protocol MessagesProtocol Messages associateassociate 認証メッセージの署名用に使う共有シークレットを認証メッセージの署名用に使う共有シークレットを RPRP--OPOP間で交換する間で交換する checkid_setupcheckid_setup,, checkid_immediatecheckid_immediate 実際に認証を行う為の認証リクエストを実行実際に認証を行う為の認証リクエストを実行 VerificationVerification checkidcheckid_*_* の結果が妥当であるかどうかを検の結果が妥当であるかどうかを検 証する証する
- 9. InitiationInitiation -- 初期化初期化 認証のまず始めは認証のまず始めは RPRP がユーザに対して認がユーザに対して認 証フォームを提供します。証フォームを提供します。 http://http://openiddirectory.comopeniddirectory.com// http://http://pibb.compibb.com//
- 10. DiscoveryDiscovery UserUser--Supplied IdentifierSupplied Identifier をを RPRPが受け取るが受け取る RPRP はは discoverydiscovery を実行しますを実行します discoverydiscovery とは、そのとは、その IdentifierIdentifier を認証する為を認証する為 のの OPOP Endpoint URLEndpoint URL を探すこと。を探すこと。 delegatedelegate の場合はの場合は OPOP--Local IdentifierLocal Identifier もも discoverydiscovery で探しますで探します
- 11. The three discoveriesThe three discoveries -- 三つのディスカバリ三つのディスカバリ IdentifierIdentifier がが XRIXRI の場合はの場合は XRIXRI ResolutionResolution でで discoverydiscovery するする 結果は結果は XRDSXRDS と言う形式のと言う形式の XMLXML 文書文書 IdentifierIdentifier がが URIURI の場合の場合 最初は最初は YadisYadis Protocol (XRDSProtocol (XRDS--Simple)Simple) でで discoverydiscovery を試みるを試みる 成功したら成功したら XRDSXRDS 文書が返って来る文書が返って来る YadisYadis でダメならでダメなら HTMLHTML 内の内の linklink 要素から取要素から取 得する得する
- 12. XRDS formatXRDS format -- XRDSXRDS 形式形式 <?<?xml versionxml version=="1.0""1.0" encodingencoding=="UTF"UTF--8"8"?>?> <<xrdsxrds::XRDSXRDS xmlnsxmlns::xrdsxrds==""xri://$xrdsxri://$xrds xmlns:openidxmlns:openid="="http://http://openidopenid..netnet//xmlnsxmlns/1.0/1.0 xmlnsxmlns==""xri://$xrdxri://$xrd*($v*2.0)"*($v*2.0)">> <XRD><XRD> <Service<Service prioritypriority=="0""0">> <Type><Type>http://specs.openid.net/auth/2.0/signonhttp://specs.openid.net/auth/2.0/signon</Type></Type> <URI><URI>http://http://example.comexample.com/server/server</URI></URI> <<LocalIDLocalID>>http://http://zigorou.example.comzigorou.example.com//</</LocalIDLocalID>> </Service></Service> <Service<Service prioritypriority=="1""1">> <Type><Type>http://openid.net/signon/1.1http://openid.net/signon/1.1</Type></Type> <URI><URI>http://http://example.comexample.com/server/server</URI></URI> <<openidopenid::DelegateDelegate>>http://http://zigorou.example.comzigorou.example.com//</</openidopenid::DelegateDelegate>> </Service></Service> </XRD></XRD> </</xrdsxrds::XRDSXRDS>>
- 13. YadisYadis discoverydiscovery Yadis IDへ GET or HEAD Yadis IDへ GET or HEAD X-XRDS- Locationをmeta 要素で持つ X-XRDS- Locationをmeta 要素で持つ X-XRDS-Location をレスポンスヘッ ダで持つ X-XRDS-Location をレスポンスヘッ ダで持つ X-XRDS-Location ヘッダを含む Or / And Content-Typeが application/xrds+xml X-XRDS-Location ヘッダを含む Or / And Content-Typeが application/xrds+xml 文書のmimetypeが application/xrds+xml 文書のmimetypeが application/xrds+xml Yadis Document (XRDS document) Yadis Document (XRDS document) Resource Descriptor URL にGET Resource Descriptor URL にGET XX--XRDSXRDS--LocationLocationヘッダがあるヘッダがある XX--XRDSXRDS--LocationLocationヘッダがないヘッダがない HEADHEADの場合での場合でmetameta要素にあり、他が該当しな要素にあり、他が該当しな い場合は改めてい場合は改めてGETGETを行うを行う
- 14. HTML based discoveryHTML based discovery headhead 要素内に所定のフォーマットで要素内に所定のフォーマットで OPOP Endpoint URL, OP Local IdentifierEndpoint URL, OP Local Identifier を指定を指定 しておくしておく <head> <link rel="openid2.provider openid.server" href="http://openid.example.com/server" /> <link rel="openid2.local_id openid.delegate" href="http://zigorou.example.com/" /> </head>
- 15. DDirectirect CommunicationCommunication -- 直接通信直接通信 RPRP OOPP 1. OP1. OP EndpointEndpoint URLURL へリクエストへリクエスト 2.2. プロトコルのモードに応じた処理プロトコルのモードに応じた処理 3.3. レスポンスレスポンス
- 16. IndirectIndirect CommunicationCommunication -- 間接通信間接通信 ユーザユーザ RPRP OOPP 1. OP1. OP EndpointEndpoint URLURL へのリダイレクト要求へのリダイレクト要求 2. OP Endpoint URL2. OP Endpoint URL へリダイレクトへリダイレクト 3.3. プロトコルのモードに応じた処理プロトコルのモードに応じた処理 4. RP4. RP のの openid.return_toopenid.return_to へリダイレクト要求へリダイレクト要求 5. RP5. RP のの openid.return_urlopenid.return_url へリダイレクトへリダイレクト
- 17. Message FormatMessage Format application/xapplication/x--wwwwww--urlencodedurlencoded 形式形式 つまりつまり keykey -- valuevalue 形式形式 OpenID ProtocolOpenID Protocol のメッセージは全て接頭のメッセージは全て接頭 辞に辞に openidopenid.. をつけるをつける openid.modeopenid.mode,, openid.nsopenid.ns,, openid.assoc_typeopenid.assoc_type,, openid.session_typeopenid.session_type
- 18. associate mode (1)associate mode (1) RP, OPRP, OP との間で共有シークレットを交換する。プロトコとの間で共有シークレットを交換する。プロトコ ルメッセージの署名ルメッセージの署名(MAC(MACキーキー))に用いられるに用いられる Communication typeCommunication type はは Direct CommunicationDirect Communication associationassociation がが OPOP--RPRP 間で確立している場合は、認証結間で確立している場合は、認証結 果の妥当性検証に余計な通信を挟む必要が無い。果の妥当性検証に余計な通信を挟む必要が無い。((StatefulStateful mode)mode) associationassociation が確立していなかったり、が確立していなかったり、RPRPががassoc_handleassoc_handleを保存を保存 出来ない場合は、出来ない場合は、check_authenticationcheck_authentication モードで認証結果の検証モードで認証結果の検証 を行うを行う (Stateless mode)(Stateless mode)
- 19. associate mode (2)associate mode (2) 署名アルゴリズム署名アルゴリズム HMACHMAC--SHA1 (OpenID 1.1SHA1 (OpenID 1.1 の名残の名残)) HMACHMAC--SHA256 (RECOMENDED)SHA256 (RECOMENDED) セッション型セッション型 NoNo--EncryptionEncryption OPOP から返されるから返されるMACMACキーは平文キーは平文 TLS/SSLTLS/SSL を使ってない通信路では絶対に使用しないを使ってない通信路では絶対に使用しない DiffieDiffie--HellmanHellman 鍵共有鍵共有 DHDH--SHA1SHA1 またはまたは DHDH--SHA256SHA256 で共有シークレットを交換で共有シークレットを交換
- 20. checkid_setupcheckid_setup,, checkid_immediatecheckid_immediate modemode 認証リクエストを行うモード認証リクエストを行うモード Indirect CommunicationIndirect Communication openid.return_toopenid.return_to,, openid.realmopenid.realm return_toreturn_to はは 認証応答を受け取る認証応答を受け取る RPRP 上の上の URLURL で、で、realmrealm はは return_toreturn_to で指定されたで指定された URLURL の検証の為に用いられるの検証の為に用いられる URLURL パターンを指定するパターンを指定する checkid_setupcheckid_setup 認証時に画面遷移を含む方式認証時に画面遷移を含む方式 checkid_immediatecheckid_immediate JavaScriptJavaScriptの非同期通信の非同期通信 ((iframeiframe)) を用いて認証を用いて認証 そのそのRPRPに対して恒久的に認証結果を返すようにしているに対して恒久的に認証結果を返すようにしている そのそのOPOPに対するログインセッションが残っているに対するログインセッションが残っている 上記の条件が揃っていれば、認証結果が即座に返って来るが、そうでない上記の条件が揃っていれば、認証結果が即座に返って来るが、そうでない 場合は場合は checkid_setupcheckid_setup に切り替えるに切り替える
- 21. Verification assertionVerification assertion -- アサーションの検証アサーションの検証 認証結果を認証結果をRPRPが受け入れる前の検証が受け入れる前の検証 openid.return_toopenid.return_to と現在と現在RPRPにリクエストされにリクエストされ たたURLURLを検証を検証 RPRP がディスカバリした結果とアサーションのがディスカバリした結果とアサーションの 結果との比較検証結果との比較検証 nonce (nonce (openid.response_nonceopenid.response_nonce)) の検証の検証 アサーションの署名の検証アサーションの署名の検証
- 22. OpenIDOpenID に対するセキュリティの話の前にに対するセキュリティの話の前に 以上でプロトコルの簡単な解説は終わり以上でプロトコルの簡単な解説は終わり 今回はプロトコル解説ではなくセキュリティに関する話なので今回はプロトコル解説ではなくセキュリティに関する話なので?? 必要な場合はプロトコルの説明もさらにします必要な場合はプロトコルの説明もさらにします OpenIDOpenID のセキュリティに対する考え方のセキュリティに対する考え方 ProtocolProtocol 上でセキュリティに対してどういう配慮がされているか上でセキュリティに対してどういう配慮がされているか 現実的に考えうるセキュリティ上の脅威に対してどのような対策現実的に考えうるセキュリティ上の脅威に対してどのような対策 を採るべきかを採るべきか と言う二つの視点で考えて行きます。と言う二つの視点で考えて行きます。 ちなみにほとんどのトピックは盗聴やら中間者攻撃です＾＾ちなみにほとんどのトピックは盗聴やら中間者攻撃です＾＾
- 23. 盗聴と中間者攻撃盗聴と中間者攻撃 盗聴に対する対策盗聴に対する対策 TLS/SSLTLS/SSL を使いましょう。使えない場合はを使いましょう。使えない場合は noncenonce のチェックにのチェックに よって防ぐことが出来ます。よって防ぐことが出来ます。 中間者攻撃とメッセージの署名中間者攻撃とメッセージの署名 checkid_setupcheckid_setup,, checkid_immediatecheckid_immediate の際のメッセージのやり取の際のメッセージのやり取 りには署名が用いられるりには署名が用いられる つまりこの部分のやり取りの改ざんは用いるつまりこの部分のやり取りの改ざんは用いるHMACHMACの強度に依存の強度に依存 一方で一方で discoverydiscovery やや associateassociate、、check_authenticationcheck_authentication には署名には署名 が用いられないが用いられない この部分はメッセージのやり取りに中間者攻撃の危険性があるこの部分はメッセージのやり取りに中間者攻撃の危険性がある やはりやはり TLS/SSLTLS/SSL を用いるのが対策の基本を用いるのが対策の基本 まずは何をおいてもまずは何をおいても TLS/SSLTLS/SSL を使う事が重要を使う事が重要
- 24. DiscoveryDiscovery とと SecuritySecurity (1)(1) DiscoveryDiscovery とはとは ((復習復習)) UserUser--Supplied IdentifierSupplied Identifier を認証する為に、どの認証を認証する為に、どの認証 サーバーを用いれば良いかを調べる行為サーバーを用いれば良いかを調べる行為 三つの方法があるが、いずれも外部と三つの方法があるが、いずれも外部とhttpshttps通信する通信する DiscoveryDiscoveryを駆動するのはユーザを駆動するのはユーザ つまりつまり RPRP にディスカバリを強制させる事が出来ると言にディスカバリを強制させる事が出来ると言 うこと。うこと。 これを連発すればこれを連発すれば Denial of Service AttackDenial of Service Attack となるとなる IdentifierIdentifier がが URIURI の場合は、任意のホストにある任意の場合は、任意のホストにある任意 のポートに対してのポートに対して RPRP が接続試行する事になる。が接続試行する事になる。 ポートスキャンのような事が出来てしまいかねないポートスキャンのような事が出来てしまいかねない
- 25. DiscoveryDiscovery とと Security (2)Security (2) 原則として攻撃者に対して有益な情報を与えない原則として攻撃者に対して有益な情報を与えない ディスカバリが出来なかった理由を詳細に伝えない。ディスカバリが出来なかった理由を詳細に伝えない。 エラーメッセージはただ出来なかっただけで良い。エラーメッセージはただ出来なかっただけで良い。 IdentifierIdentifier に対する一定のルールを設けるに対する一定のルールを設ける 例えば例えば XRIXRI かか 80 or 44380 or 443 以外は認めないなど以外は認めないなど プライベートアドレスに帰着する場合も弾くプライベートアドレスに帰着する場合も弾く IPIP ベースの対策ベースの対策 Denial of Service AttackDenial of Service Attack に対して有効な対策に対して有効な対策 特定の閾値を設けてその特定の閾値を設けてそのIPIPからのアクセス自体を禁止からのアクセス自体を禁止 するようにするするようにする
- 26. AssociationAssociation type,type, Association session typeAssociation session type openid.modeopenid.mode=associate=associateの際に行う共有鍵の交換の際のの際に行う共有鍵の交換の際の 話話 署名アルゴリズムの種別である署名アルゴリズムの種別である 二つの二つのAssociation typeAssociation type と、と、macmac キーをどのように受け渡すかと言う方式である三つのキーをどのように受け渡すかと言う方式である三つの AssociationAssociation session typesession type がある。がある。 AssociationAssociation TypeType AssociationAssociation Session TypeSession Type HMAC-SHA1HMAC-SHA1 HMAC-SHA256HMAC-SHA256 no-encryptionno-encryption DH-SHA1DH-SHA1 DH-SHA256DH-SHA256
- 27. DiffieDiffie--HellmanHellman と中間者攻撃と中間者攻撃 (1)(1) DiffieDiffie--HellmanHellman の長所の長所 通信路が安全で無い場合でも安全に共有鍵を交通信路が安全で無い場合でも安全に共有鍵を交 換出来る換出来る DiffieDiffie--HellmanHellman の短所の短所 中間者攻撃に弱い中間者攻撃に弱い どういう事かどういう事か 通信路の安全性には問題は無いがやり取りする通信路の安全性には問題は無いがやり取りする 二者が互いに期待しうる相手かどうかが問題。二者が互いに期待しうる相手かどうかが問題。
- 28. DiffieDiffie--HellmanHellman と中間者攻撃と中間者攻撃 (2)(2) 図式化するとこういう事が考えられる図式化するとこういう事が考えられる 中間者中間者RPRP OOPP 1. OP1. OP だと思い込んで中間だと思い込んで中間 者に者に associateassociate 2. RP2. RP のふりをしてのふりをして OPOP にに associateassociate 33.. 共有鍵共有鍵 ((中間者中間者--OPOP間間)) のの 交換交換 4.4. 共有鍵共有鍵 (RP(RP--中間者間中間者間)) のの 交換交換 最近話題になった最近話題になった ARP SpoofingARP Spoofing やや DNS SpoofingDNS Spoofing が行われていた場合にこが行われていた場合にこ うした危険性があるうした危険性がある
- 29. Association Best PracticeAssociation Best Practice OP Endpoint URLOP Endpoint URL がが httpshttps にに((もも))対応の場合対応の場合 かならずかならず httpshttps を用いる。当然だが野良証明書は信じない。を用いる。当然だが野良証明書は信じない。 AssociatioAssociation session typen session type にに DHDH を用いる意味は無くなるのでを用いる意味は無くなるので nono--encryptionencryption で。で。 残念ながら残念ながら httphttp の場合の場合 DHDH--SHA256SHA256 を採用するを採用する さらに通信相手が期待する相手かどうかチェックすべしさらに通信相手が期待する相手かどうかチェックすべし プライベートアドレスを弾くとか、出来る限りのチェックをするプライベートアドレスを弾くとか、出来る限りのチェックをする discoverydiscovery の段階で見つけたの段階で見つけた OP Endpoint URLOP Endpoint URL を見て、を見て、httpshttps費費 対応の場合には、そうした対応の場合には、そうした OPOP は信用しないと言う対策もありは信用しないと言う対策もあり 共通して言えること共通して言えること AssociationAssociation typetype はは HMACHMAC--SHA256SHA256 で。で。
- 30. Relying PartyRelying Party の詐称の詐称 (1)(1) 端的に言えばフィッシングです端的に言えばフィッシングです http://http://idtheft.fun.deidtheft.fun.de// 実際にデモを作った人が居ます実際にデモを作った人が居ます myopenidmyopenid ではなくではなく idtheft.fun.deidtheft.fun.de に！に！
- 31. Relying PartyRelying Party の詐称の詐称 (2)(2) 対策の方針対策の方針 ブラックリストは未知のフィッシングサイトにブラックリストは未知のフィッシングサイトに 対応出来ない為、愚策である。対応出来ない為、愚策である。 今回の場合、何がおかしいかと言えば、今回の場合、何がおかしいかと言えば、 本来、本来、UserUser--SuppliedSupplied IdentifierIdentifier を入れた場合、を入れた場合、 RPRP はは discoverydiscovery してして OP Endpoint URLOP Endpoint URL にユーザにユーザ を誘導するのが正しいを誘導するのが正しい にも関わらず、偽にも関わらず、偽OPOPの画面が出ているの画面が出ている
- 32. Relying PartyRelying Party の詐称の詐称 (3)(3) ブラウザがブラウザが OpenIDOpenID 認証セッションに関与すれ認証セッションに関与すれ ばいいばいい OpenIDOpenID の認証セッションかどうかを判定するにはの認証セッションかどうかを判定するには RPRP の入力フォームがの入力フォームが openid_urlopenid_url またはまたは openid_identifieropenid_identifier と言うと言う namename 属性を持っている場合属性を持っている場合 に判断するに判断する IdentifierIdentifier を入力してを入力してPOSTPOSTする段階でブラウザがする段階でブラウザが discoverydiscovery する。する。((それまで偽それまで偽RPRPにはにはIdentifierIdentifierを送信を送信 しないしない)) OP Endpoint URLOP Endpoint URL に対してに対して checkidcheckid_*_* リクエストがリクエストが 成されない限り、その成されない限り、その OpenIDOpenID 認証セッションにて認証セッションにて ユーザーが認証情報を通知しないようにすれば良い。ユーザーが認証情報を通知しないようにすれば良い。
- 33. return_toreturn_to とと realm (1)realm (1) return_toreturn_to,, realmrealm とはとは RPRP が実際に認証リクエストをが実際に認証リクエストをOPOPに送るに送る ((checkidcheckid_*_* mode )mode ) 時に、時に、 openid.return_toopenid.return_to で認証アサーション応答を受け取るで認証アサーション応答を受け取るURLURLをを 指定する指定する openid.realmopenid.realm でで return_toreturn_to の含まれるの含まれるURLURLパターンを指定パターンを指定 するする 何のためにあるのか何のためにあるのか リダイレクトはユーザにとって、どこに飛ばされるかが一見分リダイレクトはユーザにとって、どこに飛ばされるかが一見分 からないからない もし悪意のあるもし悪意のある RPRP がおかしながおかしな return_toreturn_to を指定した場合は？を指定した場合は？
- 34. return_toreturn_to とと realm (2)realm (2) OpenID Realm SpoofingOpenID Realm Spoofing リダイレクタを持つ白なリダイレクタを持つ白な RPRP が踏み台にされるが踏み台にされる そのその RPRP のリダイレクタをのリダイレクタを return_toreturn_to に指定に指定 するする リダイレクタのリダイレクト先を悪意のあるリダイレクタのリダイレクト先を悪意のある RPRP のの callbackcallback urlurl とするとする そもそもそもそもOPOPからのリダイレクト直前はユーザからのリダイレクト直前はユーザ にどのように見えるかにどのように見えるか
- 35. return_toreturn_to とと realm (3)realm (3) 国内某国内某 OPOP の例の例 これからどこにリダイレクトされるかまるで分からないこれからどこにリダイレクトされるかまるで分からない 早急に改善して下さい！！！早急に改善して下さい！！！早急に改善して下さい！！！
- 36. return_toreturn_to とと realm (4)realm (4) 国内某国内某 OPOP の例の例 -- その２その２ return_toreturn_to にに googlegoogle のリダイレクタを指定し、のリダイレクタを指定し、 realmrealm にに googlegoogle を指定した場合を指定した場合 実際の実際の RPRP は別のドメインは別のドメイン ドメイン部分しか表示されていないドメイン部分しか表示されていない
- 37. return_toreturn_to とと realm (5)realm (5) Realm SpoofingRealm Spoofing の図式の図式 RPRP OOPP ユーザユーザ リダイレクタリダイレクタ 1. RP1. RPへのへのURLURLを指定したリダイレクタへのリダイレクト要求を指定したリダイレクタへのリダイレクト要求 2.2. リダイレクタへリダイレクトリダイレクタへリダイレクト 3.3. 認証レスポンスも含めて認証レスポンスも含めて RPRP へリダイレクト要求へリダイレクト要求 4. RP4. RP へリダイレクトへリダイレクト
- 38. return_toreturn_to とと realm (6)realm (6) 何が問題なのか何が問題なのか 悪い例にあるとおり、これからリダイレクト先を明示しない悪い例にあるとおり、これからリダイレクト先を明示しない OPOP があったりがあったり ユーザはこれからどこに飛ばされるかまったく分からないユーザはこれからどこに飛ばされるかまったく分からない あるいはあるいは return_toreturn_to で示されるで示される URLURL のの authorityauthority 部しか表示し部しか表示し ないない OPOP もあるもある 一見、一見、GoogleGoogle に対して認証結果を返すかのように錯覚に対して認証結果を返すかのように錯覚 下手すると下手すると GoogleGoogle がそのユーザにとって既知のがそのユーザにとって既知の RPRP だとしたら実装だとしたら実装 如何では、如何では、GoogleGoogle に対するポリシーが適用されかねないに対するポリシーが適用されかねない 最悪のケース最悪のケース 白な白な RPRP に対する認証ポリシーでに対する認証ポリシーでassertionassertionされてしまい、属性交されてしまい、属性交 換時のデータ等が悪意のある換時のデータ等が悪意のある RPRP に盗まれるに盗まれる
- 39. return_toreturn_to とと realm (7)realm (7) 良い例良い例 SignOn.comSignOn.com きちんときちんと return_toreturn_to が表示されている！が表示されている！
- 40. return_toreturn_to とと realm (8)realm (8) どのように対策すべきかどのように対策すべきか OPOP は、当然だがは、当然だが return_toreturn_to のの URLURL がが realmrealm で指定で指定 されたパターンに合致しない場合は弾くされたパターンに合致しない場合は弾く またまた return_toreturn_to が異なるドメインを指定していた場合が異なるドメインを指定していた場合 も弾くも弾く realmrealm の指定範囲が広すぎるの指定範囲が広すぎる (*.com(*.com とかとか)) の場合もの場合も 弾く弾く RP DiscoveryRP Discovery と言うのもあるがこれへの対策の決定打と言うのもあるがこれへの対策の決定打 とはならなさそうとはならなさそう ちなみにちなみに RP DiscoveryRP Discovery とはとは YadisYadis をを RPRP に対して行う事。に対して行う事。 結果は結果は RPRP のの callbackcallback URLURL がが XRDSXRDS で返って来る。で返って来る。
- 41. noncenonce の確認の確認 (1)(1) openid.response_nonceopenid.response_nonce 値値 認証アサーションが成功した場合に認証アサーションが成功した場合にOPOPから返から返 されるレスポンスに含まれるされるレスポンスに含まれる OPOP はこの値が認証アサーションごとにユニーはこの値が認証アサーションごとにユニー クである事を保障するクである事を保障する
- 42. noncenonce の確認の確認 (2)(2) RPRPがすべきことがすべきこと このこの noncenonce 値に対して同じ値に対して同じ OP Endpoint URLOP Endpoint URL からのからの 認証アサーションを既に受け付けていないかを確認す認証アサーションを既に受け付けていないかを確認す べきであるべきである つまりつまり OP Endpoint URLOP Endpoint URL と対にしてと対にして noncenonce 値を保持する必値を保持する必 要がある要がある これは認証アサーションの再利用攻撃であるこれは認証アサーションの再利用攻撃である ReplayReplay 攻撃の防攻撃の防 止策止策 noncenonce では防げないことでは防げないこと ユーザの通信路に中間者が居る場合、ユーザよりも早く認証ユーザの通信路に中間者が居る場合、ユーザよりも早く認証 アサーションを利用してしまう可能性があるアサーションを利用してしまう可能性がある TLS/SSLTLS/SSL を使えば良いを使えば良い
- 43. noncenonce の確認の確認 (3)(3) OPOP がすべきことがすべきこと statelessstateless モードモード (association(associationハンドルが無いハンドルが無い)) 時に署名検証の為に行う時に署名検証の為に行う check_authenticationcheck_authentication の際のレスポンスを、の際のレスポンスを、 それぞれのそれぞれの noncenonce に対してに対して22回以上発行しない。回以上発行しない。 つまり発行したつまり発行した noncenonce を覚えておく必要があるを覚えておく必要がある これもこれも ReplayReplay 攻撃対策攻撃対策
- 44. Identifier RecycleIdentifier Recycle -- 再利用問題再利用問題 (1)(1) 例えば次のようなケースを考える例えば次のようなケースを考える ユーザが用いているユーザが用いている Claimed IdentifierClaimed Identifier のドメインがのドメインが 他者の手に渡る他者の手に渡る OPOP が用いているドメインが他者の手に渡るが用いているドメインが他者の手に渡る OPOP上で既に退会したユーザの上で既に退会したユーザの IdentifierIdentifier を他の人に再を他の人に再 発行する発行する どうなるかどうなるか いずれにせよ他人によっていずれにせよ他人によって IdentifierIdentifier を騙る事が出来を騙る事が出来 てしまうてしまう これがこれが Identifier RecycleIdentifier Recycle 問題問題
- 45. Identifier RecycleIdentifier Recycle -- 再利用問題再利用問題 (2)(2) URLURL の場合の場合 OPOP はそもそも失効したはそもそも失効した IdentifierIdentifier を再発行すを再発行す べきでは無いべきでは無い 仮に再発行する場合は重複しない値を仮に再発行する場合は重複しない値を URIURI fragmentfragment としてとして Claimed IdentifierClaimed Identifier に含め、に含め、 それを認証アサーションの結果に入れるそれを認証アサーションの結果に入れる つまりつまり RPRP はユーザの一意性を判断する為にはユーザの一意性を判断する為に Claimed IdentifierClaimed Identifier とと fragmentfragment の対を保持する必の対を保持する必 要性がある要性がある
- 46. Identifier RecycleIdentifier Recycle -- 再利用問題再利用問題 (3)(3) XRIXRI の場合の場合 そもそもそんな事は起こらないそもそもそんな事は起こらない ii--namename 例えば例えば ==zigorouzigorou のような物のような物 これは失効したら他者が取得する可能性があるこれは失効したら他者が取得する可能性がある ii--numbernumber 永久に変わらない値で永久に変わらない値で =!545A.6972.43FA.38AD=!545A.6972.43FA.38AD のの ような値ような値 XRI ResolutionXRI Resolution の結果であるの結果である XRDSXRDS 文書の文書の CannonicalIDCannonicalID 要素に書いてある要素に書いてある RPRP はこの値を信じれば良いはこの値を信じれば良い
- 47. Reputation (1)Reputation (1) -- 評判評判 (1)(1) ReputationReputation とは何かとは何か 対象がどの程度信頼できるかを測る指標対象がどの程度信頼できるかを測る指標 OpenIDOpenID には現時点で、には現時点で、OPOP やや RPRP、ユーザに対しての、ユーザに対しての ReputationReputation システムが存在しないシステムが存在しない ReputationReputation の無い世界で何が起こる？の無い世界で何が起こる？ 野良野良 OPOP を信じて良いかどうか分からないを信じて良いかどうか分からない OpenIDOpenID はは User CentricUser Centric な分散認証システムな分散認証システム つまり、どういうつまり、どういう OPOP と認証するか分からないと認証するか分からない 困った困った、、、、、、どうする？どうする？ 現時点での解は特定の現時点での解は特定の OPOP しか採用しないホワイトリストをしか採用しないホワイトリストを 作るしかない作るしかない
- 48. Reputation (2)Reputation (2) -- 評判評判 (2)(2) で、ホワイトリストはどう作るで、ホワイトリストはどう作る 残念ながら基準はありません＞＜残念ながら基準はありません＞＜ ここから個人的な見解になりますここから個人的な見解になります と言う訳で参考程度と言う感じで聴いて下さいと言う訳で参考程度と言う感じで聴いて下さい
- 49. Reputation (3)Reputation (3) -- 評判評判 (3)(3) 例えばどこかのブラックリストに載ってな例えばどこかのブラックリストに載ってな いかを確かめるいかを確かめる http://http://malwaredomains.commalwaredomains.com// とかとか Google Safe Browsing API ? (Google Safe Browsing API ? (この用途で利用この用途で利用 出来る出来るAPIAPIかどうかは未確認かどうかは未確認)) 疑わしきは罰する方針疑わしきは罰する方針
- 50. Reputation (4)Reputation (4) -- 評判評判 (4)(4) 外部から分かる情報から評価外部から分かる情報から評価 例えばドメインを長く所有し、例えばドメインを長く所有し、OPOP として長い間、運用として長い間、運用 実績がある事を評価する実績がある事を評価する あるいは特定の機能の実装状況を見るあるいは特定の機能の実装状況を見る それは先のリダイレクト時にどう表示されるとかそれは先のリダイレクト時にどう表示されるとか パスワードリマインダがしっかり実装されてるだとかパスワードリマインダがしっかり実装されてるだとか OpenIDOpenID 固有の問題も評価対象に固有の問題も評価対象に OP Endpoint URLOP Endpoint URL にに TLS/SSLTLS/SSL を使ってるかどうかを使ってるかどうか discoverydiscovery の形式は何かの形式は何か ( HTML( HTML ベースよりベースより YadisYadis やや XRIXRI ResolutionResolution の方が良いとかの方が良いとか ))
- 51. Reputation (5)Reputation (5) -- 評判評判 (5)(5) いずれにせよ機械的に評価出来れば最も良いずれにせよ機械的に評価出来れば最も良 いい さらに言えばそれをさらに言えばそれを RPRP がいつでも利用出がいつでも利用出 来るように出来ればいい来るように出来ればいい ドラフトは出てるドラフトは出てる Trusted Data ExchangeTrusted Data Exchange http://http://wiki.openid.net/Trusted_Data_Exchangewiki.openid.net/Trusted_Data_Exchange
- 52. まとめまとめ OpenIDOpenID のセキュリティで大事な事のセキュリティで大事な事 通信経路に出来る限り通信経路に出来る限り TLS/SSLTLS/SSL を用いるを用いる リダイレクトを挟むシーンはユーザにきちんと明示すリダイレクトを挟むシーンはユーザにきちんと明示す るる さらにプロトコルのフロー上おかしなリダイレクトは弾くべさらにプロトコルのフロー上おかしなリダイレクトは弾くべ きき noncenonce の保持、確認を徹底するの保持、確認を徹底する URI fragment, iURI fragment, i--numbernumber の保持、確認を徹底するの保持、確認を徹底する 以上の事をきちんと守れば、以上の事をきちんと守れば、RPRPでもでもOPOPでも安全でも安全 性が高いと評価されていくでしょう性が高いと評価されていくでしょう