Cookieの持ち回りかた(発行するデータ、有効期限)について詳しく説明がされているものが望ましいです。
※”セキュリティホールになるから駄目”という指摘はごもっともなのですが、そこを前向きに対処する方法をご教示頂けると助かります。
http://www.webkoza.com/doc1/cookie_a.htm
Cookieについて
こちらが参考になるかな
SSLとは 【Secure Socket Layer】 - 意味/解説/説明/定義 : IT用語辞典
一番いいのはSSLですが
はてなの場合、name値にユーザ名、rk値(多分パスワード)を
暗号化してオートログイン機能を実装しているようです。
有効期限は10年後になってます。
http://e-words.jp/w/E69A97E58FB7E58C96.html
暗号化とは 【encryption】 - 意味/解説/説明/定義 : IT用語辞典
暗号化は昔はDECが主流でしたが、
今はRSAの方が良さそうです。
はてなのことまで調べて頂きありがとうございます。
それはそれで興味深いです。(^_^;)
やはりCookieに渡すIDをmd5などでハッシュ又は暗号化するのが主流なのでしょうか?
ただやはりセキュリティの面で有効期限がないのはまずいような気がします。Cookieが漏れてもある程度耐性がある認証方式はないでしょうか。。
例えばCookieを定期的に再配布したり、Cookieとそれ以外の情報を組合わせてセキュリティを確保するなど。。
はてな以外のサイトについても調査してみるのもいいかもしれないですね。
http://securit.gtrc.aist.go.jp/research/paper/AIST03-J00017/
Cookie$BEpD0$K$h$k(BWeb$B%"%W%j%1!<%7%g%s%O%$%8%c%C%/$N4m81@-$H$=$NBP:v(B
SSLでsecure属性のcookieを設定すれば良いと思いますが。
URLのところはいろいろ情報がありますが、高木 浩光氏の発表スライドは参考になるかと思います。
ありがとうございます。
cookieの漏洩自体を防ぐ為にsecure属性を指定する必要があるということですね。スライドが大変わかりやすかったです。
「2つのcookieをセッション追跡に使用する」というのは目からウロコでした。
http://www.atmarkit.co.jp/fsecurity/rensai/webhole10/webhole01.h...
@IT:Webアプリケーションに潜むセキュリティホール(10)
Webアプリケーションの検査を仕事としている者です。セッションはWebアプリケーションで必ず必要となるので、色んな意見があると思いますが、私としてはこんな風に考えています。
まず通常のログイン。一般にはIDとパスワードで認証がOKになるとセッションIDが発行され、それがその後のアクセスではCookieで受け渡しされます。それに対しオートログインは、そもそもセッションIDがCookieに含まれているだけのこと。本質的には違いはありません。
しかし問題となるのが、セッションIDの有効期限。通常の認証では認証ごとにIDが変わりますので、オートログインでもアクセスのたびにセッションIDを変化させれば、セッションハイジャックに対しては通常のログインと同じレベルの対策になるでしょう。
となると残る問題は、IDとパスワードを知らなくてもログインできてしまう人がいるかもしれない、ということです。ここは、まず危険性を利用者に説明し、オートログインを使用するかしないか選択させることも必要でしょうが、システム側としては別な情報と組み合わせることで、本人を認識するとよいかと思います。別な情報とは、もう一つCookieを発行するもよし、HTTPの環境変数からUser-Agentを取得するもよし。
だけど、それでもある人のブラウザを別な人が使ってしまうと、どうしようもありません。よってオートログインを使う場合は、アクセス範囲を限定するのも一つの手かと思います。オートログインの場合は、ユーザ別にカスタマイズされた画面やお知らせなど当たり障りのない内容を表示させ、登録内容の変更やパスワードの変更においては再度パスワードを入力させる。たとえば銀行系はそうですよね、取引の最後に暗証番号を入力させたり。ここまでしておけば、十分な対処になるかと思います。
大変貴重なご意見ありがとうございます。
オートログインで使用するCookieの有効期限設定と再配布をすることで成りすまし対策ができると思っています。ですが実装を考えた場合、オートログイン時毎にCookieの再配布(セッションIDの再発番)が確実に行えるか?ということ危惧しています。ネットワークの状況によってはCookieの受け渡しがうまくいかず、以前のセッションIDのままとなってセッション切れとなってしまいます。。(ここら辺は実装次第でカバーできるかと思います。)
最後にアクセス範囲を限定することについては実装時には考慮する予定です。コアな情報にアクセスする場合には再度、ID・パスワードによる認証を行ないます。
Welcome to the Java Open Single Sign-On Project
というのは駄目?シングルサインオン実装のひとつですが。セキュリティはばっちし。かも。
既に認証システムがあるのと、シングルサインオン単体ではオートログインを実現できないと思いますので、今回の質問にはマッチしないです。
質問を一旦終了します。皆さんのご意見を参考にしながらもう少し考えてみたいと思います。
ありがとうございました。
すみません。Cookieの使い方ではなく、Cookieを組合わせた”認証方式”が知りたいです。
アカウント保持者を判別する為の一時的な情報としてCookieを挙げていますが、その他の方法があればそれでも良いです。
セキュリティ関係に詳しい方でこういう認証方式がよいというアドバイス等でも結構です。