会員メニューのセッションに関する指摘について

先日、「Web屋のネタ帳」というブログから、「さくらインターネットの会員メニュー画面のセッション情報はログアウトしても1年たっても消えない件」という旨のトラックバックがありました。
それによると、「クッキーを保存しておくと、1年後でもログインできる」といった内容で、クッキーを保存する人なんておるんかいなと思いつつも、実際に保存していた人が居たことに、少し興味が惹かれました。
ただ、指摘されている内容については、実際と異なることも多く、当該ブログの管理者様にはコメントだけお送りしたのですが、特に返事の無いまま、飛び火をして憶測だけが流れ続けていることに少し憂慮しており、ここで解説させて頂くことにしました。

ちなみに、「考え」の部分は、私個人の考えですので、その点はお含みおきください。


まず初めに、当該ブログにおいて指摘されている点を以下の2点に要約します。

  • セッション管理をする際にはログアウト時にセッション破棄を行わなければならない

  • ログインからしばらくたった後(1年後)もそのまま利用できるのは、良くない

1点目は技術的な指摘であり、会員メニューがセッション管理を行っていたならば、当然ログアウト時にセッション破棄を行わなければならないというのは、書いているとおりです。この部分のみを切り取ってみれば、間違いありません。
しかし、会員メニューに当てはめてみると、これには重大な間違いがあります。
それは何かというと、会員メニューではセッション管理をしていないということです。なので、セッションを破棄するという動作がそもそもありません。
つまり、問題点その1と、問題点その2は、会員メニューには当てはまりませんので、ご安心ください。
20070424-browser.gif
2点目はポリシー的な指摘であり、考えが分かれるところです。
ただ、管理者の方が指摘されている、「ログインしてから1年以上もたった後に解約できるのは問題」という部分は間違っており、実際にはログイン後に一定時間が過ぎると、パスワードの再確認がなされます。また、住所変更や、クレジットカードの表示・変更の場合にも、同様の処理が行われます。
すなわち、問題点その3についても、会員メニューには当てはまりません。
(後ほど、管理者によって修正されています。ありがとうございます)
もちろん、サーバ設定については一定期間経過後にできないようにすればとの意見もあると思いますが、逆に不便になる点もあり「考えが分かれる」と表記させて頂きました。

ところで、セッション管理というキーワードが出てきましたので、ユーザ認証が必要なサイトに関して、すこし解説をさせていただく事にします。
まず、ユーザ認証が必要なサイトに関して、以下に代表的な3種類をあげさせていただきました。


  1. セッションで管理する

  2. ユーザ名とパスワードはログインを行う場合のみデータベースへ確認し、その後はサーバとブラウザがセッションIDと呼ばれるランダムに生成された文字列を共有して、認証行います。
    比較的多く利用されている手法で、今回ご指摘頂いた管理者の方の意見も、これをベースとされています。
    たとえるならば、カード表面にランダムに振られた番号の書かれた印鑑登録カードと同じようなものです。最初に免許書等で本人確認を行い、それ以降はカード番号の記された印鑑登録カードを持っていくだけで印鑑登録証明書が発行されるのに似てるでしょう。

  3. その都度ユーザ名とパスワードを送る

  4. その都度、ユーザ名とパスワードをサーバに送付し、毎回データベースに確認します。これは古典的な方法で、ブラウザのダイアログボックスにユーザ名とパスワードを入力する手法が多く見られます。
    たとえるならば、キャッシュカードのようなもので、毎回暗証番号を入れることに似ています。

  5. ハッシュを利用する

  6. ユーザ名とパスワードをログイン時のみに行うのはセッション管理に良く似ていますが、サーバに何らかのIDを残すことはしません。手法としては、サーバ側でサーバ暗号とユーザ名をハッシュ化しクライアントに知らせ、アクセスする際にはハッシュとユーザ名をサーバに通知します。サーバ側はサーバ暗号とユーザ名を再度ハッシュ化し、通知されたハッシュ値と比較して認証を行います。
    その都度ユーザ名とパスワードを送る仕組みと異なり、パスワードは最初のみに限定して安全性を高めると共に、毎回データベースに確認する手間を省けます。

以上が、それぞれの解説です。
他にも、さまざまな方法がありますが、今回は3つだけの紹介とさせていただきます。
以下が、それぞれの特徴などをまとめた表です。

セッション管理 都度送信 ハッシュの利用
特徴 セッション内でさまざまなデータを扱うことができ、認証情報の破棄も簡単にできる。 古典的な方法であり、動作が分かりやすい。 サーバで管理すべき情報が無く、サーバを分離しやすい。また、認証の有効期間をプログラム側で設定できる。
不便な点 サーバ内でセッション情報を管理しなければならず、サーバを分離するのも手間がかかる。 毎回パスワードを交換しなければならず、且つデータベースへの確認も必要となる。 認証の時間管理を適切に行わねばならず、プログラムが煩雑になる。
危険な点 サーバのセッション情報が漏れると、全てのセッションが乗っ取られる パスワードを毎回送信するため、漏洩の確率があがる 暗号やハッシュ値の適切な管理を行わないと、いつまでも認証が出来たり、勝手に認証情報を偽造されることがある

なお、詳しく書くことはできませんが、会員メニューの認証は3番目の「ハッシュを利用する」に近いものを採用しています。その為、セッション管理が無く、当該ブログで指摘しているようなセッション削除に関する問題は理論上発生しないということは、上記のとおりです。
この仕組みを採用した背景としては、会員メニューのページ毎に有効期限を指定したいということと、実際のサーバは複数に分かれておりセッションの管理が煩雑になることとの2点からです。このおかげで、クレジットカードは高頻度に、サービス一覧は低頻度にパスワードを再確認する仕組みを構築できています。さらに、会員メニュー、コントロールパネル、オンラインサインアップ、DNSゾーン編集、ドメインコンパネ等、さまざまなシステムへシングルサインオン可能な環境が構築できました。

ちなみに、この仕組みの危険な点として記した暗号の漏洩や詐称を防ぐべく、公開鍵暗号を利用した暗号化での実装を行っており、認証サーバ以外、会員メニューやレンタルサーバコントロールパネルを含めて、全てのサーバにおいて秘密鍵が含まれておらず、それらのサーバでクッキーの偽造はできません。
さらに、クッキーの中には会員IDと発行日時、キーのインデックス以外の情報はほとんど入っておらず、当然のことながらパスワードなどの機密情報は全くありません。

ところで、高木浩光氏の指摘はとても的を射ており感心する限りですが、キーの有効性についてはキーのインデックス情報により対処ができるようになっており、古いキーの失効をさせることも可能です。
すなわち、時間情報とキーインデックスを公開鍵暗号によって詐称できない裏づけの元にクッキーを生成し、失効したキーインデックスのシリアル番号を登録しておくことにより、古いクッキーの無力化が図れるようになっています。

なお、唯一当社で考えなければならないこととしては、ページ毎の有効期限を再考することかと思っています。
例えば、レンタルサーバのコントロールパネルには、かなりの長時間にわたってクッキーの失効を抑制していますが、1ヶ月毎にパスワード再確認の必要性があるのかもしれません。
このあたりについては、皆様のお知恵をお借りしつつ、ポリシーの再検討をさせて頂きたく思っております。

まとめ


  1. 認証にセッション管理は利用しておらず、セッションを破棄する仕組みはそもそも存在しない

  2. クッキー(SID)の有効期間はコントロールできる仕組みであり、ページ毎に個別の期限を設けている

  3. クッキー(SID)を選択的に無効化できる仕組みがサーバ側に備わっている(失効情報)

  4. クッキー(SID)には会員IDとキーインデックス(シリアル)、発行時間などが含まれており、詐称防止のために公開鍵暗号を用いている

  5. 現在の有効期限を今より短くしないといけないページがあるのかもしれない(コンパネ等)

  6. ログアウトを押しつつクッキーを保存する人は通常はおらず、居たとしても前述のように有効期限管理で代用可能(クッキーを破棄するログアウト方法は一般的)


技術的にかなり複雑なシステムで、ウェブプログラミングの技術が相当に深い方でないと、この仕組みに問題ないことがわかっていただけないのは事実で、頭の良い方がうまく補足していただけると幸いです。
結局、仕組みをどのようにしても(セッション形式を用いても)、1年以上クッキーを残してサーバにセッション等の情報を残す限り、認証状態の継続を行うことは可能であり、技術的な仕組みにはまったく問題無いわけですが、ポリシーは再考する場合もあるのではないかところで、まとめとさせていただきたいと思います。(26日一部修正)

以上、長文を最後までごらん頂き、ありがとうございました。
また、当該ブログの管理者様には深く感謝いたします。

今後とも、さくらインターネットのサービスをよろしくお願いします。

追記1 4/28
当該ブログの管理者様によって記事が追加されていました。
http://neta.ywcafe.net/000731.html
大変丁寧にご対応いただき、ありがとうございます。
ちなみに、「公開してくださってもかまいません」については、特に他意はなく(笑)、ほかの方にメールを送った際に『ブログで公開しても言いか』と返信されることがたまにあるので、書いただけでした。私的には、「セッションではないらしい」ということと「パスワード確認があるらしい」ということが、ほかのかたがたに伝われば、特に問題は無く、結局このエントリーもあるので、見解の発表はすでに達成できたと思っています。
なお、新しい記事で書かれていた有効期限は、たいへん有用かと思うので、実現できればいいなと思います。SIDに含まれるキー自体は1日で失効させて、利用者の方があらかじめ設定した期間に限ってパスワードなしでキーを更新していくなどの方法も取れるかもしれません。

トラックバック(2)

tb 頂いたので眠いけど軽く。。。 会員メニューのセッションに関する指摘について (さくらインターネット創業日記 さま) 概ね了解。雑... 続きを読む

ちょっと前に筆者が書いた さくらインターネットの会員メニュー画面のセッション情... 続きを読む

コメント(6)

通りすがりの者

>高木浩光氏の指摘はとても的を射ており感心する限りですが、

氏の指摘はどこに書いてあるのでしょうか?リンク先を見たのですが見つかりません。

通りすがりの者

この記事についても出鱈目とのコメントがついているようですので参考まで

田中

指摘可能な文章にしていた私の脇が甘かったようです。
「1年以上クッキーを残してサーバにセッション等の情報を残す限り、?」に変更しています。
このくだりは、1年間ログイン状態を継続させるかどうかが要点だったのですが、言葉たらずで別の観点での突込みをされてしまいました。

dai

2004年頃に都内DCでハウジングを利用していました。
コンロールパネルといったソフト面のセキュリティも然りですが、、データセンターのファシリティ面のセキュリティ(ラックの管理やもろもろ)は改善されてるのでしょうか。。
2004年頃でも既にmixiやgreeやCAなど有名企業が多く利用していたかと思いますが、あの頃のイメージが強くて、、自分のお客様にデータセンターの利用を提案する際に、躊躇してしまいます。
御社とほぼ同じ値段でも、作業前後にオペレータが解錠/施錠/ラックチェックなど、セキュリティがかっちりした上に手厚いサポートをしてくれる所も多くありますので。
せめて最低限のセキュリティは確保して頂きたいと思っています。

田中

daiさん
データセンターの具体的なファシリティ面ということですが、具体的に何が不満な点としてございましたでしょうか?
ラックの管理に何らかの問題があって、利用提案に躊躇するということは読み取れるのですが、どのような問題があって、どのようにすれば最低限のセキュリティが満たせるのかを詳しくお教え頂ければ幸いです。

ちなみに当社のデータセンターでは、ラック毎に別々のキーを用いており、開錠・施錠はお客様にゆだねております。もちろん、そのキーでは他のラックを開けることはできません。また、1時間に1回の見回り点検をしており、ISMSに基づく点検簿も備えております。
サポート面では、サーバのオペレーションなどを行うサービスもご用意しております。

なお、ブログのコメントよりは、私に直接メールを頂いたほうが対処の幅も広がると思いますので、ぜひともご連絡下さい。
以上、詳細がわからないのでこれ以上は何とも言いがたいのですが、ご不満な点があられた事には、申し訳なく思っております。