【Webアプリケーション】オートログイン機能の実装を考えています。出来るだけセキュリティに配慮した認証方法を知りたいです。

Cookieの持ち回りかた(発行するデータ、有効期限)について詳しく説明がされているものが望ましいです。

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

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:
  • 終了:--
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

回答5件)

id:FMR No.1

回答回数406ベストアンサー獲得回数0

こちらが参考になるかな

id:katzumi

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

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

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

2005/02/25 14:09:38
id:dev_zer0 No.2

回答回数332ベストアンサー獲得回数25

ポイント10pt

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の方が良さそうです。

id:katzumi

はてなのことまで調べて頂きありがとうございます。

それはそれで興味深いです。(^_^;)

やはりCookieに渡すIDをmd5などでハッシュ又は暗号化するのが主流なのでしょうか?

ただやはりセキュリティの面で有効期限がないのはまずいような気がします。Cookieが漏れてもある程度耐性がある認証方式はないでしょうか。。

例えばCookieを定期的に再配布したり、Cookieとそれ以外の情報を組合わせてセキュリティを確保するなど。。

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

2005/02/25 15:35:19
id:sadcns No.3

回答回数53ベストアンサー獲得回数0

ポイント40pt

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のところはいろいろ情報がありますが、高木 浩光氏の発表スライドは参考になるかと思います。

id:katzumi

ありがとうございます。

cookieの漏洩自体を防ぐ為にsecure属性を指定する必要があるということですね。スライドが大変わかりやすかったです。

「2つのcookieをセッション追跡に使用する」というのは目からウロコでした。

2005/02/27 08:02:05
id:roiko No.4

回答回数67ベストアンサー獲得回数0

ポイント30pt

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を取得するもよし。

だけど、それでもある人のブラウザを別な人が使ってしまうと、どうしようもありません。よってオートログインを使う場合は、アクセス範囲を限定するのも一つの手かと思います。オートログインの場合は、ユーザ別にカスタマイズされた画面やお知らせなど当たり障りのない内容を表示させ、登録内容の変更やパスワードの変更においては再度パスワードを入力させる。たとえば銀行系はそうですよね、取引の最後に暗証番号を入力させたり。ここまでしておけば、十分な対処になるかと思います。

id:katzumi

大変貴重なご意見ありがとうございます。

オートログインで使用するCookieの有効期限設定と再配布をすることで成りすまし対策ができると思っています。ですが実装を考えた場合、オートログイン時毎にCookieの再配布(セッションIDの再発番)が確実に行えるか?ということ危惧しています。ネットワークの状況によってはCookieの受け渡しがうまくいかず、以前のセッションIDのままとなってセッション切れとなってしまいます。。(ここら辺は実装次第でカバーできるかと思います。)

最後にアクセス範囲を限定することについては実装時には考慮する予定です。コアな情報にアクセスする場合には再度、ID・パスワードによる認証を行ないます。

2005/02/28 09:34:02
id:ma-kanoh No.5

回答回数155ベストアンサー獲得回数4

http://www.josso.org/

Welcome to the Java Open Single Sign-On Project

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

id:katzumi

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

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

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

2005/03/02 08:51:48

コメントはまだありません

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません