雑記

◆ IP変更について

なるべくDNSが引けない時間が短くなるよう，レジストラに変更のタイミングをお願いしたりしていますが，27日あたりからしばらくの間，on-sky.netとの通信が出来なくなると思われます．ウェブやftpサーバにはIPアドレス直指定でアクセス可能ですが，メールは届かなくなる可能性大です．セカンダリがうまく働いてくれれば，あっさり行くかもしれませんが． とりあえず，DNSが引けなくなったときのために，IPアドレスを公開しておきます．

・28日10:00まで	211.6.119.236
・28日11:00以降	202.220.231.236

27日夜に仕込んで，工事終了予定時刻の28日11:00にはリブートが かかるようにするつもりですが，忘れるかもしれません． こちらのサーバの準備はほぼ終わっているので，プロバイダの技術者が28日より前にこっそり新しいほうのルータを繋げてくれると幸せになれるのですが．やってくんないかなぁ．

ここの所すっかりF1観戦日記と化してますな。F1が唯一の息抜きと化しているせいなんですが。。。あと2週間ほどは修羅場が続きそう。

◆ F1モナコGP決勝

うーん、琢磨選手残念。奇数グリッドだったのでジャンプアップを期待していたら、予想以上のスタートを見せてくれた時には大興奮だったのですが。

シュー兄は思いっきり壁を蹴りつけてましたね。不可解なブレーキングに意味のないモントーヤへの寄せはどうかと思いますが、そこで引かずにぶつけちゃうモントーヤもらしいというか。弟はいよいよ本格的にヒール転向でしょうか。ってアロンソとの絡みは肝心のところが良く見えなかったので決め付けるといけないかもしれませんが。

ルノーはフェラーリへの挑戦権を得た感じでしょうか。B.A.R.は完璧なマシンを2台作れるほどの実力はまだないということなのかな。もしそうなら琢磨選手は厳しいですね。マクラーレンは予選だけで、トンネルは長そうでしたねぇ。ウィリアムズは車よりドライバーの方がごたごたしているせいで結果が出ない感じ。トヨタはひっそりとダブル入賞でマクラーレンに迫る勢いです:-)。ザウバーとの三つ巴でしょうか。ジャガー、ジョーダンはすっかり下位チームに、ミナルディは定位置ですが。

◆ も〜いや。今日は寝る。

デスマーチから抜け出せない…　もうちょっとだと思ったのに。

◆ WASForum2010

参加してきましたので、自分なりのまとめや感想など書いてみます。

オープニングセッション

• これまでのセキュリティ問題に関する議論はサーバ・デベロッパ重視
• ユーザーに目を向けよう
• ブラウザの「派手さ」とユーザーの「上手さ」：専門家は地味なブラウザ(w3mとか)を好み、下手なユーザは派手なブラウザを好む
• 3つの危険
  • あそびとしごと、まぜると危険：あそびにはFirefox、しごとにはChromeとか使い分けよう
  • パスワードの使いまわし危険：2要素認証とかクライアント証明書とか…
  • もう一つはメモし忘れた
• 危険をどうやって伝えるのか？^Jということで以降のセッションに続く

ユーザの「上手い」「下手」は、セキュリティ意識の高さといった意味合いで使っているようでした。で、「上手い」ユーザーが地味なブラウザを使うというのは良いとして、「専門家」はもう一歩踏み込んであえて「派手な」ブラウザを使うようにしないと、「下手な」ユーザーがさらされている危険に気づかないのでは？と思ったり。挑発的なことを書いてしまうと、今回のメインテーマであった携帯認証の危機的な状況にしたって、「上手い専門家」がこれまで携帯の利用を避けていた結果、今こうなっちゃってるという側面が無いとも言えなくもないわけじゃないんじゃないかと思わなくもないわけで。

国民のためのウェブサイトを運営するID認証の舞台裏

Yahoo! Japan IDについてのお話

• 概要
  • アクティブユーザ数・登録数など
  • ログイン試行数に対してエラー(失敗)が1割程度
    • ID/パスワードの不整合がほとんど(それ以外って何だ？）
    • 内部：外部サービス比(内部がほとんど）
  • パスワードの再確認の割合
• ニーズへの対応
  • サービス数150以上
  • 子供向けID(Yahoo! KIDS)ではかなり気を使っている
• セキュリティ
  • ログイン三兄妹
    • ログイン履歴：成功・失敗とうの履歴を表示^J正規ユーザーへのサービスと言う側面と、悪意のあるユーザに対する警告(変なことすると記録が残るぞ！)という側面
    • ログインアラート：変なアクセスを感知してメールで通知＆ブロック用のURLを提示→クリックして開くだけでアクセスをブロックできる
    • ログインシール：ユーザーが登録した秘密の文字列をシールとしてWebページ内に表示することにより、フィッシングサイトの判別に利用(フィッシングサイトでは、正しいシールが表示されない)
  • 残念ながら利用率は低い
    • デフォルト(強制的な)機能ではない
    • かといって勝手に有効化するわけにも行かない(メール通知がうざいとか)
  • 新しい仕組みの検討
    • リスクベース認証
  • 「利便性を保ちつつ全てのユーザーを守りたい」を目標に
• オープン化とプライバシー
  • OpenIDとOAuthへの対応：同意画面による提供属性の確認と選択
  • 連携レベル：IDのみ、属性、決済、ポイント
  • どの属性情報をどの外部サービスにどういったルールで提供するか？
    • 本人に結びつく物と仮想的なユーザーの情報
    • 公開レベル区分：同意による公開、同意後に審査の上公開、非公開
    • 現状は独自に判断：横の連携や共通ルール化できると良いのだが…

実務ベースの具体的な数字や資料が出てきてとてもためになるセッションでした。連携レベルとか公開レベル区分とかはパブリックにしてしまって、デファクトスダンダード化を狙うというのも手じゃないかなあと思いました。

OpenIDのモバイル対応 〜 認証基盤連携フォーラムの取組み他から

認証基盤連携フォーラムの偉い人(?)のお話でした。

• Digital Identityとは
  • 文献：Phill Windley 'Digital Identity'
  • Identity Attribute:形質、属性、関係性(Wiiで言うところのmiiがそれに近い、身体的特徴のイメージ化やWii-netでの他ユーザーとのつながりまで含んだモノ)
• 認証基盤連携フォーラム：2009年総務省から実験の受託
  • キーワード：「分散&連携」「ユーザー中心」「硬化用」「信頼&評判」
• モバイルからのOpenIDの利用：開けない! GET URL長すぎ。
• 属性連携の評判は良い(9割以上が利用したい)^Jただし、情報提供先サイトの信憑性についての情報が欲しいとの要求も高い→OITFモデル
• Artifact Binding WG:
  • デモ：https://openid4.us/
  • magic signatureを使った署名
  • 秋ごろには固まるかな…
  • ASCIIの国の人が考えた仕様なので…：スクリプト表現案の工夫
• Q&A
  • SAMLとの違い、Atrifact Binding(AB)および全体として
    • ABはSAMLのものをOpenIDでも出来るようにした
    • ○○(聞きそびれ、文脈からしてSAMLかな)はDiscoveryベース
    • OpenIDの方が実装が簡単
  • 認証基盤連携フォーラムのその他の活動
    • OpenIDとSAMLの相互運用性確保
      • 認証結果のやり取り
      • Yahoo! IDでGoogle Appsにログイン
    • IdP間のIdentity移行の課題の検討：
      • これまではSP=IdPで、サービスの終了と同時にID破棄で済んでいた
      • IdPがサービス終了したときに、アカウント情報をどうするのか？^J→継続性を保証するための組合(?)で加盟組織についてはサービスの継続性を確保済み
    • 利便性の検討
      • デバイス間でのセッション引継ぎ：モニターテスト済み。おおむね好評
    • 今の携帯の固有ID方式は駄目だよね
    • 携帯キャリアのIdP化への道はあるのかも

このセッションも含め、全体的にSAML(Shibboleth)をスルーしているのが個人的には非常に不思議な印象を受けました。SAMLとの違いを聞かれた時の答えもいまいちはっきりしなかったし、議論の中で先日書いたような話にかなり近い話をしているのに、概念レベルで留まっていて、ShibbolethでのeduPersonTargetedIDについての言及が一切ないあたりからして、ひょっとしてOpenIDな人たちは一生懸命に車輪の再発明してるんじゃないかという気が。だとすると非常にもったいない話ですが、とっくに検討済みで、なんか問題があるので別の解決を目指してるだけかもしれません。

ケータイ2.0が開けてしまったパンドラの箱

かんたんログインの話でした。どこまで書いていいのか分からないので、差しさわりのないことだけ。

• かんたんログインのおさらい
  • 端末固有IDは秘密情報ではない
  • 端末固有IDやHTTPリクエストのヘッダは書き換え出来ないのが前提
  • ところが…
• テーマ：携帯端末にHTTPヘッダを書き換える機能がない、のか？
  • docomoのJavaScriptでsetRequestHeader()が使えるんじゃ？ということで調査^J→サービス再開後は使えなくなってた
  • DNS Rebindingによる攻撃：アドバイザリ公開済み
    • 対策：リクエストヘッダのHostフィールドをチェックする
    • Hostフィールドを書き換える方法はないのか？^J(以下略)

結構怖いお話でした。ちなみにスマートフォンとその開発キットを使えばヘッダなんて書き換え放題ってのはご存知なのかな？Symbian OSならPythonで開発できるので実験とか楽そうなんですが。その前にNokia撤退という壁がありますが。

どうするケータイ認証

ケータイ認証の問題点とその影響について。

• 携帯電話で使われているID：契約者固有IDと端末固有ID
• 端末固有IDによるかんたんログインはやっちゃ駄目(2009年夏)
• 契約者固有IDは安全か？
  • CGIの仕様による'-'と'_'の混乱
  • SSL接続ではキャリアによるヘッダチェックが出来ない(通信が暗号化されているため)
• cookieベースの「次回から自動的にログイン」機能で十分では？
  • クッキー食えないのはdocomoだけ
  • iモード端末1.0だけ特別扱いする
• なぜいまさら騒ぐのか？^J→携帯認証の悪しき習慣が一般サイトにまで波及する恐れ
  • 携帯電話のIDが国民ID的な機能を持ちつつある^J→そこでかんたんログインのような間違った方式が一般的になるのは非常に危険(後戻りできなくなる)
  • Webサイト側で対策を迫られる可能性(やってられないなどとは言えず、そろそろ心構えしておく必要がある)

「端末固有IDをかんたんログインに使わない」という結論が出たのは去年の夏の話だ、ということでしたが、OpenPNEとか最新版でも端末固有IDを使ったかんたんログインが有効になってて、ソフトバンクどうしならなりすましし放題なのはどういう決着をしてそうなっちゃったんでしょうか。ユーザーが端末側の設定でonにしなければ端末固有IDは送信されないので、ユーザーの自己責任ってことなのかな。

OAuthとWEBサイト運営のエコシステムに潜む罠

OAuthのお話でした。

• エコシステム：特定業界の収益構造をさす言葉
• 認証(AuthN)と認可(AuthZ)の違い
• Twitterのエコシステム
  • 連携の手法
    • ID/パスワードを連携サイト側で預かる^J→預けたサイトでは生パスワード保存になるので危険
    • Basic認証^J→6月末廃止(ログアウトできない)
  • OAuth：認可の委譲
  • OAuth1.0の問題：Session Fixation^J→1.0aで対策済み
  • デスクトップアプリではxAuthを使う

パスワードを第三者に預けさせる状態でスタートしてブラッシュアップしていったってのはある意味すごいです。

“Web2.0”におけるセキュリティ 〜 セキュアなWeb2.0環境の構築とは

駆け足でメモが追いつかず。脅威を7つに分類して、それぞれの説明と対策について。網羅性やサンプルがすごく充実してました。資料を後で公開してもらえると言うことだったので楽しみです。

SDL脅威分析の方法とWindows Live IDにおけるアプローチ

Security Development LifecycleとLive IDの解説

• SDL
  • セキュリティアプローチはパッシブモードからプロアクティブモードへ
  • 攻撃はどこ(内)からでも来る
  • 信頼の境界線
  • STRIDE
• Live IDデモ
  • 渡すのはIDだけ、属性を受け取りたい場合はDedicated版を利用する

Live IDのOpenIDサポートってどんな状況なんでしょうか？なんか2008年に発表したっきりで、ベータ版のサイトは500になっちゃってるし。最近、DreamSparkがShibbolethに対応してるのを知ったのですが、乗り換えたのかな。

まとめ

ということで、全体的に非常に濃い内容で、満足のいくイベントでした。なんか回し者のような感想になってしまいましたが、ShibbolethはOpenIDとあわせて勉強しておいて損はないシステムだと思います。