Identity Conferene 15

Identity Conference 15(#idcon) に参加してきました。
非常に勉強になったので今後も参加できればなぁと思うと同時に
SSO/IDM製品の開発に携わった経験がありながら初参加という状況で少し反省。

#idcon 15th
Togetther

Yahoo! JAPANのOAuth/OpenIDに代わる新しい認証認可機能 -YConnect-

ヤフー株式会社 河内 俊介 氏

YConnectとは？

  • OAuth2.0準拠 / OpenID Connectをサポートの Yahoo!
    の新認証認可システム
  • Yahoo! でログインが可能
  • ユーザの一部属性情報の連携が可能
  • OAuth1.0 に比べて RP の実装が容易
  • 2012年末　YConnect 設計開始
  • 2012年9月中旬　パートナー向け公開開始
  • 現在　公開中
  • 対応Authorization Grant@OAuth2.0
    Authorization Code
    Implicit
  • 対応Profile@OpenID Connect
    Basic Client Profile
    Implicit Client Profile
  • 100サイト以上、50以上の企業に提供 毎日新聞社、GREE等等
  • 社内アプリには続々対応中

用途の紹介

  • Yahooウォレットと連携することで決済システムを簡単に実装
  • 属性情報の連携(ユーザ識別子、氏名、生年月日、ロケール情報、メールアドレス等等)
    プレミアム企業には更に多くの属性情報を開示している

導入構成図事例

  • Authorization Code 利用例
  • Implicit 利用例
    シーケンスの紹介

裏話

  • OAuth1.0やBBAuthはYahoo!incのローカライズだった
  • ブラックボックスのため、メンテナンス工数が大変
    -> YConnectはフルスクラッチで開発することによりこの問題を解決
  • 全WebAPIのSSL化を行う必要があった
    -> ワイルドカードの証明書で対応
  • 仕様理解を深めるため、RFCの翻訳業務をPJで行った
  • Apple Store の reject 事例
    ブラウザを開いたタイミングでリンクがあると、課金の可能性を指定されrejectされた
    -> リンクを省くことで解決
    アプリケーションからsafariを使用してloginしたらrejectされた
    ログインしないと使えないようなアプリケーションはrejectされる可能性がある
    -> 解決策は見つかっていない
  • 認証PF一覧
    用途によって認証PFが分散し、ユーザ識別子も分散していた
    　OAuth1.0 / Open ID2.0 / SSO 等
    　-> YConnectでは上記全てを解決している
  • 以下の機能拡張を検討中
    PPID
    OTP対応を検討中
    シングルログアウト(Session Management)

Q. カスタムURIスキーマが被ってしまった場合のセキュリティリスクは？
A. Yahoo!が提供しているアプリは他社のアプリと被らないようにしている。
攻撃者がいた場合、技術的には被らせることは可能。今後の課題として扱う。

「Andouroid Android OSのカスタマイズによるアプリ間統合認証の実現」

ヤフー株式会社 安藤 義裕 氏

  • Android OS layor からアタッチ
  • 個人(趣味)で開発
  • デモンストレーション
    Yahoo!のアプリ二種類を使い、一方のアプリにログインすると
    もう一方で認証が必要なくなる仕組みをデモ

1. Yahoo!メールアプリの起動
　　未ログイン状態
　　アプリ終了
　2. Yahoo!ブラウザの起動
　　メールページを開く
　　未ログイン状態
　　UID/PWD入力
　　ログイン成功、コンテンツ確認
　　アプリ終了
　3. Yahoo!メールアプリの起動
　　ログイン状態を維持(SSO成功)

改修内容

  • WebKit(OSとアプリの中間レイヤー)の改造
  • ログイン画面を開く前にトークン(ストレージ)に問い合わせる仕組み
  • トークンはアプリケーション間で共有している
  • AndroidはアプリケーションごとにLinux UIDが割り当てられている
  • アプリが使用する Android 内の database file 等は上記の UID/GID
    により 660 の permission を付与し、 ACL を行っている
  • あんどうろいどは上記の database file
    に対し、独自user(yahoo)のアクセスを追加

  • Androidのデータ共有の方法
    Content Provide
    　カレンダー、データ帳を他のアプリに提供
    Intent
    　アプリ間のデータのやりとり
    Shared Preference
    　テキスト等小さなデータを保存する。アプリ間の共有可能
    Shared ID

    Play!Storeにuploadする際に、証明書を作成する。同じ証明書を使用していれば複数のapplicationで同じUIDを降ることができる

    信頼できる大企業により同一の証明書を使用しアプリ間で情報連携を行うようにすれば、従来と異なるマーケットを開拓できるのでは
    その他(SQLite, Local File, Internet(Cloud))

デバイス時代のID

  • OSを握ってカスタマイズができる立場は非常に強力と感じている
  • Apple, Google
    をみてわかるように、OSベンダーであるからこそ出来ることは多い
  • やりたいこと、センシティブな情報の共有は、OSを握っているか否かで自由度がかなり変わる
  • デバイスの時代になると、デバイスのIDとWebのIDの境目は今後薄れていくと考えている

Q.　パッケージ名でYahoo!のアプリであることを判別している(模造可能、プロトタイプ版のため)
A.　アプリケーションにsignatureを付けることで正当性を確認する等の対応になると推測している

Q.　ストレージで何を共有していたか
A.　Cookie。本来はトークンになるべきところ。

C向けサービスで2要素認証を普及させるためにできること

株式会社ミクシィ 伊東 諒 氏
Slide

現状と課題

  • C向けサービスにおける2要素認証の現状
  • 金融系、ゲーム系などでは以前から普及
  • ユーザ数の多いサービスも実装
  • ワンタイムパスワードが実装方法として流行
  • ID/PWD認証 + αをオプションで提供
  • 脆弱性や課題については黙認状態

普及への課題

  • ついてこれないユーザー
    サービスごとの設定は面倒

  • 導入しにくいプロトコルの存在
    POP/IMAP/SMTP, XMPP, …
    認証とリソースアクセスの強い結びつき

  • 解決策
    Yahoo! Google Facebook 等に OpenID Connect で Rely する
    信頼あるプロバイダの認証強度をそのまま利用できることがメリット

    認証とリソースアクセスの強い結びつきに対し、アクセストークンを利用して分離することで対応

  • OpenID Providerがやるべきこと
    認証強度の見える化
    　RPからみて、OPがどのような認証をするのかを把握できることが大切 対応する認証強度を開示
    認証したユーザの認証強度を提供
    求められる認証強度をRPに指定させる

  • Relying Partyがやるべきこと
    自らのサービス・ユーザアクションに求められる認証強度を意識する 適切なタイミング、強度で再認証を要求する

  • 残る課題
    2要素認証を採用しないOPはG
    1 USER per 1 OP の風潮
    -> ID/PW + αは組み合わせにくい?

  • 追加認証に特化した認証プロバイダ
    RP側が既存OPとの組み合わせ
    Trustが重要
    　B向けに実績のあるサービスの進出
    物理デバイス、生体認証などの可能性

まとめ

  • 最大の課題は”めんどくさい”と思わせるユーザビリティ
  • OpenID Connect は重要
  • 経済合理性は別として追加認証に特化した認証プロバイダは有用かも

実際に追加認証に対応したプロバイダを作成してみた - SecondAuth -

  • メールアドレスがあれば登録可能
  • OTP 認証のみ実装
  • OpenID Connect OP
  • YConnect, Google, Faceboo k から受け取った確認済みメールアドレスを利用
  • OTP 認証には Google Authenticator を利用(Server側の処理)
  • ユーザ単位に Secret 作成
  • 設定用の QR コード生成
  • otpauth://totp/(mailaddress)
  • secret=(base43_encoded_otp_secret)
  • ユーザはアプリをインストールし、QRコードを読み取るだけ

リモートログアウト

  • 現在アクティブなセッションを一元管理
  • 手元で別の端末をログアウト可能
  • Facebook, Googleが実装

OpenID Connect Session Management

  • OPのログアウトをRPから検知するための仕様
  • AuthZ Response にセッション識別子
  • iframe + postMessageを送り続ける
  • OPのログアウトをRPから検知し、他のRPのセッションも終わらせる等

#idcon mini のお知らせ

  • もっと技術的な話をしたい人向けに #idcon mini を計画している
  • 少人数、USTなし
  • アンカンファレンスもどき
  • 技術屋が気になることをじっくりと話せる場

パネルディスカッション「スマデバ時代ぼくらは幾つパスワードを使うのか 」※USTなし

ヤフー株式会社 セントラルサービスカンパニー 技術調査室 室長 楠 正憲 氏
米国・OpenID Foundation 理事長 崎村 夏彦 氏
セコム株式会社 IS研究所 松本 泰 氏
OpenID Foundation Japan 事務局長代行 高橋 伸和 氏
独立行政法人 情報処理推進機構 神田 雅透 氏

  • パスワードはどのくらい前からあるか
    1961年頃らしい。IBMのメインフレーム。
    一昨年がパスワード誕生50年

  • SSLが安全であるという土台の上に認証基盤を考えてきた
    2011年頃からきわどい状況になっている
    従来の認証基盤を維持していけるのかを考えていかないといけない時期

  • SSL/PKIはなぜ危機に陥ったのか 　 本セッションに興味があれば、PKI DAY
    2012から資料を取得

    サイバー攻撃ツールとしての公開鍵証明書の役割
    (個人的に必見の資料だと思います。)

  • ネットの信頼性は技術、制度・運用、実装、ユーザリテラシの4点から担保されている

  • ルートCAはPKIのTrust Anchor

  • 公開鍵証明書が悪用されるのはどんなとき?
    ハッキングの問題
    　登録局の検証ミス
    　認証局への不正アクセス
    暗号技術の問題
    　計算量により秘密鍵を割り出す(公開鍵暗号の根本的な問題)

    真正な公開鍵証明書と区別ができない不正な証明書を計算機により偽造(ハッシュ関数の問題)
    運用の問題
    　秘密鍵の流出
    　意図せず秘密鍵を共有

  • DigiNotar のケース(PKIの危機を招いた事例)
    不正SSLサーバ証明書がCA機能を乗っ取られて発行

    EV-SSLサーバ証明書発酵用CAを含め、少なくとも6つのCA(疑いを含めると30個以上のCA)に不正侵入され、不正SSLサーバ証明証を発行

  • ルートCAとしてはあまりにも重大な失態が相次ぐ

  • 事件報道されるまでの5週間、事実を隠蔽し続けた
    2011年6月17日攻撃が始まっていたことを把握

    2011年7月19日以降、短期間に不正SSLサーバ証明書の発行・失効処理が繰り返されていたにも関わらず、根本的な対策を取らなかった
    2011年7月28日イランにおけるで不正SSLサーバ証明書の悪用を把握
    OSやブラウザベンダーにも通知をしなかった
    - 主要ブラウザベンダーの対処
    DigiNotar のルート証明書を削除
    - DigiNotar は破産手続き開始
    - 証明書を使うのを意識しないのはなぜ？
    実際にはブラウザやアプリケーションが自動検証する
    登録されている「信頼できる認証局証明書」をベースに判定
    設定次第でリアルタイム検証も可能
    最もリテラシの低い人にあわせるとこうなってしまう、という典型

以後オフレコ部分が多かったため、割愛します。
記述内容の間違い等がありましたら指摘頂けますと助かります。

Comments

comments powered by Disqus