More Related Content Similar to The Security of OpenID Authentication 2.0 Similar to The Security of OpenID Authentication 2.0 (20) More from Toru Yamaguchi (17) 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// ((個人活動、有志個人活動、有志))
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_*_* の結果が妥当であるかどうかを検の結果が妥当であるかどうかを検
証する証する
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>
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 へリダイレクトへリダイレクト
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)) の検証の検証
アサーションの署名の検証アサーションの署名の検証
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
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 に盗まれるに盗まれる
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 で返って来る。で返って来る。
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
