タグ「認証」が付けられているエントリー

PHPでAXを喋るOPとRPを作る

| PHPでAXを喋るOPとRPを作る

ちょっと所用があるので,OpenID AXを喋るOPとRPを作ってみた.厳密に言えば,作ってみたではなく動かしてみたなのだが,ネット上に情報が少なすぎる,特にAXを喋るOPの情報が皆無に等しいので,とりあえず書き残しておく.実装はOpenID EnaledのPHP Library 2.1.3を使いました.PHPは5.3系で上手く動かなかったので,5.2.10でやってます.apacheは2.2.12で,OSはUbuntu9.10x64です.

AXを喋るRPの実装
まずはRP側を実装します.examples/consumerを用いれば,RPは簡単に作れます.しかも,サンプルにはSregとPAPEを喋るように作られています.まぁ,普通に動かせば動きます.んで,AXを喋るようにいくつか改変します.基本的にAXはSregやPAPEと同じExtensionなので,参考にしながら実装します.実装に当たっては,当然ながらドキュメントが役に立ちます.読みにくいですけどね.

まずはcommon.phpをいじります.AX関連のクラスを使いますので,doIncludes()の中で,require_once "Auth/OpenID/AX.php"しておきます.papeを参考にすると,ここらで定数などを宣言しているようなので,真似して宣言してみます.

global $ax_attributes;
$ax_attributes = array(
'http://axschema.org/contact/email' => 'email',
'http://axschema.org/namePerson/first' => 'firstname',
'http://axschema.org/namePerson/friendly' => 'nickname');

属性型はaxschema.orgにしました.別に他のでもいいです.次に,index.phpを変更しておきましょう.PAPEの部分を参考にします.というか,バッサリ頂きます.61-67行目を以下のように置き換えちゃいます.

<p>Optionally, request these attributes:</p>
<p>
<?php
global $ax_attributes;
while (list($key, $val) = each($ax_attributes)) {
print "<input type=\"checkbox\" name=\"ax_requests[]\" value=\"$key\" checked />";
print "$key ($val)<br/>";
}
?>
</p>

恐ろしく汚いコードですが,気にしたら負けです.これでIdentifierの入力を尋ねるときに,要求するAXを3種類の中から選べるようにしています.デフォでは全部ONですが. 続いて,try_auth.phpをいじります.まず,SregとPAPEは使わないので,該当部分をバッサリ捨てます.30-38行目がSregで,40-45行目がPAPEなので,コメントアウトするなり,消しちゃうなりして,機能しないようにしておきます.で,この辺りにAXのコードを書きます.

global $ax_attributes;
$ax = new Auth_OpenID_AX_FetchRequest;
$ax_uris = $_GET['ax_requests'];
while (list($key, $val) = each($ax_attributes)) {
if(in_array($key, $ax_uris)) {
$attribute[] = Auth_OpenID_AX_AttrInfo::make($key, 1, false, $val);
}
}
foreach($attribute as $attr){
$ax->add($attr);
}
$auth_request->addExtension($ax);

3行目の$_GET['ax_requests']はindex.phpのチェックボックスからどの属性がリクエストされたかを受け取っています.そんで,その要求されたものを$ax_attributesと比較して,Auth_OpenID_AX_AttrInfoでAXのリクエストにあうように準備します.ちなみに,第3パラメータをfalseにしているので,要求する属性はrequiredではなく,if_availableになります.そんで,$ax->add($attr)で属性セットして,最後にextensionに追加する感じです.このコードはExample usage of AX in PHP OpenIDを参考にしました. 最後に,finish_auth.phpを書き換えます.SregとPAPEを無効にしたいので,41-90行目をバッサリと消しちゃいます.かわりにAX用のコードを書き加えます.

$ax_resp = Auth_OpenID_AX_FetchResponse::fromSuccessResponse($response);
$success .= '<dl>';
global $ax_attributes;
while (list($key, $val) = each($ax_attributes)) {
$ax_data = $ax_resp->get($key);
if(!is_object($ax_data)) {
$success .= "<dt>$val</dt><dd>$ax_data[0]</dd>";
}
}
$success .= '</dl>';

特に解説することもないですけど,AXの返事は$ax_resp->get($key)で取り出しています.Type URIをキーにして,取り出しています.コードを見ればわかると思いますが,何を要求したとか,何が返ってきているかは全く考えず,総当たりにチェックしてます.大した量じゃないし.そのため,!is_object($ax_data)でエラートラップしてます.getメソッドで取り出せなかった場合,Auth_OpenID_AX_Errorが返りますので,objectかどうかのチェックでさばいてます.複数の属性値が返ってきた場合でも最初の1つしか表示しない辺りも詰めが甘いですが,気にしないで下さい.気になるなら,自分で工夫して下さい.僕には必要がないコードです.

AXを喋るOPの実装
続いて,OP側を作ります.examples/serverを使います.こっちが結構に四苦八苦でした.勝手にはまっただけですけど.こっちはいじくる部分はlib/common.phpだけです.まずはSregとPAPE関連を消し去ります.56-76行目がSregで,PAPEは・・・ないですねw.なんだ,OP側のPAPEは実装されていないのか.それはそれとして,Sregが書いてあった辺りに,AX用のコードを書き加えます.

$attributes = array(
'http://axschema.org/contact/email' => '[email protected]',
'http://axschema.org/namePerson/first' => 'first',
'http://axschema.org/namePerson/friendly' => 'nickname');

$ax_requested = Auth_OpenID_AX_FetchRequest::fromOpenIDRequest($info)->getExtensionArgs();
$ax_response = new Auth_OpenID_AX_FetchResponse();
while (list($key, $val) = each($attributes)) {
if(in_array($key, $ax_requested)) {
$ax_response->addValue($key, $val);
}
}
$ax_response->toMessage($response->fields);

実に,このコードにたどり着くまでに苦労しました.何にはまっていたかは後で説明します.コードは解説する必要がないくらいに簡単です.$attributes[]の中は連想配列でType URIをキーとして,属性値を格納します.んで,$ax_requestedと比較して,リクエストされている属性を$ax_response->addValue($key, $val)でセットします.以上で完成です.

動作例

100608_ax01.jpg

これはRP側です.http://localhost/rp/です.色々突っ込みどころ満載ですが,デモですからスルーして下さい.Identity URLのところに,自前OPのidentifierを入れます.AXで取得したい属性をチェックボックスから選びます.とりま,全選択で.

100608_ax02.jpg

こっちがOPからの返事を受け取ったRPです.要求した属性が全て取得できています.下の黄枠の中にはAXレスポンスの内容を表示してみました.aliasがext0とかになっています.ここで勝手にはまってました.結果的には,これで良かったんです.問題なく動いています.これで,AXを喋るOPとRPはできあがるので,後は煮るなり焼くなり・・・.

はまったところ
OPのレスポンスを作るのに苦労しました.というか,勝手な思い込みです.上記で示したOPのコードでAXを喋らせると,違和感があったんです.例えばこのエントリで例示されているように,ax.type.nicknameでリクエストしたら,レスポンスもax.type.nicknameとax.value.nicknameで返るのが自然のように思います.僕もそうだと思っていましたが,これは全然どうでもいい話でした.ここで例示したnicknameというのはaliasなのですが,aliasについては以下のように書かれています.

The <alias> will further be used to identify the attribute being exchanged.

Final: OpenID Attribute Exchange 1.0 - Final

とのことですので,identify出来ればよろしく,何だっていいようです.なので,ここではnicknameでリクエストしても,レスポンスはfriendlyでもいいわけです.問題なのはレスポンスにおいて,friendly.typeとfriendly.valueが紐付きますので,その関係だけが保たれていれば,aliasは何でもokです.

実際のところ,上記に示したOPが喋るAXはレスポンスとしてext0とかext1というaliasを張ります.最初はこれをみて正規の手続きでやっていないからまずいんだと思い込み,AX.phpやMessage.phpの中にまでダイブして,色々と調査しました.で,追っていけば行くほど,コードは正しそうに見えてくるんです.おかしいと思って確認してみたところ,さっきの例示したエントリでも,profile_imgでリクエストして,imageでレスポンスされている.つまりまとめると,重要なのはaliasではなく,Type URIである.aliasは一意ではない(そんな定めがない)が,Type URIは一意なので,そっちを見ろということである.なるほど当然の道理である.

まとめ:
PHPでAXを喋るOPとRPを実装した.簡易版なので,色々と不十分な実装(特にOP側)となっているが,実証コードには十分である.

201006081344追記:
Apache License 2.0らしいので,10はてブ超えたらソースコード公開する.

TwitterのBASIC認証が2010年6月末で終わり,OAuth/xAuthでの認証が必要になります.以前,xAuthに対応する話を書きましたが,最近になって,botの場合はxAuth申請をする必要がなくなったようです.手順は以下の通り.

まずは,アプリケーションの登録をします.アプリケーションの登録が完了すると,OAuthのConsumer keyとConsumer secretが手に入ります.

100505_twitter01.jpg

この2つの値をコピーしておきます.続いて,右のメニューからMy Access Tokenを選びます.

100505_twitter02.jpg

表示されるAccess TokenとAccess Token Secretをコピーします.準備完了です.あとは,PHPでテストコードを書いてみます.参考コードはウノウラボから.PECL::oauthを前提にしています.


<?php
$consumerKey = '
Consumer key';
$consumerSecret = '
Consumer secret';
$oauthToken = 'OAuth token';
$oauthTokenSecret = 'OAuth token secret';
$oAuthStatusesUpdateUrl = 'http://api.twitter.com/1/statuses/update.xml';

$response = '';
$parameters = array(
'status' => 'OAuthから投稿テスト♪',
);

try {
$oauth = new OAuth($consumerKey, $consumerSecret,
OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_URI);
$oauth->setToken($oauthToken, $oauthTokenSecret);
$oauth->fetch($oAuthStatusesUpdateUrl, $parameters, OAUTH_HTTP_METHOD_POST);
$response = $oauth->getLastResponse();
} catch (OAuthException $e) {
var_dump($e);
exit;
}
var_dump($response);
?>

上記コードの4カ所に先ほどコピーした各値をセットすればokです.簡単ねっ!

関連:
TwitterでxAuthを使う試み - 4403 is written

IMG_1322.JPG

3月12日に一橋記念講堂で行われたUPKIシンポジウム2010に途中から参加してきた.終日参加する予定で申し込んだのだが,のっぴきならぬ予定が入ってしまい,行くのを諦めていたところ,想像以上に早く戻ってくることができたので,パネルディスカッションから聴講しに行ってきた.なお,今回もeduroamの無線LANが解放されていて,トライアルアカウントを利用できるようになっていました.こういう試みっていいよね.啓蒙活動として.

ところで,今回大変に気になったことがある.撮影・録音禁止と書かれていた.ちゃんとした機材で撮影している係の人がいたのだが,別にustされているわけでも,オンデマンド配信されているわけでもなく,なんだったんだろう?さらによく分からないのが,#upki10というハッシュタグを推奨していた.

IMG_1323.JPG

こんな感じで休憩中は大スクリーンに表示されていたが,何をしたかったのだろう?撮影・録音禁止だとすれば,tsudaりもなんとなく禁止っぽそうな気がするし,なんといっても映像配信されていないから,外部の人と情報共有しようと試みること自体が無駄に思える.ただ単にTwitterを使ってみたかっただけなのだろうか?推奨ハッシュタグを準備するなら少なくともtsudaれる状況は準備して欲しい.

さて,シンポジウムの話に戻すと,佐賀大学が超がんばっているということが感じ取られたパネルだった.学内統合認証ってのは大阪のどこかの大学もやっていたけど,佐賀大のはUPKIに乗っ取って,かつ学内業務のほとんどをシボレスで統合したという試みらしい.しかも,段階的にではなく,一気に.チャレンジングだと思う.しかもNIIへの提言として「私たちの失敗を見て下さい.身を以て試しますから」と言ってしまう辺りが,素晴らしくかっこいい.実際はそんなに失敗してないのに・・・.

あと,シボレスの普及が進んでいるみたい.MicrosoftのDreamSparkがシボレス対応でUPKIと接続できるみたいなことを説明していた.うちの大学もそういうのやらないかなぁ・・・.Elsevier,Springer,CiNiiを自宅から使えるようになるから便利なんだけどなぁ・・・.学内IP帯からのアクセスしか許可してないから,VPN必須で面倒だし・・・.電子認証は信用されていないんですね.わかりません.

まとめ:
うちの大学もUPKIに対応しないかなぁ・・・.てか,次のポストはUPKIに参画している(もしくは参画可能な)機関から探すというのも1つの考え方ですね.

なにやら2010年6月頃に従来使われていたBASIC認証でのAPIコールができなくなるらしく,OAuthまたはxAuthへの対応が必要となっております.ぶっちゃけ,作っているのはbotなので,OAuthのような仰々しい実装(ぇ)は必要ないので,簡易的なxAuthを用いようと考えました.なお,OAuth対応を行うと60分に350回(将来的には1500回)のAPIコールができるようになるらしい.これはかなり自由度が増します.というわけで,今回はxAuthに対応する話を書いておきます.例によって,実装はPHPです.

参考にしたのはこちら.というか,そのまんまです.OAuth/xAuthを使うには準備が必要です.手順は以下の通り.

準備: アプリケーションを Twitter に登録し、consumer key と consumer secret を取得する
      http://twitter.com/oauth_clients/new にアクセスし、登録する

・Webアプリケーションの場合
  (1) consumer key と consumer secret を使って、リクエストトークン(token と token secret)を取得する
  (2) リクエストトークンのうち、token を使って、ユーザにアクセス許可を求めるための URL を生成し、その URL にリダイレクトする(Web ブラウザに表示させる)
  (3) ブラウザに表示された「許可(allow)」ボタンをユーザが押すと、(アプリケーション登録時に申請した)コールバック URL にリダイレクトされる
  (4) コールバック URL へのアクセスを検知したら、その URL 中に含まれる oauth_verifier パラメータを取り出す
  (5) consumer key, consumer secret, token, token secret, oauth_verifier を使って、アクセストークン(token2 と token2 secret)を取得する
  (6) 以後、consumer key, consumer secret, token2, token2 secret を使って、API を実行する

Twitter API 仕様書 日本語訳 第四十八版 (2010年3月2日版)

簡単ですね.え?まぁまぁ.まずは,http://twitter.com/oauth_clients/newにアクセスして,OAuthを使うアプリケーションを登録します.登録が完了すると以下のような画面が出ます.

100304_xauth01.png

Consumer keyとConsumer secretが表示されるので記録します.で,ウノウラボを参考に以下のようなコードを実行して,アクセストークンを取得してみます.


<?php
$consumerKey = 'Consumer key';
$consumerSecret = 'Consumer secret';
$username = "username";
$password = "password";
$xAuthAccessTokenUrl = 'https://api.twitter.com/oauth/access_token';

$response = '';
$parameters = array(
'x_auth_mode' => 'client_auth',
'x_auth_username' => $username,
'x_auth_password' => $password,
);

try {
$oauth = new OAuth($consumerKey, $consumerSecret,
OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_URI);
$oauth->fetch($xAuthAccessTokenUrl, $parameters, OAUTH_HTTP_METHOD_POST);
$response = $oauth->getLastResponse();
} catch (OAuthException $e) {
var_dump($e);
exit;
}
parse_str($response, $accessTokenInfo);
var_dump($accessTokenInfo);
?>

ウノウラボ Unoh Labs: PECL::oauthでxAuthを参考に一部改変

これを実行すればアクセストークンが取得できるはずです.結果を以下に一部抜粋.


object(OAuthException)#2 (7) {
["message:protected"]=>
string(73) "Invalid auth/bad request (got a 401, expected HTTP/1.1 20X or a redirect)"
(中略)
["lastResponse"]=>
(中略)
<error>Client application is not permitted to use xAuth.</error>
}

おやおや?芳しくないですね.401エラーでxAuthの許可がないと言われています.うーん.ドキュメントを読んでみると,こう書いてあります.

In order to get access to this method, you must apply by sending an email to [email protected] -- all other applications will receive a HTTP 401 error.

Twitter API Wiki / Twitter REST API Method: oauth access_token for xAuth

よく読めという話である.つまりは,xAuthを行うにはOAuthのアプリケーション登録をするだけではダメで,メールでの申請がさらに必要とのこと.なるなる.なので,早速メールで申請を行います.・・・って,Twitterって日本語が通じないような気がしますよね?というわけで,どのような文面を書けばよいか.以下をパクりました.

Hello.

I'm a developer of '[Your application]', the twitter client application for windows.
My account is @[Your twitter account].
Please apply this app to use xAuth.

Application: [Your application]

Best regards.
-----------------------------------------------
@[Your twitter account]
[some urls]

xauth request - 3d7b1

簡単ね!これに対するお返事が2日後に来ました.結果は許可ならず.要約すると「おまえbotだろ?なんでxAuthつかうん?もっと説明せーや!」とのこと.ううう・・・.アプリ名を「factoring_bot」にしたのがいかんかったか・・・.確かに,OAuthでやれと言われれば,グーの音もでない.「xAuthを使ってみたいんだよ!」って本音を書きたくなったけど,そこはグッとこらえて,高度な言い訳を.そして更に2日後に「プラットフォームはなに?Windowsでいいのけ?」ってお返事が.ここはクールに「あぁ,最初はWindowsだ.その次はLinux対応だね」って送り返しました.マルチプラットフォームでプログラムを書ける好青年を演じておきました.で,最終的には,コンタクトを始めてから1週間後に以下のメールが来ました.

Your application now has the ability to use XAuth,

おお!!やっと許可されました.粘り強く交渉してみるもんだ.では,先ほど401エラーが返されたプログラムを実行してみましょう.


array(5) {
["oauth_token"]=>
string(50) "oauth_token"
["oauth_token_secret"]=>
string(41) "oauth_token_secret"
["user_id"]=>
string(9) "101753216"
["screen_name"]=>
string(13) "factoring_bot"
["x_auth_expires"]=>
string(1) "0"
}

完璧です.実際にはoauth_tokenとoauth_token_secretには何やらの値が格納されています.ここで見せちゃうとダメだからね^^.ではでは,xAuthを利用してつぶやきをポストしてみましょう.以下のコードを走らせてみます.もちろん,参考コードはウノウラボから.


<?php
$consumerKey = '
Consumer key';
$consumerSecret = '
Consumer secret';
$oauthToken = 'OAuth token';
$oauthTokenSecret = 'OAuth token secret';
$oAuthStatusesUpdateUrl = 'http://api.twitter.com/1/statuses/update.xml';

$response = '';
$parameters = array(
'status' => 'xAuthから投稿テスト♪',
);

try {
$oauth = new OAuth($consumerKey, $consumerSecret,
OAUTH_SIG_METHOD_HMACSHA1, OAUTH_AUTH_TYPE_URI);
$oauth->setToken($oauthToken, $oauthTokenSecret);
$oauth->fetch($oAuthStatusesUpdateUrl, $parameters, OAUTH_HTTP_METHOD_POST);
$response = $oauth->getLastResponse();
} catch (OAuthException $e) {
var_dump($e);
exit;
}
var_dump($response);
?>

で.結果がこちら.

Twitter / 素因数分解ボット「ふぁくたん」: xAuthから投稿テスト♪

アプリ名としてfactoring_botって表示されるのがかっこいい!クール!クール!!クール!!!

まとめ:
TwitterのxAuthはOAuthのライブラリを使って実装可能.xAuthはOAuthのアプリ登録をするだけではダメで,xAuth利用申請をメールで送る必要がある.その際,アプリ名にbotが含まれていると疑われる.というか,最初から自分のアプリを詳細に説明しておけば良いんだと思う.実装のプラットフォームも尋ねられたので,書いておくと良いと思う.実装言語は訊かれなかったけど,アグレッシブに主張した.

OAuth/xAuth採用によって,API制限が少し緩和されるはず.いや,まだfactoring_botにこのテストコードを移植してないけどさ. そのうちにやります.そのうちに・・・.

Sig-japanとcsec-newsに流れてきたので,思い切って転載.

【タイトル】カンターラ・イニシアティブ発足記念セミナー
~アイデンティティ管理技術とビジネス活用事例~
【日 時】7月14日(火) 14:00~17:00 (受付 13:30~)
【場 所】日本オラクル株式会社 オラクル青山センター
http://www.oracle.co.jp/aoyamacenter/
【主 催】カンターラ・イニシアティブ ジャパン・ワークグループ
【後 援】リバティ・アライアンス 日本SIG
【参 加 費】無料(事前登録制)
【内 容】

1. カンターラ・イニシアティブ概要説明
2. 分科会における取組み事例
3. カンターラに集う技術事例
- Liberty/SAML 事例紹介
「SAML認証によるGoogle Appsの認証連携事例の紹介」
サイオステクノロジー株式会社
国内事業ユニット クラウドインテグレーション
ゼネラルマネージャー 博士(理学)
中田 寿穂 (なかた ひさほ) 様
- OpenID 事例紹介
「NTTComにおけるOpenID活用の取組み」
NTTコミュニケーションズ株式会社
ネットビジネス事業本部 OCNサービス部
北村 和広 (きたむら かずひろ) 様
- Information Card 事例紹介
「Information Card と Windows CardSpace のご紹介」
マイクロソフト株式会社
デベロッパー&プラットフォーム統括本部
田辺 茂也 (たなべ しげや) 様

参加予定ですので,見かけたら声をかけて下さい.呑みに行きましょう.

Federica Paci, Rodolfo Ferrini, Andrea Musci, Kevin Steuer Jr., Elisa Bertino, "An Interoperable Approach to Multifactor Identity Verification," Computer, vol. 42, no. 5, pp. 50-57, May 2009, doi:10.1109/MC.2009.142

今日届いたIEEE CSのComputerに載ってます.オレのやらんとしていることに近すぎてワロスワロス.方向性は間違っていないということで,喜んでみます.

SSLの話がさっぱりわからない.以下,引用.

ショップは暗号化の鍵を認証局に預ける.認証局は預かった鍵を認証局の鍵で暗号化して返却.ショップは認証局で暗号化された鍵を客に渡す.客は認証局の鍵を入手暗号を解読しショップの鍵を入手.客はショップの鍵でクレジット番号を暗号化,買い物を始める.

おかしいと思う部分を強調してみた.何週間か前に公開鍵暗号の話をやったばっかりなのに,もう忘れてしまったのか・・・.参考サイトに挙げられている総務省の説明と違うのが気になるなぁ.どっちが間違っているんだろう.わからない.

もしショップが偽物だとしたら,認証局の鍵が使えないことで見破れます.

そうなのかぁ・・・.それって,ショップが偽物というか,認証局が偽物なのでは?

その後は,SSLの認証手続きの話をしてまして,実在証明の話をしていましたが,世の中には実在証明なしのSSL証明書が山ほどあるので,SSL証明書があれば必ず実在証明がついているかのような説明では,警告が出ない正規のSSL証明書を使った悪意あるサーバに,フィッシングやらなにやらされてしまいそうで怖いです.

証明書に期限がある理由は定期的に証明書(秘密鍵)を変更することによって、悪意を持った攻撃者からの総当たり攻撃を防ぐためです。

NHK: IT whitebox

そうだったのか!証明書の中身は秘密鍵だったのか!!

まとめ:
嘘を嘘と見抜けない人がネットショップで買い物するのは難しい.もうちょっと真面目に調べて番組にするか,もっと抽象的にして誤魔化すかをした方がいいと思います.ITのブラックボックスがホワイトボックスではなく,NHKカラーボックスになってしまいますので.ちなみに,森下千里写真集は今現在で残り3冊なので,買う人は早めに.

関連:
ITホワイトボックス第3回「メールは盗み見られないのか?」 - 4403 is written
[IT whitebox]ブログ特集 - 4403 is written
SSLサーバ証明書購入奮闘記 - 4403 is written
SSL証明書の件いろいろ - 4403 is written
用途別SSLサーバ証明書を勝手にまとめ - 4403 is written

名称変更にともない、Product Advertising API にリクエストを送信いただく都度、認証のための電子署名を含めていただくことが必要になります。この変更は、2009年5月11日より3ヶ月の間の移行期 間の後、2009年8月15日には、Product Advertising API へ送信されるリクエストは全て認証されることとなり、認証されない場合、リクエストは処理されなくなります。

Amazon アソシエイト・プログラム(アフィリエイト) 公式ブログ: Amazon アソシエイト Web サービスの名称変更および署名認証についてのお知らせ

だそうです.まぁ,使ってないので関係ないですけど.REST的にはHMAC-SHAですよね.そんな理由で,WAISの発表の署名部分はHMAC-SHA256を採用していたんですけど,座長に「非対称オススメ」って言われちゃったので,うん・・・.英語力がないから言い返せない辺り,弱い.研究的な話でいけば,確かにPKI上でやるんだろうし,RSA-SHA256とかでいいかもしれない.いいかもしれなくないのは,URL長の問題だけど,これはRFC2616的には規定がない.RFCに規定がないからって制限がないわけでもないわけで,理論上は大丈夫とか,モダンブラウザでは大丈夫とか,そんな次元.個人的には携帯のブラウザでも大丈夫なように,HMAC-SHA256くらいの長さが関の山だと思うのです.RSA-SHA256は長すぎです.REST的に気分イクナイ!楕円曲線上の離散対数問題が云々だから,160bitって言えばいいのかな?簡単に実装できなさそうだから言いたくないけど.

と,今書いている論文の愚痴をこぼしても〆切が延びるわけでも,時間が増えるわけでも,執筆速度が上がるわけでも,なんでもないので,さっさと大人しく書けと,オレはオレに言いたい.

さて,タイトルと内容が不一致になっているので,HMAC-SHA256を実装する時の話をチラッと書いて,お茶を濁しておく.PHPでHMAC-SHA256する話.非常に簡単だから,良かったね.

algo
選択したアルゴリズムの名前 (すなわち "md5"、"sha256"、"haval160,4" など…)。

PHP: hash_hmac - Manual

さて,眠いので寝ると見せかけて,3章を仕上げる.

関連:
[を] アマゾンAPIを使うのに2009年8月15日から認証が必要になるらしい

200905102316追記:
PHPでこれら云々を簡単にやるPEARがあるようだ.Services_Amazonっていうらしい.便利な世の中です.なお,Perlの場合はdankogai氏作成のURI::Amazon::APAが使えるっぽい.良い世の中だ.なお,Rubyの場合はここが参考になるかと.

200905110122追記:
各言語用のまとめがありました.PHP,Perl,Ruby,Pythonがあります.Javaとか,JavaScriptとかはないですね.てか,みんなは一体なんの言語で書いているんだろう?オレなら,PHPかPerlですね.Rubyもいいなぁ・・・.

200905111052追記:
むしゃくしゃしてサンプルを書いてみた@PHP.

<?php
$key = '1234567890';
$req = array(
'AWSAccessKeyId=00000000000000000000',
'ItemId=0679722769',
'Operation=ItemLookup',
'ResponseGroup=ItemAttributes%2COffers%2CImages%2CReviews',
'Service=AWSECommerceService',
'Timestamp=2009-01-01T12%3A00%3A00Z',
'Version=2009-01-06');
$req = join('&', $req);
$message = array('GET', 'webservices.amazon.com', '/onca/xml', $req);
$message = join("\n", $message);
$hash = hash_hmac('sha256', $message, $key, 'true');
echo base64_encode($hash);
?>

みずほ銀行九段支店のフロアマンはダメだと思った.

みずほマイレージクラブカードを新しいものに変えたので,生体認証情報を再登録しにいった.どこにいけばいいのかわからないし,調べる気もさらさらないので,フロアマンにこう訪ねた.「指静脈の登録をしたいんですが」って.そしたら,なんて返ってきたと思うよ.「えーあー.指紋認証ですか?生体認証のことですよね?」って.「あの読み取り機で指紋が読み取れるんですか!?最先端過ぎですねっ!」って皮肉っても良かったけど,通じないだろうから,諦めて「はぁ,それでもいいですけど」って言ってみた.自行のサービスを知らない,しかも間違えている,さらに言えば客の言ったことを否定までしている時点で,偽銀行員だよね.フロアマンなんだから,どうにかした方がいいと思う.

関連:
みずほ銀行:生体認証(指静脈認証)機能

2009年2月23日に,NIIの一橋記念講堂で開催されたUPKIシンポジウム2009に参加してきた.シンポジウムは10:40からやっていたのだが,午前中は学校に行く用事があったので,午後の第2部から出席しました.配布された講演資料集がちゃんとした簡易製本になっていて,しかも印刷がテカテカインクで,テラカッコヨス.参加費無料とか,太っ腹すぎます!お土産のUPKIポストイットも活用させていただきます!

さて,参加したからには参加報告をするわけですが,話の内容的にオフレコっぽいのがあったわけですが・・・.資料が公開されるかどうかもよくわからないので,資料を引用しない形で,雑感を述べていきます.資料が公開されたら,詳細なレポートを追記します.たぶん.

特別講演:「インターネット事業を取り巻く環境と展望」
当然ながら,ビッグローブの宣伝からスタート.「残念ながら」苦労をされているようです.話の内容はUPKIではなく,ISPからみたインターネットとその先いろいろという感じ.y or nの広告について述べていて,「ちょwそのnは違うn」って突っ込みたかった.いや,わかってたけど.

飯塚社長のご講演を聴講するのは,これで2回目(初めては去年のNICTシンポ)なわけだが,特段真新しい話はないのに,とても面白い.ISPならではの視点に基づく発言がワクワクする.過激すぎて,書くとまずそうな気がするので,資料が公開されたら・・・.個人的には同意します.

認証を用いた情報セキュリティ対策
情報セキュリティポリシを策定する際のサンプル規定集について.プロジェクトはこれでいいのかな?

電子証明書の意義とサーバ証明書新プロジェクトの計画
ざっくばらんに誤解を恐れずに言えば,オレオレ証明書はダメだっていう話.概要を直感で伝えるとすれば,概ね間違っていないと思う.オレオレ証明書はダメだから,オープンドメイン認証局から発行された,要はUPKIの証明書を使っていこうという内容.それから,今後の展望も.UPKIの証明書を使ったとしても,運用次第では第五種や第六種のオレオレ証明書になり得る.その際たる例が携帯電話で,古い携帯の対応に問題があることは,WASFでも語られていた

Shibbolethを用いたフェデレーション構築計画
Shibboleth(シボレスって読むらしいよ!)のフェデレーションとUPKI-Fedについて.外国人の方で通訳付きでしたが,非常に聞き取りやすい英語で日本人に優しい!Libertyの資料はよく見かけるけど,Shibbolethの資料は見たことがないなぁ・・・.集めてみようかなっと.プロジェクトはこちら

認証基盤を活用したコンテンツサービスの展開
SSOってこんなにすごいんだ!ってのを,UPKI方面ではない人向け(むしろSSOを知らない人向け?)に実演を交えて啓蒙.インパクトがあって面白かった.個人的には,実演を見る限り,あのSSOは使いにくいと思った.機会があれば,書きます.

パネルディスカッション
資料が出ないと書き辛いので,今は書きません.

まとめ:
事前の予想を上回る面白さでした.特段に真新しい情報はなかったけど,情報を整理できたから収穫はあったかと.UPKI使いたいなぁ・・・とSINET外から言ってみるテスト.

200902240104追記:
昼飯に食べた小学館地下にある七條のミックスフライ,1300円です.

CA391616.JPG

開店直後の11:30ちょい過ぎに行ったのに,ほぼ満席で,店から出たら大行列でした.凄い店だ.

200903022314追記:
資料が公開されていました.資料を確認した後,追記します.

ホッテントリメーカで77usersです.ちょっとメールのセキュリティについて,軽く説明してみようかと思います.ちなみに,spamメールについては一切触れる予定はありませんので,あしからず.

パスワードを守るAPOP
メールを受信するためのプロトコルとして,POP3があります.POP3とはPost Office Protocol version 3の略でして,メールサーバからメールを取り出すためのプロトコルです.メールを取り出すプロトコルですので,誰でも彼でも使えてしまっては,自分宛のメールを他人に読まれてしまいます.そのため,メールを取り出す際の認証が必要になる.しかしながら,POP3は認証時のパスワード暗号化を提供しません.これはつまり,パスワードが平文で流れることを意味します.HTTPでいうところの,Basic認証に相当します.そのため,通信路上で盗聴が行われるとパスワードはばれてしまいます.これは結構イヤな感じです.イヤな感じですが,HTTPではBasic認証が未だに用いられていることを考えれば,大した差はないといえば無いような気がしますが・・・.

さて,そんなパスワードが平文で流れてしますPOP3の認証を安全にするプロトコルがAPOPです.APOPについては杜撰な研究者さんが書かれているので,まま引用.

APOP とはAuthenticated POP のことで、POP のようにパスワードを生でやりとりするのではなく、APOPサーバから送られたチャレンジ(乱数)に対し、ユーザはチャレンジとパスワードの連接のハッ シュ値をサーバに送り返すことで、安全なパスワード認証を実現しています(ただしメイル本文は平文のままです)。

杜撰な研究者の日記: APOP

ここで説明されているとおりです.つまり,HTTPでいうところのDigest認証に相当します. APOPによって,パスワードが平文で流れることがなくなることはお分かり頂けると思います.これで安心!ではないんです.昔はこれで安全だったんですが,APOPに用いられているハッシュ関数であるMD5の危殆化によってパスワードが復元されるという攻撃を受けてしまいます.このAPOP上におけるMD5コリジョン攻撃はLeurentやSasakiらによって,ほぼ同時期に行われているという話も,杜撰な研究者さんが詳しくされているので,繰り返しません.この問題に対して,2007年の話になりますが,IPAは以下のような注意喚起を行っています.

独立行政法人 情報処理推進機構(略称:IPA、理事長:藤原武平太)は、メールの受信に利用される認証方式の一つであるAPOP(エーポップ)方式におけるセキュリティ上の弱点(脆弱性)に関する注意喚起を2007年4月19日に公表しました。

(中略)

プロトコル(通信手順)上の問題であり、現時点で根本的な対策方法はありません。

回避方法は「『POP over SSL』や『ウェブメール』など、SSLによる暗号化通信を利用する」ことです。回避方法が取れない場合「メールのパスワードを他のシステムのパスワードと同一にしない」ことで悪用された際の被害を軽減できます。

情報処理推進機構:情報セキュリティ:脆弱性関連情報取扱い:APOP方式におけるセキュリティ上の弱点(脆弱性)の注意喚起について

ということで,APOPはパスワードを通信路上に平文で流すことなく認証が可能なプロトコルですが,ハッシュ関数の危殆化によって,その安全性に問題が発生したのでした.

通信路ごと暗号化してしまえPOP over SSL
そこで,次の話です.IPAでも回避方法としてあげている,over SSLです.これは簡単で,POPをSSL化してしまえ,えいや!というものです.これをPOP over SSLといいます.POPSと呼ばれることもありますが,一般的かどうか・・・.これはHTTPでいうところのHTTPSに相当します.これは最早,SSLで通信路が暗号化されますので,パスワードが平文で流れる云々もなにも,メール本文すらも暗号化されて通信路を流れます.当然,SSLの安全性に依存します.POP3やAPOPに比べて,POP over SSLが如何に安全になるかは,@ITの表がわかりやすいと思います.これで,通信路上での盗聴の問題は解決しました.

とは問屋が卸さない.やはり同様にして,MD5コリジョン攻撃の問題がやってきました.先日書いた,MD5なSSL証明書の問題です.SSL証明書の問題は残りますが,これは別に,POP over SSLに特化した話ではなく,SSL全般の話なので,詳しくは触れません.そういうことがあるという話だけ.

ちなみに,IPAの回避方法でも述べられていますが,案外Webメールは安全です.通信路がSSLで暗号化されている的な意味で.GmailならHTTPSで接続されると思います.注意しないとHTTPで通信してたりするけど.素のPOP3やAPOPを使うくらいなら,HTTPSなWebメールの方がいいかもしれません.HotmailとYahooメールはSSLにならないなぁ・・・.優しくないなぁ・・・.

こうしてメールのセキュリティは確保されました?
これで,クライアント-サーバ間の通信路の安全性は守れられました.パスワードも安全そうです.良かった良かった.で終わらないから,このエントリを書いているんです.では,どこがダメなのでしょうか?クライアント-サーバ間が安全になったにも関わらず・・・.

そうです.サーバ-サーバ間の通信が安全ではありません.もっと言えば,サーバが安全ではないかもしれません.そうです.APOPでパスワードの安全性は確保されますが,メール本文の暗号化はされません.POP over SSLは通信路上において,メール本文も暗号化されていますが,メールサーバ上では暗号化されていません.これは何を意味するかと言えば,サーバ-サーバ間の通信においては,メール本文が平文で流れていること,そして中継に利用されたメールサーバはメール本文を平文で見ているという点です.厳密には,普通のテキストが流れているわけではなく,BASE64などのエンコードがかかった状態で流れていますが,符号化は暗号化ではないので,平文と考えて問題がありません.

つまり,メール本文は暗号化しない限り,平文で流れます.メール本文は暗号化しない限り,平文で流れます.重要なことなので,2回書きました.

メールを暗号化するPGPとS/MIME
メール本文を暗号化しない限り,安全にならないのであれば,暗号化すれば良いんだ.簡単なことです.そのソリューションを提供するのが,PGPS/MIMEです.PGPはPretty Good Privacyの略で,公開鍵暗号方式を用いていますが,Web of Trustと呼ばれる仕組みによって,信頼を得る方式になっています.対して,S/MIMEはSecure/MIMEの略で,公開鍵基盤(PKI)アプリケーションです.この2つの方式の大きな差は,公開鍵の信頼性をどのように保証(確認)するかという違いです.この2方式の差も,今回書きたいこととは直接関係がないので,詳解は避けます.

結論だけ言いますと,PGPやS/MIMEを利用することで,メールを暗号化することができます.それだけではなく,ディジタル署名を付けることもできます.これによって,盗聴の脅威を防ぐだけではなく,メール本文の改ざんを防ぐこともできますし,送信者の否認を防止することができます.こうして,メールは安全になりました.

はて?あなたは今までに1度でも,PGPやS/MIMEによって暗号化されたメールを受け取ったことがありますか?無いのではないでしょうか.ボクは学生時代に「試して見たがり衝動」で,PGP暗号化/署名を試しています.S/MIMEも第四種オレオレで良ければ,院生時代に試しています.でも,それだけです.「試してみた」レベルです.何故,このようなセキュリティソリューションが利用されないのでしょうか?300字以内で答えなさい(配点:70).

ちなみに,電子メールに署名を付ける人は少なからずいます.これはメール送信者のセキュリティ意識の高さを示していると言えるでしょう.しかしながら,何故かそのような人においても,暗号化されたメールは送ってきません.何故なのでしょうか?200字以内で答えなさい(配点:30).

ちなみに,MUFGのメールにはS/MIMEの署名がついていますGmail S/MIMEというFx用のアドオンを導入すると,簡易的ながらGmail上で署名を検証できます.

090222_smime01.png

まとめ:
POP3ではパスワードが平文で流れます.APOPはそれを防ぎますが,安全ではなくなりました.POP over SSLはクライアント-サーバ間の通信をSSLによって暗号化するので,安全です.しかしながら,クライアント-サーバ間以外の通信に保証がないので,暗号化されていないメールは中継中に盗聴可能です.そのため,PGPやS/MIMEでメールを暗号化すると良いです.

何が書きたかったかっていうと,2点です.内部ではPOP3でメールが運用されています.外部からはVPN接続しないとダメなので,このネットワーク構成は安全です.っていうのは,安全ではありません.敵は外からのみ来るのではなく,内部にも存在し得ます.逆内弁慶はセキュリティ上,安全ではありません.

もう1点はGmailを否応なしに毛嫌いする人です.Googleは個人情報を集めまくっている.きっとメールも覗かれているに違いない.その証拠にメールの内容に合った広告が出るじゃないか!という主張.これ自体はその通りでしょうが,だったら平文でメールを流さないで下さいといいたい.Gmailを使わないとしても,中継サーバがメールの中身を見ていないとは限らない.Gmailだからというのはリスクの差を生みません.

某所で運用しているサーバの話なんですが、割と"SSH Brute Force Attack"がヒドく、対策を行わないといけないんですが、せっかくなので、攻撃者がどんなユーザ名でログインを試みているかの統計を取ってみました。

SSH総当り攻撃(Brute Force Attack)の傾向から利用を避けたいユーザ名 - RX-7乗りの適当な日々

おもしろそうなので,便乗してみる.某所のサーバからです.

# cat /var/log/secure* | grep 'Invalid' | awk '{print $8}' |
sort | uniq -c | sort -nr | head -n 100
1306 test
723 admin
666 a
376 guest
363 user
332 oracle
255 tester
207 postgres
171 testing
169 webmaster
163 testuser
157 123456
155 ftpuser
151 student
138 info
132 test1
129 temp
126 alex
117 123
115 12345
108 web
106 administrator
104 qwerty
98 test2
98 test123
97 sales
97 john
95 tomcat
94 dan
94 1234
93 testftp
90 adam
89 paul
88 zxcvb
88 sarah
86 richard
85 tests
85 nagios
84 robert
83 webadmin
82 matt
80 master
80 fax
80 demo
78 user1
78 patrick
78 frank
78 eric
76 toor
76 david
76 backup
75 abc
71 www
71 support
71 kevin
70 amanda
69 mike
68 michael
67 adrian
66 stephen
65 office
64 steven
63 james
62 wwwrun
61 irc
61 andy
61 abcde
61 abcd
60 victor
60 jack
59 lisa
59 larry
58 public
58 max
57 service
57 martin
56 peter
56 dave
55 jacob
55 carol
54 test3
54 scott
54 sandy
53 upload
53 tony
53 louise
53 linda
52 shell
52 maria
52 library
52 jessica
51 ben
50 brian
49 students
49 linux
49 client
49 bill
48 victoria
48 mailtest
48 cyrus

なるほどなるほど.こういうユーザ名をログイン可能にしておいてはいけないんですね.わかりました.ちなみに,現所属サーバだとsshに制限をかけているので,情報が少ない・・・.

# cat auth* |grep 'Invalid' |awk '{print $8}' |sort |uniq -c |sort -nr
1 toor
1 test
1 staff
1 spd
1 oracle1
1 master
1 admin

効果はあるようだ.

まとめ:
sshは公開鍵認証で.

本家のストーリにもなっているが、認証局として知られる「Comodo」のアウトソース先の証明書販売業者が、mozilla.com用のサーバ証明書を関係のない第三者に発行してしまう事件が発生したようだ(eWeekの記事「SSL Certificate Vendor Sells Mozilla.com Cert to Some Guy」、mozilla.dev.tech.cryptoグループに掲載されている事件の経緯)。

スラッシュドット・ジャパン | Comodo CAがサーバ証明書を関係のない第三者に発行、大問題に

ボソッとつぶやく.

PKIの信頼って,いうところのTTPって,何を誰がどうやって信頼しているのだろうか.一般人はわかっているのだろうか.ブラウザがSSL証明書に警告を出さなければ信頼できる?それはTTPを信頼しているの?あなたはverisignを知っていますか?comodoを知っていますか?

もしかして,一般人にとってのPKIって,トラストアンカーはTTPである認証局になんか向いてなくて,ブラウザなんじゃ・・・.ブラウザが「うん」といえば「うん」なのか.PKIが一般的に普及しないのはこういう理由からなのだろうか.

そろそろファイナルにしたいっす.回線が開通したので,接続テストやらなんやらやってたら,起動しなくなりました(ぇ.いや,まぁ,事なきを得たんですが,ヒヤリでした.

で.予想通りトラブルに見舞われています.全く理解できません.

svn+sshできない
できないというのは嘘で,できるんだけど,できない.できる状況は以下の通り.

  • サーバ内から,svn+ssh://ループバック/
  • サーバ内から,svn+ssh://外部IPアドレス/
  • サーバ内から,svn+ssh://FQDN/
  • 研究室内回線から,svn+ssh://内部IPアドレス/

ダメな状況は以下の通り.

  • 研究室内回線から,svn+ssh://FQDN/
  • 研究室内回線から,svn+ssh://外部IPアドレス/
  • 研究室外回線から,あらゆるsvn+ssh

FQDNは内部DNSで内部IPアドレスに変換しているはずです.少なくとも,nslookupではそう返事が返ってくる.外からFQDNへのアクセスは管轄上位のDNSによって外部IPアドレスが返されます.だからこそ,FQDNでアクセスしたいのだが・・・.

svn単体は許可していないので,sshポートフォワードが必要になるのだが,どうも外部線から入ろうとするとダメなようだ.何故だ.sshはどこからでも繋がるのに・・・.事実,svn+sshではなく,ssh単体はどこからでも繋がる.誰か・・・助けて><.

で.自宅に帰ってきてからVPNを使わずに外部線でsvn+sshしたら,普通に繋がった件について.ぇー.もうこうなったら,研究室内部のネットワーク構成がおかしいってことじゃないですかー.もしくは,オレのPCがおかしいってことじゃないですかー.明日もトラブルシュートか.

Satisfy Anyできない
研究室構成員だけが見られるようにしたいディレクトリがある.そこにパスワード認証をかけて,研究室外からはパスワード認証で,研究室内からはIP制限で通したいのだ.だから,.htaccessでsatisfy anyだ.だから,こう書いた.

AuthUserFile /etc/.htpasswd
AuthGroupFile /dev/null
AuthName "Please enter username and password"
AuthType Basic
require valid-user

Satisfy Any
order deny,allow
allow from 127.0.0.1
allow from 192.168.11.0/24
deny from all

なんがー!なにがダメがー!わからんちん.誰か・・・ボスケテ.

200811191047追記:
今日になったら両方とも絶好調稼働中な件について.なんじゃそら.きっと無茶苦茶な設定を繰り返す内に,オレPCのDNSやらなんやらがおかしかったんだろうなぁ・・・.再起動してテストしてたつもりだったんだけどなぁ・・・.

P1000034.JPG

11月7日にベルサール九段で開催されたLiberty Alliance Day 2008に行ってきた.行ってきたというか,レジストレーションしてきたというか,いや,実験があったのだよ.本当だったら,最後の方のOpenSSOとかパネルとか見に行けるはずだったのに,例外が発生して,全く聞けなかった件.

オレ,Liberty系のイベントと相性悪いのかな?技術セミナーも1回しか参加できていない上に,遅刻していって,さらに入室して数分で終わったしorz.

ホッテントリメーカーで9userです.現実的です.

そろそろ言っておくか.「暗号化」に対して「復号化」っておかしすぎるんだよ.1人1人が注意して,徐々に啓蒙していくしかあるまい.ハッキリと言おう.「復号化」はおかしい.

CA391398.JPG

世界的名著であるApplied Cryptographyとその和訳本である暗号技術大全を参考にしつつ,説明していこう.ちなみに,2冊とも私物として持っている.もっと言えば,暗号技術大全は衝動買いだ.

メッセージ(message)は平文(plaintext)だ(ときにはクリアテキスト(cleartext)とも呼ばれる).内容を隠すような形でメッセージを偽装するプロセスを,暗号化(encryption)という.暗号化されたメッセージは,暗号文(cyphertext)だ.暗号文を平文に戻す作業が,復号(decryption)だ.

暗号技術大全 p.1 ll.3-5

この説明が全てを示しているのだが,それではこのエントリーの意味がないので,もう少し説明.「暗号化」と呼ばれる行為は,「平文」を「暗号文」にすることを指す.言い換えれば,「平文」を「暗号文」にする行為を「暗号化」と呼ぶ.ならば,その逆作業はどうなるか.「暗号文」を「平文」にする行為なのだから,「平化」ではないのか.常識的に考えて.仮に,この行為が「復号化」だとするならば,「暗号文」は「復号文」になって然るべきではないのか.ほら!論理的に考えて,おかしいだろ.そうなんだ.だから,「復号化」ではなく「復号」なのだ.「復号」と呼ばれる行為は,「暗号文」を「平文」にすることを指しているのだ.だから,「暗号化」に対する言葉は「復号」であって,「復号化」では有り得ない.

ところで,encryption(暗号化:名詞)とdecryption(復号:名詞)が対で,動詞にするとencryptとdecryptが対になる.しかし,ここで似たような別の言葉がある.

ISO7498-2規格に従いたいなら「encipher」「decipher」という用語を使おう.

暗号技術大全 p.1 l.7

encryptとencipherは同じと考えていいと思う.オレはencryptを使うけど.復号に関しても同じだ.ただ,個人的な印象としてはdecipherは「解読」に感じる.感じるだけで,正しいかどうかは分からない.

折角なので,「解読」についても.「暗号文」を「平文」に戻す行為で,正規の手段に基づいているものは「解読」とは言わない(と思う).「解読」というのは英語ではcryptanalysisと呼ぶ.「解読」という行為は,「暗号文」を「平文」に戻す手順が正規のものではなく,解析的に行われる.なので,「復号」と「解読」は区別して使わなくてはいけない.

ちなみに,認証分野ではもっと厄介なことがあって,authenticationとauthorizationとidentificationとcertificationを使い分けねばならない.日本語にしてしまうと似ているものには,confirmationとvalidationとverificationもある.難解だ!

まとめ:
「暗号化」に対する言葉は「復号」.「~化」って言いたいなら「平化」で.でも,「平化」って意味がわからないし,日本語的解釈だから,やっぱり「復号」で.「復号化」は間違いなので,使わないように!

OpenIDでのNetアンサーログイン開始により2008年10月23日をもってNetアンサー規約を変更いたしました。

Netアンサー規約変更のお知らせ|クレジットカードはセゾンカード

おおお!ついにクレジットカードにまでOpenIDの流れが!これはチェックしなくては!

081024_saison.png

OpenID対応・・・だ・・・と?Yahoo IDしかないじゃん!!そんなのかんけーねー!そんなのかんけーねー!

これ・・・本当の意味でのOpenID対応とちゃうよ.外部認証APIに対応しました程度のOpenID対応だよ.ガッカリだよ.最初から使う気はなかったけど.

200810241310追記:

081024_saison02.png

やっぱりYahoo IDのみではないか.mixiだってOpenID!LivedoorだってOpenID!あ.OpenID(って名乗るけどYahoo! JapanのOpenIDしか許可しないけどOpenIDを使うから一応)対応ってことですね><.

ブログ・ソフトウェアおよびサービス大手のシックス・アパート株式会社(本社:東京都港区、代表取締役:関 信浩)は、ブログ・ソフトウェア「Movable Type 4.2」が、株式会社ミクシィ(本 社:東京都渋谷区、代表取締役社長: 笠原 健治)が本日発表したOpenID認証サービス「mixi OpenID」に対応したことを発表します。シックス・アパートは「mixi OpenID」認証を利用可能にするMovable Type用プラグインを開発し、本日よりMovable Typeユーザー向けに「Movable Typeプラグインディレクトリ」にて無償で提供します(mixiCommentプラグイン)。

Six Apart - シックス・アパートが、Movable Typeを「mixi OpenID」に対応

mixi OpenIDが始まったので,MTの対応をwktkしていたわけですが,即日対応とはやりおるわ.OpenIDファウンデーションは名ばかりじゃないってことですね.というわけで,超高速で対応してみた.誰か,mixiでコメント付けてみてくれぃ!

関連:
速報、1500万人が使える mixi OpenID の技術面を解説するでござるの巻 - Yet Another Hackadelic

200808201846追記:
ちょwww.mixiなidが表示されてるからwww.これはまずいwww.コメントテストしたけど,消しますorz.

nicknameがSREGから取得されます.urlにmixiのidがばっちり入ってます.

みずほダイレクトにログインしようと思ったら,なにやら怪しい画面が表示された.フィッシュられたかと思ったが,ドメインはちゃんとしてたし,EV SSLだった.

080715_mizuho01.png

読んでみると,なにやらセキュリティ情報というものを登録しなさいといっている.しかも,登録しないと使わせてやらないよ!といっている.一応,規約を確認してみたが,「合言葉」云々の記載はあるが,「画像」云々の記載はない(魚拓へのリンク).なので,画像は何に使われるのかをよく読んでおこうと思った.どうやらヤフーなどで導入が進んでいるログインシールのようなものみたいだ.フィッシング防止ですかね.さて,進みましょう.

080715_mizuho02.png

こんな感じで画像を選びます.下の真ん中のボタンを押すと,画像が色々と変わるので,好みの画像を探せばいいらしいです.ま.見つかりませんがw.仕方なく,適当に選びます.

080715_mizuho03.png

続いて,「合言葉」を登録させられます.しかも,3つも.質問1~3はそれぞれ選択肢群が異なります.質問2と質問3の選択肢を掲載するのは割愛しますが.

080715_mizuho06.png

最終的にはこうなります.画像は黒抜きしました.こうやって「画像」と「合言葉」を登録します.すると,次のようなメールが届きます.

080715_mizuho07.png

えっと・・・.画像も保管しないとダメですか??もう既にディテールを忘れているんですが・・・.まずいッスかね?合言葉もですね.他人に知られないようにってのは難しいよねぇ・・・.選択肢は画面に表示されるわけで,「ゼミはどこだ」なんて,公知の事実だし・・・.もしかして,オレが悪い??

さて,これらはどのように使われるか,実際に試してみた.まず,自分のPCではないところからログインを試みてみた.まず,お客様番号を入れる.すると,合言葉1を訊かれる.続いて,合言葉2を訊かれて,正解すると,以下のログイン画面に至る.

080715_mizuho08.png

ふむ.ここまで来ないと「画像」は入手できないわけだ.さて,総当たりは別として,ソーシャル的な攻撃があったとしましょう.お客様番号とその持ち主の紐付けができていて,社会的な周辺知識を十分に持った人がいたとしましょう(あくまで想定).その場合,少なくとも,オレの設定した合言葉は突破されると思う.いとも容易く.まぁ,ログインパスワードはわからないだろうから,ログインはされないと思われるが,この「画像」を入手するところまではたどり着けそうだ.さて,画像さえ入手してしまえば,模倣サイトは作れそうです.フィッシュフィッシュ!スピア攻撃(笑)ならできそうです.でも,それを言い始めたら,ヤフーのログインシールだって同じか.不特定多数を攻撃できない時点で,十分に効果がある.

というわけで,みずほのログインが面倒になったかもしれません.オンラインバンクって,そんなに色々と対策をしないといけないものなんだろうか.ちょっと疑問.

財務省は4日、たばこ自動販売機に7月から全面導入した成人識別機能として、自販機製造大手のフジタカ(京都府長岡京市)が開発した「顔認証」を認定した と発表した。(中略)未成年が大人の顔写真を掲げても認証してしまう不備があったが、ソフトの改良を条件に認 めた。

asahi.com(朝日新聞社):たばこ自販機、「顔認証」で成人識別 財務省が認定 - ビジネス

4日の話を6日に書く辺り,出遅れ感が全開だけど,追っかけてきた話なので,書いておく.フジタカの顔認証自販機が財務省の認定を受けたようだ.都内にも数多く設置されることを期待します.公式の設置場所では確認できないから,都内にあるのかどうかもわからない.

それはそれとして,この前に発見された脆弱性は対処されているのかなぁ.

6月下旬からソフトの更新を始め、今月中に作業を終わらせる予定だ。

7月3日の報道で,6月下旬からソフトの更新をしていたとなると,微妙・・・.瞬き対応だったら,問題なさそう.あぁ・・・.こうなってくると,松村の免許証方式が一番安定しているように思えてくる.いやいや,これを機に,店頭販売というか,角のたばこ屋さん方式が復活して,井戸端会議的な駄弁り場ができて,地域住民のコミュニケーションが盛んになって,「こんなところで、うろうろしてたらあかんで。」ってたばこ屋さんが話しかければ,怪しくないから大丈夫で,だんだん世界が平和になるんじゃないかなーって思います.

関連:
タバコはお札で買おう! - 4403 is written

プロフィール

e-m@il @ddress