WASForumに参加してきました

スコープを絞って考えたこと＋自分用振り返りメモ。
内容を把握するためにこれを読むのは勧めません。

TogetterのYahoo! JAPAN松岡さんのセッションに関する反応への反応

ログイン３兄弟

ちなみに、「ログインシール」だけアメリカ生まれ。

シールにセキュリティ効果はあるのか？

効果の定義がわからないが、「設定してたはずなのに出ないときに少しでも疑う」ことができるユーザーなら、あとはSSL証明書やURL見て何か気付くのでは？
少しでもリスクが減らすことができるならあってもいいんじゃないでしょうか。

シールはProxyされたら終わりか？

ブラウザ単位で、Cookieを利用しているようです。

「かんたんログイン」について

リスクがあることをしっかりと説明されて、素晴らしい講演だった
「これはダメ」だけではなく、「こうすべき」も提案されていた(Cookieによる実装)

知り合いの大先輩からのリモートつっこみでもあったように、この辺の話も今後聞きたいですね。

ケータイブラウザだとアドレスバーとか出なかったりして、フィッシングされやすいとか

「OAuth vs Basic認証 vs xAuth」

自分が今までたくさん調べてきたことでもあるので、あえて「上から目線」で補足していく。

Basic認証の何がいけないのか？

HTTPリクエスト中のAuthorizationヘッダの中身を戻して説明いただいた。わかりやすい。
はまちちゃんの例を出されていたが、ブラウザでBasic認証させるところは前はたしかに少しあった気もするが、
大半のアプリ開発者がユーザーのID/PWを入力させる理由は「バックエンドでBasic認証使ったAPIアクセスするためにもらう」が一番だと思う。
なので、「ID/PWを保存される可能性（＋その後いろいろされたときの可能性も含む）」がメインで、ログアウトできないってとこの説明はそれほどいらなかったのではないかと。

xAuth

twitterはBasic認証の代替として、ID/PWからAccessTokenを取得するエントリポイントを提供しはじめた。
開発者にとっては、めんどうなOAuthを実装しなくても、署名がんばるだけで（それが大変かもだけど）今までのUI、フローでユーザーの「ID/PW」を保存する必要がなくなる。
ただ、使ってるユーザーにとってはやはり「ID/PW」を保存されるリスクは残る。

ブラウザを立ちあげられないような端末の場合、OAuthで頑張ることもできます。ただし、かなり大変。
xAuthはそのあたりをターゲットにしていると思われるのでわかりやすいけど、あえてOAuthでやる場合の大変さを説明してほしかった。

OAuth セッション固定攻撃

OAuth1.0の仕様では、callback_urlの書き換えによりリスクが発生する可能性があった。
問題が露呈したタイミングでほぼ全てのSPがOAuth止めた。
1.0 + callback URL固定制限で再開したところ、Rev.Aと同時に再開したところなどあるが、今使うなら必ず1.0aで言いきってほしかった。

これ、前にブログ書いたっけ。。。？