Movable Type 技術情報

MovableType のパスワードは最初の8文字しか認識しません

ぴろり上西 2011年02月01日

Amazon のパスワードを長い間変えていない人は、とりあえず今すぐ変えましょう！
Amazonのセキュリティの欠陥は、パスワードの8文字以降を認識しないというものだそうです。
例えば、パスワードが「password1234567890」でも「passwordpizza」でも、最初の8文字が「password」で同じなので、同じものと認証されてしまうとのこと。

　それ何て crypt 関数？　と思いましたが、Amazon が Perl で構築されているという話もあるので、あながち間違っていないのかも知れません。

　どういうことかというと、Web サービスなどでは、サービス側がユーザのパスワードを平文でそのまま保持せず、何らかの暗号化(一方向関数とかいろいろあるんだけれど、ここでは暗号化と呼びます)を施した上で、パスワードを保存するのが普通の設計です。そうしないと、万が一顧客情報が漏れたりした時に、パスワードが丸見えだと不正ログインされてしまいますからね。その暗号化の処理において、Perl で使われているのが crypt という関数なんです。
　ところが、この crypt 関数には、入力されたデータの最初の 8 文字しか使わない、という変な仕様(?)があります。そのため、どれだけ長いパスワードを使っていても、上記の記事のようにパスワードの 9 文字以降が無視されてしまうのです。サービス内部の実装によっては、長いパスワードを使っているから安心、というわけではないのです。

　さてさて、ここからが MovableType のお話になるわけですが。実は MovableType も、パスワードの暗号化処理には crypt 関数を使っています。...嫌な予感がしますね。ソースコードを見ると、素直に上記の処理がコーディングされています。早速、実験してみましょう。使ったのは最新の MovableType 5.04 です。
　まず、適当にユーザーを作成し、パスワードを「password123」に設定します。ここで、パスワードは全部で 11 文字ありますね？　一度、ログアウトしたら、ログインし直してみましょう。

パスワード	ログイン
password123	成功。まぁ当たり前。
pass	失敗。まぁ当たり前。
password1234567890	成功。あれ！？
passwordhogehoge	成功。あれれ！？？
password	成功。あれれれ！？？？

　...とまぁ、なかなか香ばしい結果になってしまいました。というわけで、MovableType でもパスワードは入力された最初の 8 文字しか認識しないということがわかりました。セキュリティ要件の厳しいお客様だと、問題になったりしませんかね？　何らかの対策がされることに期待したいところです。とりあえず、パスワードは 8 文字の範囲内でOKなので、英数大文字小文字、記号を入り交えて設定されることを強くオススメします。

投稿者ぴろり上西 : 02/01

regex_replaceでごにょごにょ

ぴろり上西 2011年01月26日

　URI 文字列からスキーマとドメイン部分を除去してごにょごにょしたい！　というシーンで。まぁ、脊髄反射的にプラグインを書いたりしちゃうわけですが、regex_replace モディファイヤを使うと簡単にごにょごにょできますよ、と。

<MTUnless regex_replace="/https?://[^/]+/g","">
http://www.skyarc.co.jp/hoge.txt → /hoge.txt
https://www.skyarc.co.jp/fuga.txt → /fuga.txt
</MTUnless>

regex_replace の引数はスラッシュで囲むわけですが、その中のスラッシュはエスケープしなくてもいいんですな(´･ω･`)　なんだか気持ち悪いけど。

投稿者ぴろり上西 : 01/26

Mac上でMTのダイナミックパブリッシングでハマる

ぴろり上西 2011年01月21日

　こんにちは。社長の趣味か否かは定かではありませんが、昨年から開発陣の使用する PC が、次第に Windows マシンから Mac に移行しつつあります。WIndows だと XAMPP を入れたり ActivePerl を入れたり、と環境を作るのが大変だったりしますが、Mac の場合だと、最初から Apache やらが入っていて、結構本番サーバ(Linux)に近い環境が最初から揃っているのがありがたいですね。そんなこんなで、キーアサインの違いに苦労しながら、Mac で開発しているんですが。先日、ダイナミックパブリッシングを使う機会がありまして。普段はスタティックなプラグインばかりを書いていて、ダイナミックパブリッシングなんて、もう完全に忘れていたんですが。

Error: pdo error: [-1: Connection attempt failed: SQLSTATE[HY000] [2002] No such file or directory] in PCONNECT(mysql:host=localhost, 'root', '****', mt_5)

　データベースに接続できていないみたいです(´･ω･`)

$ vi mt-config.cgi
#DBHost 127.0.0.1
DBHost localhost

　よくわからないままに、mt-config.cgi を編集したら、接続できるようになりました。localhost と 127.0.0.1 で同じことだと思うんですがね。リロード。
　...エラー(´･ω･`)

mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Tokyo' for 'JST/9.0/no DST' instead

　次は PHP のランタイムエラーが(´･ω･`)　なんかタイムゾーンが設定されていないぞー的な感じです。

$ vi /etc/php.ini
date.timezone = Asia/Tokyo

　やっと動くようになりました。Mac 上でダイナミックパブリッシングなんて奇特な人の参考になれば幸いです。

投稿者ぴろり上西 : 01/21

SKYARC Tech Preview: Brothers Technology

ぴろり上西 2010年12月24日

　まだ公開できないものの、スカイアーク社内では今、こんなことを研究・開発しています、というヒミツをチラ見せしてしまう新コーナー「SKYARC Tech Preview」の第一回です(勝手に作りました＞＜)
　今回は、Movable Type を更にプログラマブル・パブリッシング環境に近づける、Brothers Technology について紹介しちゃいます！

　通常の Movable Type では、MTテンプレートタグを用いてテンプレートを記述し、静的なファイルを得ることができます。このような使い方では、MTテンプレートタグを用いて条件分岐やループなどの処理を行うことができるので、プログラマブルなレイヤ数としては 1 段と数えることができます。

　更に、MTテンプレートタグを併用して、PHPのソースコードを生成してやれば、WebサーバでPHPが処理される時にも条件分岐などの処理が可能になります。すなわち、プログラマブルなレイヤ数としては 2 段と数えることができます。ここまでは、誰にでも簡単に実現できます。
　また、一部のベンダが採用している動的生成(≒ダイナミックパブリッシング)では、MTテンプレートタグを用いて、MTテンプレートタグの含まれた静的なファイルを生成し、Webサーバにリクエストがあった時点で、もう一度、ファイル内のMTテンプレートタグを処理する、ということが行われています。しかし、それでは PHP のコードは処理しませんので、プログラマブルなレイヤはやはり 2 段留りになります。

　このように、今までは、サーバ上に書き出された静的なファイルを Perl で処理するか、または PHP で処理するか、という二者択一でした。スカイアーク社内で研究中の Brothers Technology を用いると、静的ファイルの中のMTテンプレートタグとPHPコードを、どちらか一方ではなく、両方とも動作させることが可能になります。これによって、テンプレートを用いて、MTテンプレートタグとPHPの混在した静的ファイルを書き出し、Webサーバにリクエストがあった時点で、MTテンプレートタグとPHPを処理する、という 3 段のプログラマブルレイヤを実現することができるようになりました。技術的には、更に段数を増やすことも可能な仕組みです(PHPの処理結果を再びPHPで処理するとか)
　実際のところ、3 段ものプログラマブルレイヤが必要になることは、大規模開発以外では滅多にありませんが、任意のタイミングで、任意の言語を選んでプログラミングを行えるというメリットが生まれます。結果、採用するアーキテクチャを柔軟に変更可能とすることで、コスト、納期、品質の面で大きなアドバンテージを得ることができるようになるでしょう。