こんばんは、ritouです。
1/14,15にJAPAN IDENTITY & CLOUD SUMMITが開催されました。
すでにレポートや取材記事、まとめ、まとめのまとめなどありますのでイベントを知らない方は見ていただければと思います。
IdM実験室: Japan Identity & Cloud Summit 2014のまとめのまとめ
2日間のうち、自分の出番の時間以外はなんとか一通り聞いてたつもりでしたが、関係者から「セキュリティ・トラック、ritou寝てただろ」と言われましたので、ノートPCを閉じ、スマホをポケットにしまい、椅子に座ってやや下を向きつつ目を閉じて静かに息をしながらID連携推しの立場として思ってたことを残しておきます。
セキュリティ・トラックの内容はこのあたりでわかるかと思います。
#JICS2014 #Sec Track - クレイジーダブルポケットフランネルチェックシャツ - Togetter
パスワード認証の現状に対するID連携の使いどころ
セキュリティ・トラック、モデレーターの方の肩書きが「OpenIDファウンデーション・ジャパン プロデューサー」でしたので、ところどころに「やはりID連携!OpenID!!」ってぶっこんでくれると期待していましたが、あんまりそっちの方向に話が膨らむことはなかった印象です。まぁ、とても魅力的な内容でしたけども。
まずは、「記事の続きを見るのに登録必要なのうざいときある、ID連携で良いのでは？」っていうあたりです。
辻さんもブログで触れられていましたね。
パスワード管理の観点からすると管理しなければいけないアカウントが増え
これも簡単なパスワード、使い回しを誘発する要因となると考えられます。そこで、言い方は悪いですが
「ユーザにとって価値の低いと考えられるアカウントだけを
ID連携でまとめてしまうというのもあってもいいのではないでしょうか？」という発言をしました。
http://n.pentest.jp/?p=31142
実現するかどうかは別にして以外と楽になるんじゃないかなって思います。
こういうところって、無料会員なんだけどやたらと属性情報ほしがりますよね。ものによっては、企業名とか入れる場所もあったりしますが、別に代表に電話かかってきて確認するようなことはないですね。本当に勤務先などの情報を欲しがっているなどの場合はエンプラ・トラックで少し紹介された企業アカウントの属性情報を外に出す話につながるのですが、現状求められている属性情報はそこまでではなさそうです。
とりあえず、どんなユーザーが見ているかを知りたいのであれば、OpenID ConnectのUserInfoを補完的に使いつつ、足りない属性情報を入力させてしきいを下げる感じにするだけでだいぶ使いやすくなるでしょう。
OpenID Connectでは「難しいことも簡単に」みたいな感じでかなりセンシティブなデータを扱うユースケースでも利用できるように設計されていますが、OpenIDの初期のユースケースってブログコメントとかの比較的ライトなユースケースでした。
私たちが「もうパスワード管理するのやめよう、ID連携で信頼できるところに任せよう」と言っても、「サービスの認証機能を全てIdPに預けるのは、そのIdPのアカウントに何かあったときとかいろいろ不安。」という声はもちろんあります。
では逆に、「コンテンツに対するコメントの部分だけ」「無料会員のところだけ」とID連携するスコープを狭めるのはどうでしょうか。「個別の機能では利便性重視で外部アカウントに任せてもいいところもある」という考えもあるんじゃないかと。
今回は後者の話で、スコープもリスクも限定したID連携の啓蒙というのも重要かもなーと思いました。
IDを持たないという選択について
こっちは前者のほうですね。
ディスカッションでは、MS Passportの失敗の話とかFBやTWのようにAPIありきじゃないと連携する気にならないみたいな話も出ていました。
まぁ、ユーザーセントリックなんつってOpenID 2.0が騒がれたときも本音は囲い込みが目的だろ？って感じでしたね。
今はOAuth + Profile APIなどで属性情報を提供するIdPは増えており、属性情報がもらえてUXがそこそこ悪くなければID連携するよって感じのサービスも少しずつ増えています。
昨今のパスワード認証してるところからの漏洩やリストを用いた不正ログインの状況は、ID連携を後押しするものだと思います。
ただし、ID連携をしたとしてもたどり着く課題は最後のリカバリーのところですし、リカバリーこそそのサービスの最終的な認証手段といえます。
ということで、ID連携しましょうって言いつつ、「ID連携しているRPが使える、”万能でもなくていいけど各サービスの特性に合わせたアカウントリカバリー方法”」についてもよく考えないとなーと思いました。
おまけ：「パスワードを覚えられない方はこちら」について
そんな中、１つの方法としてサービス提供側がユーザ登録時に強固なパスワードを発行して、それを使ってユーザはログインし、自分の好きなものに変更することはせず、再度ログインするときには再発行/リセットするといった「なんちゃってワンタイム」（実際には再発行/リセットするまで同じパスワードなのでワンタイムとは呼べませんが）的な運用を行なうという選択肢もあってもいいのかも？と思いました。
http://n.pentest.jp/?p=31142
もちろん、再発行/リセットを行うためのメールアカウントなどは死守する必要はありますが、記憶/記録しておかなければならないものが減りますし、サービス提供側が毎回強固でランダムなものを発行すれば
「複雑なパスワードを設定して、サービスごとに別々のものを設定して使い回しをしない。」
ということは満たされますし、リスト型攻撃などによる被害状況は改善されるのではないかと思います。
（追記：再発行とすると平文でパスワードがメールで届くことがイメージされるため、再発行から再発行/リセットとしました。）
私が「パスワードなんて覚えずに、毎回リセットかましてログイン状態になるユーザーがいるらしい」って話を聞いたのは2007年ごろだった気がします。
そのとき、似たようなことを考えていて、
- 普通に再設定したいユーザーはそのままさせればよい
- はなから覚える気がないユーザーには毎回ワンタイムなログイン用URLをメールで送りごにょごにょしたあとログインさせ、パスワードは"設定なし"という扱いにする
という2つの選択肢を用意しても良いのでは？という感じでした。辻さんがおっしゃられているようなユースケースを切り出しちゃうイメージです。
「メールを受け取ってログインするしかない」認識であればユーザーはがんばってメールアドレスをメンテするだろうし、その頃ちょうど「PC用とケータイ用の両方のメアドが必要」なんていうサービスが増えてきたときだったので複数必須にしとけばなんとかなるかなーとか思ってました。
これいきなりY!とかのサービスでいきなり使えるようにってのは難しいと思いますけど、世の中にあふれている生パスワード送信系リマインダーややたら短いパスワード文字数、文字種制限のあるログイン方式に比べたら有用な話だと思うので、気が向いたら実装のデモでも作って次のidconなどで披露したいと思います。そのときは是非、セキュリティな人に検証をお願いしたく。
とりあえずこんなところです。
「本当は寝てたけど、ブログ記事とtogetter見なおして今ぱっと思いついた」とかじゃないです。
エンプラとSAMLの話も書こうかと思ったけど別で書くかもしれません。
ではまた。
