個人的には（そこまで重大かどうかは別として。緊急度は「低」だと思う）やっぱりこれは脆弱性といってよいのでは、と思います。

まあそう考える人もいるでしょう。元報告者の方およびその報告を受けて対応した方々はそう考えているんでしょうし（でもシックスアパート自体は「脆弱性」ではなく「危険性」と書いているんですけどね。その辺の言葉の選択もビミョー）。

ただ、Webアプリケーションで認証状態を維持する方法としては、一般的にCookieが利用されるものです。そのCookieにどのような情報が含まれるのであれ、そのCookieが漏れた場合は、ある程度の期間において認証状態が乗っ取られる可能性が発生することになります。

そのCookieによる認証をどの程度の期間有効にするかはWebアプリケーションの設計によりますが、ブラウザセッション（ブラウザを閉じるまで）を越えて有効な認証状態を継続するようなアプリケーション（MTでいうところの「情報を登録する?」オプションがあるもの）では、無期限とまでは言わないまでもかなりの期間、認証が有効な状態が継続するでしょう。

そして現在のところ、WebアプリケーションでHTTPセッション（1回のサーバーへのアクセス）を越えて状態を維持する手段としては、機能性・利便性・安全性のバランスにおいてCookieよりも妥当な方法がありません。より安全なSSL＋secure Cookieを利用する方法や、証明書やハードウェアキーなどを利用した方法は、現時点ではいつでも使える手段とはなっていません（もちろんより安全性が必要な場合は、それらを選択するべきでしょうけど）。

つまり、現在一般的なWebアプリケーションで（特にブラウザセッションを越えて）認証状態を継続しようとした場合は、多かれ少なかれ今回movable typeの認証Cookieが持っていたような危険性を持たざるをえないわけです。で、Webアプリケーション側では、漏れたら危険な認証情報をCookieに持たせる代わりに、Cookieが第三者に漏れないようなアプリケーションの設計にするわけです。Cookieが漏れないようにする（入り口に鍵をかける）ことによって、安全性を確保するわけですね。

もちろんCookieがそれほど安全なものでないことは、XSSやブラウザ自体が持つ脆弱性、盗聴の危険性などから、ある程度知られています。そして、そのような危険性への回避策もいろいろとあります。ただし安全性を高める回避策は基本的にはSSLとの組み合わせとなってしまう（利便性が損なわれすぎる）ため、一般向けのアプリケーションではそれに依存した設計はできません。

というわけで、現在のところ「Cookieにはある程度秘密の情報を保存してもいいが、その代わり第三者にCookieが漏れないような設計にする（漏れた場合はそれは脆弱性である）」というWebアプリケーションの設計方針は、（それほど重要ではない情報・機能を扱うWebアプリケーションにおいては）妥当なものだと考えています。おそらく現在稼働しているWebアプリケーションで、そのような設計方針の下に作成されたものは非常に多いのではないでしょうか。

で、私はmovable typeにおいても、基本的には（扱っている情報・機能とのバランスを考えて）上記のような設計は「あり」だと思います。つまり、「Cookieが漏れるような穴がない限りは、Cookieに秘密情報を保存していること自体は問題にならない」という考えです。ただし、より安全性を重視した設計にするならば、Cookieに保存する情報の内容自体ももっと安全な（漏れたときの影響が小さい）ものにするべきだとも思いますけど。

movable typeのような使われ方をしているWebアプリケーションでは、SSL必須にするわけにはいかないでしょうから、今回の問題を解決する方法としては、おそらくランダム性の高い（少なくともAtom APIでは使えない）認証キーをCookieに保存するようにするのでしょう。それでも「情報を登録する?」オプションが存在する限りは、その認証キーはある程度の期間有効でしょうし、その認証キーが漏れた場合はWeb管理ツールを乗っ取られる危険性があります。Cookieに登録されている情報の内容に関わらず、「Cookieが漏れたら危険である」わけです。つまり重要なのは「Cookieが漏れるかどうか」であって「Cookieに記録されている情報」の方ではない、と考えるわけです。

と、なんか長々書いてきたけど、うまい締めが思いつかないんで、ひとまず「まあそういうことなんですよ」って感じで終わっておく。それにしても俺は別に「MTスキー」でも「セキュリティスキー」でもないのに、なんでこんなに一生懸命説明しているんだろうなー。