人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

【Webアプリケーション】オートログイン機能の実装を考えています。出来るだけセキュリティに配慮した認証方法を知りたいです。
Cookieの持ち回りかた(発行するデータ、有効期限)について詳しく説明がされているものが望ましいです。

※”セキュリティホールになるから駄目”という指摘はごもっともなのですが、そこを前向きに対処する方法をご教示頂けると助かります。

●質問者: katzumi
●カテゴリ:コンピュータ
✍キーワード:cookie Web アプリケーション グイン セキュリティ
○ 状態 :終了
└ 回答数 : 5/5件

▽最新の回答へ

1 ● FMR
●0ポイント

http://www.webkoza.com/doc1/cookie_a.htm

Cookieについて

こちらが参考になるかな

http://www.fromdfj.net/javascript/cookie.html

fromdfj.net

◎質問者からの返答

すみません。Cookieの使い方ではなく、Cookieを組合わせた”認証方式”が知りたいです。

アカウント保持者を判別する為の一時的な情報としてCookieを挙げていますが、その他の方法があればそれでも良いです。

セキュリティ関係に詳しい方でこういう認証方式がよいというアドバイス等でも結構です。


2 ● dev_zer0
●10ポイント

http://e-words.jp/w/SSL.html

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とそれ以外の情報を組合わせてセキュリティを確保するなど。。

はてな以外のサイトについても調査してみるのもいいかもしれないですね。


3 ● sadcns
●40ポイント

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をセッション追跡に使用する」というのは目からウロコでした。


4 ● roiko
●30ポイント

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・パスワードによる認証を行ないます。


5 ● ma-kanoh
●0ポイント

http://www.josso.org/

Welcome to the Java Open Single Sign-On Project

というのは駄目?シングルサインオン実装のひとつですが。セキュリティはばっちし。かも。

◎質問者からの返答

既に認証システムがあるのと、シングルサインオン単体ではオートログインを実現できないと思いますので、今回の質問にはマッチしないです。

質問を一旦終了します。皆さんのご意見を参考にしながらもう少し考えてみたいと思います。

ありがとうございました。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ