2016年7月25日月曜日

続！#PokemonGo のログインと OpenID Connect

こんにちは、富士榮です。

昨日に引き続き Pokemon Go / ポケモン Go です。

だいぶレベルあがりました。


昨日のポストに対する皆様の反応を拝見していると、iOS版はわかったから、Android版はどうなの？という意見が多かったので、今回はAndroid版です。

また、結局 Pokemon Go はどういう権限を要求しているのか？について若干混乱が見られたので、そのあたりもついでに整理していこうと思います。

では、早速見ていきます。

まずは、Android版の動きです。

◆環境設定

昨日のiOSと同様に、Wifi設定よりProxyサーバとしてPC上で動かしているFiddlerを使うように設定します。


準備はほぼ同じなので、さっそくGoogleでログインしてみます。


◆ログイン時のトラフィックの違い

実際にログオンしてみるとiOSとは大きな違いがあることがわかります。
iOS版では、WebViewが立ち上がりGoogleアカウントでログインする必要がありますが、Android版ではOSにログオンしているGoogleアカウントがシームレスに使われるため、改めてGoogleへログインする必要がありません。

トラフィックをキャプチャすると、android.clients.google.com/authに対して直接client_idなどをPOSTしてid_tokenを受け取っています。

POST https://android.clients.google.com/auth HTTP/1.1

POSTデータ
androidId=3798d3c8e02a1cce
&lang=en_US
&google_play_services_version=9256438
&sdk_version=23
&device_country=jp
&client_sig=321187995bc7cdc2b5fc91b11a96e2baa8602c62
&callerSig=321187995bc7cdc2b5fc91b11a96e2baa8602c62
&Email=reign.of.pharaoh%40gmail.com
&service=audience%3Aserver%3Aclient_id%3A82..snip..b.apps.googleusercontent.com
&app=com.nianticlabs.pokemongo
&check_email=1
&token_request_options=
&callerPkg=com.nianticlabs.pokemongo
&Token=oauth2rt_1%2FBF_GAY86cPwrwUgpf2HZd3pV71FRTE0q-YgCePsVp2E

ちなみに、iOS版とはclient_idが違うんですね。
このリクエストに対して、HTTP 200で以下のデータが返ってきます。Authにid_tokenが入ってきています。

Auth=eyJhbGciOiJSUzI1N...snip...d9LC7FGaQ
issueAdvice=auto
Expiry=1469374236
storeConsentRemotely=1
isTokenSnowballed=0

jwt.ioでdecodeするとちゃんとid_tokenになっています。



以降のAPIコール時はiOSと同じくid_tokenがPOSTされているので、Android版でもid_tokenに乗っている情報以外（iOSと違って、メールアドレス以外に姓と名がid_tokenに含まれます）はサービスにはわたっていないことがわかります。

まぁ、一安心ということで。



◆結局どういうパーミッションが求められているのか？

前回も今回もOpenID Connectという文脈でPokemon GoアプリケーションがGoogleへどのような情報や操作を要求しているのか？を見て、とりあえず新規にGoogleアカウントを作らなくてもよさそう、という結論に達しました。

しかし、前回のポストに対するコメントとして、連絡先へのアクセスが要求されたりするので、やっぱりアカウントは新規に作る方がいいのでは？みたいなコメントもありました。

確かにAndroid版を見ると、アプリが端末に対して連絡先へのアクセスを要求しています。
※理由はよくわかりませんが。。。
＜iOS版＞

＜Android版＞


ここは非常に混乱を招きやすい部分ですが、結論から言いますとアプリケーションが端末に対して要求している権限と、Googleアカウントでログインする際にGoogleに対して要求する権限は全く別のものであり、Googleアカウントの新規作成うんぬん、という話は後者にしか関係しません。（いわゆる、OAuthのscopeパラメータの話ですので）

ここで言う連絡先へのアクセスは前者の端末インストール時の話なので、連絡先へのアクセスが嫌なのであれば、Googleアカウントを新規に取り直すのではなく、専用端末を新規に購入すべきである、ということになります。

まぁ、この辺りは確かにユーザにとってわかりにくいですね。


時刻: 0 件のコメント:

2016年7月24日日曜日

攻略！ #PokemonGo のログインと OpenID Connect

こんにちは、富士榮です。

世の中 Pokemon Go / ポケモン Go 一色ですが、いかがお過ごしでしょうか？

あいにく私の住んでいる地域は過疎化が進んでおり、ポケモンがほとんどおりません・・・・



おかげで全然レベルが上がらないので、ジムなどには無縁な平和な生活を営んでいるわけなんですが、果たして Pokemon Go のログオンは平和なのか？という ID 厨なら必ず抱く疑問を解消すべく、家族で地元の夏祭りに参加している横で解析をしてみました。

公開当初はフルアクセスを要求するアプリだったので、プチ炎上したりしましたが現状は解消されたということなので、パケットキャプチャしてみます。

　参考）ポケモン Go がフルアクセスを要求していた件。



では早速、Pokemon Go へのログインの仕組みを見ていきましょう。
Pokemon Go ではいわゆるローカルアカウント（Pokemon Trainer Club）と Google アカウントを使ってログオンする2つの仕組みが用意されています。

色々な Web サイトを見ると、専用の Google アカウントを作るべきである、というような記事を見かけたりしますが、根拠として先のとおり、すべて権限を要求するから、という理由が挙げられています。

　参考）ポケモン Go をプレイするなら専用の Google アカウントを作るべき


まぁ、公式発表によると権限周りは修正されたということなのですが、実際にどのような権限が要求されているのか、ログオン～ユーザ登録のシーケンスにおいて何が起きているのかを見ておきたい、ということで解析してみましょう。

◆準備

基本的に通信をキャプチャすることになるので、プロキシを用意して HTTP/HTTPS の通信を覗いてみたいと思います。今回はiOS版を使ったので、PC にインストールした Fiddler をプロキシとして使うように iOS の Wifi 設定を行います。

今回は、PC で Fiddler を立ち上げ、リモートクライアント向けのプロキシとして動作するように設定を行いました。

Tools より Fiddler Options を開き、Connections タブへ以下の通り設定を行います。
- Fiddler Listen Port : 8888（デフォルト）
- Allow remote computers to connect : ON

これで PC にインストールした Fiddler がプロキシとして動作するようになります。
ちなみに、 Windows Firewall が邪魔をするので、外部からの 8888 への通信を許可するように設定をしておく必要があります。

また、HTTPS 通信を復号するためには、Fiddler の使う証明書を iOS が信頼するように構成する必要があるので、 Fiddler で証明書をエクスポートし、iOS 側へ送信、インポートしておく必要があります。（細かい手順は割愛します）


次は、iOS 側の設定で、Fiddler をプロキシとして使うようにしまう。
設定から Wifi を開いてプロキシサーバのアドレスとポートに Fiddler を動かしている PC のアドレスと先のポート番号を指定します。




これで準備は完了です。

早速、Pokemon Go をインストールしてサインアップしてみます。

◆Google アカウントでサインアップした場合の要求スコープは？

Pokemon Go を起動し Google アカウントでサインアップを選択します。


ここで、Googleを選択した時の通信キャプチャを見ると、以下のようなリクエストが飛んでいます。


GET https://accounts.google.com/o/oauth2/auth
?client_id=84....snip......apps.googleusercontent.com
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&response_type=code
&scope=openid email https://www.googleapis.com/auth/userinfo.email HTTP/1.1

注目すべきは scope パラメータです。OpenID Connect のリクエストなので当然 openid は含まれるとして、email および https://www.googleapis.com/auth/userinfo.email が含まれています。
Google の OpenID Connect 関係のドキュメントを見ると、email と は同じスコープで、メールアドレスの表示だけを要求していることがわかります。

画面上に表示されるとおりですね。

ここで、許可をクリックすると token エンドポイントへ認可コードが POST される普通の OpenID Connect の流れが続きます。

POST https://accounts.google.com/o/oauth2/token HTTP/1.1

ボディ
client_id=84...snip...alem.apps.googleusercontent.com
&client_secret=NCjF1...snip....uL7
&code=4/D7vS...snip....i7h1Q_njLCM
&grant_type=authorization_code
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&scope=openid email https://www.googleapis.com/auth/userinfo.email


結果、access_tokenやid_tokenが返ってきます。

{
  "access_token" : "ya29.Ci8pAxbo....snip...FA",
  "token_type" : "Bearer",
  "expires_in" : 3600,
  "id_token" : "eyJhbGciOiJSUzI1....snip.....XsXHNwQ",
  "refresh_token" : "1/lCAJhP...snip....TM"
}


もちろん id_token の中身を jwt.io などで覗くといい感じで Google アカウントの情報が出てきます。




さて、問題はこの後です。
email をスコープとして access_token を要求しているので、必要以上の情報を Google が提供することはありませんが、どのような要求が Pokemon Go から実施されているのでしょうか？

結論、サインアッププロセスの中で access_token が使われることはなく、 id_token の中のメールアドレスだけを使っているように見えます。

続くリクエストは運営元の Nianteclabs.com への POST なのですが、所謂 RESTful API 的に JSON などがやり取りされるわけではなく、バイナリデータが飛び交うのでこれ以上の解析はしませんが、見えている範囲では、 id_token がそのまま POST されているようです。

POST https://pgorelease.nianticlabs.com/plfe/rpc HTTP/1.1

ボディ
＜いろんなバイナリ情報＞
google
   eyJhbGciO....snip.... <- div="" id_token="" post="">


と、いうことでやっぱり OpenID Connect でのログインおよびメールアドレス情報だけを渡している、ということで、まぁ大丈夫そうです。


◆まとめ

今回はあくまでサインアッププロセスのみを見ているので、続く処理で何が行われているかはわかりませんが、とりあえずという意味では以下のことが言えると思います。

  • Pokemon Go のログイン・サインアップには OpenID Connect が採用されている
  • email アドレスのみを読み取る Scope で access_token が要求されているが、実際は id_token だけが使われている
  • 結果、メールアドレスくらいしか連携されていなさそうなので、別アカウントを作ったりする程にセンシティブにならなくてもよさそう？


注記）
  • 解析はあくまで一部分のみを対象としているので、他の処理で色々と情報を収集している可能性があります
  • 本解析は Pokemon Go のサービスを攻撃することを意図したものではありません
  • 本ポストが Pokemon Go のサービス規約に違反するなどし、サービス提供者の意図にそぐわない場合は本ポストを削除する可能性があります

時刻: 0 件のコメント:

2016年7月20日水曜日

[Azure AD]AAD Connect Health for AD DSでオンプレミスのADを監視する

こんにちは、富士榮です。

Azure Active Directory（Azure AD）やPing ONEをはじめとしたクラウド上のID基盤（IDaaS）が流行ってきていますが、どのソリューションも現状はオンプレミスにActive Directoryが存在していることを前提として構成が組み立てられています。

これは、2014年のVittorio Bertocci氏へのインタビューでもオンプレミスのActive Directoryの普及率は95%を超えている、という発言があるとおり、エンタープライズ分野へIDaaSを適用する際は既存のActive Directoryを避けて通れず、どのようにシームレスにオンプレミスからクラウドへ橋渡しをするか？がフォーカスされているため決して不自然なことではありません。

しかし、こうなってくるとクラウド側の基盤がグローバルでレプリケーションされていて高い可用性を持っていたとしても、システム全体を見た時にはオンプレミスのActive Directoryがボトルネックや障害発生ポイントとなってしまいます。

と、いうことでマイクロソフトはハイブリッドID基盤をなるべく一か所で監視・管理できるようにしたり、セキュアに運用できるように色々と関連ソリューションを出しています。


脅威／リスク対象ソリューション
稼働状況監視AD FSAzure AD Connect Health for AD FS
AD DSAzure AD Connect Health for AD FS
不正アクセス検知AD DSAdvanced Threat Analytics
特権ID管理AD DSMicrosoft Identity Manager 2016


今回は、新たにPublic Previewが公開されたAzure AD Connect HealthによるActive Directory（AD DS）の稼働状況のモニタリングについて見てみたいと思います。

　公式Blogでの発表
　Introducing #AzureAD Connect Health for Windows Server AD
　https://blogs.technet.microsoft.com/enterprisemobility/2016/07/19/introducing-azuread-connect-health-for-windows-server-ad/


仕組みとしては、監視用のエージェントをAzure PortalのAzure AD Connect HealthからダウンロードしてオンプレミスのAD DSサーバへインストール・構成するだけなので非常に簡単です。


◆エージェントを入手する

新ポータル（https://portal.azure.com）のダッシュボードにAzure AD Connect Healthがない人は追加しておきましょう。


Azure AD Connect Healthを開くとAgent for AD DSのダウンロードができるようになっていますので、Get toolsをクリックしてAgentモジュールをダウンロードします。


◆エージェントをインストールする

次は、監視対象のドメインコントローラへログインしてモジュールをインストールします。
ダウンロードしたモジュールをドメインコントローラへコピーしてインストーラを実行します。

この際、以下の前提事項があるので準備をしておいてください。。

  • ドメインコントローラ上でビルトインアカウントによるInternet Exploreが実行できること
  • microsoftonline.com、microsoftonline-p.com、micorosoft.com、windows.netのCookieを受け入れる設定になっていること（windows.netはいらないかも）
  • Azure ADテナント上でグローバル管理者権限を持つ組織アカウント（マイクロソフトアカウントではなく）が存在していること
  • ドメインコントーローラからAzureへの上り通信がブロックされていないこと

特に、Windows Server 2016では、IEの設定が厳しいのでCookieの受け入れの設定を確実にしておかないとエージェントのセットアップに失敗します。


ダウンロードしたファイルを実行すると、インストールが始まります。


インストール自体は非常にシンプルなのですぐに終わります。


◆エージェントを構成する

インストールが完了したらAzure ADのテナントへ接続し、エージェントを登録します。


うまくIEの構成がされていれば、Azure ADへのログインダイアログが起動してきますので、「組織アカウント」でログインします。（マイクロソフトアカウントだとエラーが出ます）

以下、エラーになった場合のメッセージです。
＜Cookieの受け入れ設定が出来ていない場合＞


＜マイクロソフトアカウントでログインした場合＞




うまく構成ができると、以下のメッセージが出ます。



◆ポータルより状態を監視する
インストールが完了するとドメインコントローラに関する情報がエージェントによりAzure AD Connect Healthへアップロードされます。


各種状態を確認することが出来ます。
＜FSMO、サイト、GCなど＞


＜機能レベルなどのプロパティ＞


＜認証要求数、レプリケーションステータスなど＞


ちなみに監視対象のドメインコントローラを停止すると以下のようにアラートが表示されます。
（検知するまでにしばらく時間がかかります）


これでHybrid ID基盤のオンプレミス側の構成要素であるAD DSの状態監視もクラウドから実行できますので、別途監視ツールや運用ツールを用意する必要性がぐっと下がりますので、安心して基盤の運用ができますね。


時刻: 0 件のコメント:

2016年7月11日月曜日

[FIDO]Injectorでパスワードの使いまわしや簡単なパスワードの利用を防止する

こんにちは、富士榮です。

先日のOpenIDファウンデーション・ジャパン、Enterprise Identity Working Group（EIWG）の成果報告会で、Cloud Identity Summit 2016（CIS）への参加についてBlockchainとHashgraphとアイデンティティに関する報告をさせてもらいました。

　資料等は前回のポストで。
　Blockchain、Hashgraphとアイデンティティ
　http://idmlab.eidentity.jp/2016/06/blockchainhashgraph.html


実はCISではセッションの他にExpoという形で各社がソリューションを持ち寄る展示会があり、その中でFIDO関係のブースで出展をしていたBluink社のInjectorというデバイスがとても面白かったので、取り寄せてみました。

Injectorには、Injector USB DeviceとInjector Miniという2種類がありますが、あんまり機能差がなさそうなので、持ち運びを考えてInjector Miniを購入しました。

公式サイトのストアで$29.99＋日本への送料（$15.00）の合計$44.99で購入できます。


2週間くらいで届いたので、早速試してみます。

◆何をするものなのか？

まず、そもそもこれは何をするものなのか？というと、「スマートフォンアプリに各種ログオン情報を記憶させておき、Injector（ドングル）を挿したPCでの各種ログインをスマホ経由で行う」ためのものです。

１．IDとパスワードの入力を代行する入力デバイス

（公式サイトの解説より）


簡単に言うと、PCに挿したBluetoothアダプタが入力デバイスとして認識され、スマホからログインに必要なキーストローク情報を送り込む、というかなり原始的な？仕組みです。
尚、この仕組みをとるのでPC側には基本的には何の追加ソフトウェアもいりません。
（QRコードを使って対象アプリケーションの選択を簡素化したい場合はブラウザのアドオンを入れる必要がありますが、自分でスマホ上で対象のアプリケーションを選択するなら本当に何もいりません）

試しにLinkedInへのログインを動画にしてみました。



２．FIDO U2Fに対応した2要素目のデバイス

また、違った一面としてFIDO U2Fに対応しているので、GoogleなどU2Fに対応したサービスへのログイン時の2要素目としても利用が可能です。

こちらも同じくGoogleへのログイン時の2要素目として使ってみました。

◆まずは準備

では、早速使ってみます。
準備として、スマホ用のアプリケーションをダウンロード～インストールします。



アプリを立ち上げると、マスタパスワード（このアプリ自体の起動パスワード。Touch IDも使えます）の登録およびInjectorデバイスとのペアリングを行うことになります。
（この段階でPCへInjectorデバイスを挿入します）

尚、このペアリングですが、工場出荷時はオープン状態（どのスマホとでもペアリング可能な状態）のはずなんですが、私の手元に届いたものはどうしてもうまくペアリングできず、サポートとやり取りをしてリセットをしてもらいました。（15分くらいでリセット用のコードを発行してもらいました。現地は土曜日の昼頃だったはずなんですが、驚異的なスピードです！）


うまくいくと、こんな感じでデバイスが登録された状態になります。




◆ログイン対象を登録

これでアプリとデバイスの準備が出来たので、次はアプリケーションの登録です。

アプリでAdd Credentialというメニューがあり、ある程度のアプリケーションはプリセットされているので、そこから選択すると簡単に登録ができます。


ここでアプリを選んでログインに使うIDとパスワードを登録していく、という形をとります。
尚、注意点ですが先に書いたとおり、キーストロークを送り込むという仕組みになっている以上、キーボード配列が違うと特に記号がうまく入りません。
これを使うときはPCを英語キーボードモードにしておきましょう。

後は先の動画で紹介したように各アプリを開いてスマホ側でログインをするだけです。



◆FIDO U2Fとしての登録

次は、基本的な使い方に加えてFIDO U2FデバイスとしてInjectorを登録してみましょう。
尚、これも注意点なんですが、U2Fに使う場合、キーストローク入力型の基本的な使い方との両立が現時点でうまくいっていません。（私の環境の問題かもしれませんが）
基本的な使い方の方に戻したければU2Fとしての登録を一旦削除してあげる必要があります。


動きは先に動画で紹介したので、GoogleへのInjectorデバイスの登録の方法を簡単に紹介します。基本はFIDOなのでYubikeyなどと同じくデバイスを事前に登録しておくだけです。

Googleの2段階認証セットアップを開き、セキュリティキーの登録を行います。
基本は画面の指示に従ってキーの挿入をし、アプリケーション側に表示されるRegistration確認を行うだけです。

（Googleのセキュリティキーの登録画面から指示に従いデバイスを登録する）


（うまく認識するとアプリに登録確認が出てくるので回答する）




これで完了です。
後は2段階認証の際にデバイスを挿してアプリで回答するだけです。


◆使ってみた感想

意外と良いかもしれません。
LastPass見たいなサービスに依存するものもなく、あくまでペアリングされたデバイスに依存するので、オフラインでも使えますし（それこそWindowsやMacへのログインにも使えます）、キーストローク入力するだけの簡単な仕組みなので対象のアプリケーションを選びません。
これで各アプリ向けのパスワードは本当にランダムなものを使ってしまっても問題ないかもしれませんし、ブラウザにパスワードを覚えさせる必要もありません。
（忘れた場合、Injectorの設定データのバックアップからパスワードを復元するためのツールが提供されています）

ただ、課題がないわけでもありません。
具体的にはあくまでUSB入力デバイスなので、モバイルのネイティブアプリやブラウザでの利用は出来ません。ネイティブアプリの場合はアプリケーションパスワードなどをうまく利用すればよいでしょうが、ブラウザの場合は困ってしまうので今後に期待です。
（現状でもiOSのSafariの場合はIntentでアプリを呼び出してキー入力させる様にできるみたいです）


時刻: 0 件のコメント: