会員制Webサイトのアクセス制限について
- 会員制Webサイトのアクセス制限について、Basic認証以外の方法を探しています。現在のBasic認証ではセキュリティが心配なため、より安全な方法を模索しています。
- Digest認証は使用できないため、独自SSLを取得してログイン認証を暗号化することを考えています。しかし、Basic認証のままでは「ログアウト」がなく、共有PCなどでの利用に問題があります。
- また、PHPでセッションやクッキーを使った認証も検討していますが、Basic認証で使用していたパスワードファイルの流用ができるかどうかが分かりません。解決策や情報があれば教えてください。
- ベストアンサー
Basic認証以外でのアクセス制限
会員制のWebサイトを運営しています。これまでは同好会のようなサイトのため、Basic認証を使用してきました。 しかし、会員数が1万人を越えたため、そろそろセキュリティのことも考えなくてはならなくなり、何か別の方法を探しています。なお、私自身はWebデザイナーでプログラムは書けません。 一般的にBasic認証からのアップグレードではDigest認証になるらしいのですが、使用サーバがさくらのレンタルサーバ（ビジネスプロ）で、apacheが1.3xのためDigest認証は使用できないようです。 会員サイトへのログインについては、独自SSLを取得してログイン認証を暗号化してもいいと考えているのですが、Basic認証のままでは「ログアウト」がなく、共有PCなどではすべてのブラウザウインドウを閉じてもらうしかない点が不評です。PHPでセッションやクッキーを使ったものはどうかな？とも考えているのですが、今までのBasic認証で使ってきたパスワードファイルが流用できるかどうかがわかりません。 何かよい解決策や情報がありましたらお教えください。よろしくお願いします。
- popduck
- お礼率100% (4/4)
- ネットワーク
- 回答数4
- ありがとう数5
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
＞ログイン用のcgiかページ ログアウトの間違いでした。 401ヘッダ+同じAuthNameで強制的に認証エラーを起こしてリセットできるのですが、ダイアログがでてうっとおしいですよね。 変則的な方法ですがこういうのはいかがですか？ ログアウト用のユーザを設定する。logout:logoutとか。 ログアウト用のディレクトリをプライベートエリア内に作り、.htaccessを AuthType Basic AuthUserFile パスワードファイル AuthName "同じAuthName" require user logout とします。適当にログアウト画面の index.html を作ってそのディレクトリに入れます。 プライベートページにログアウトボタンをつけてリンクを https://logout:logout@www.***.com/プライベートエリア/logout/ とします。(SSLの場合) これで違うユーザがセットされてプライベートエリアで再度認証を求められます。 ログアウト用のパスワードファイルは別個に作ったほうがいいでしょう。 同じファイルだと require valid-user のときに解除できないので。 ログアウト用パスワードファイルを自分で作るときは以下をテキストファイルに書いて保存 logout:loNScApf9qjGc
その他の回答 (3)
- thezen5
- ベストアンサー率84% (27/32)
現在のリソースを生かすとしたら、SSL導入でログアウトの機構だけ付ければいいんではないでしょうか？ 以下を参考にログイン用のcgiかページを作れそうですが ヘッダー出力で認証を切ってしまう方法 http://shorindo.com/tech/tech0002.html ただできなかったという書き込みも見ましたので、プランBとして AuthNameで初期化する方法 http://blog.y-110.net/log/eid133.html
お礼
回答ありがとうございました。 ログインは専用ページを作ればいいとして、やはりログアウトが問題ですね。 ヘッダーで401を返す方法というのは私も試してみたのですが、最近のブラウザではやはりうまくいかないようです。 別のAuthNameで強引に再認証させて初期化するというのは知りませんでしたが、これはいいアイデアかもしれませんね。試してみます。
- memphis
- ベストアンサー率40% (975/2395)
既にCMSを使っているならMysqlなどのDBは使っていますよね？ それならIDとパスワードをDBで管理し、CMSのヘッダテンプレートで 認証とセッション管理の処理を追加すれば手間が少なく済むと思います。
お礼
回答どうもありがとうございました。 MySQLは使っていますが、DB認証をするには専用のApacheモジュールが必要になるのではないかと思いました。 さくらサーバの場合、そのモジュールが入っているかどうかが不明ですし、ユーザー側でモジュールのインストールはできないはずので、DB認証は難しいのではないかと思っていましたが… また、パスワード発行や管理に関しては、現状でもCGIを使用しており、それほど問題とはなっておりません。今回の質問は、今までのパスワードファイルを流用して、セキュリティレベルの向上（認証時の暗号化）と、明示的な「ログイン／ログアウト」システムを構築できないだろうか、という趣旨です。 それから、会員サイト内で使用しているCMS（MTです）は、あくまでもサイト内の一部であり、大半は古いHTMLページ（数千ページ以上）や2ちゃんねる式の掲示板および過去ログなどで構成されています。そのため、すべてのページヘッダにソースを記述するのは難しいと思っています…。
- memphis
- ベストアンサー率40% (975/2395)
会員サイトを運営するなら、CMSとかSNSとかのサイトにしたほうが手間も少ないから、考えてみては？ 私の場合、メンバー数は少ないですが 最初からトラブル発生、多くなる事を見越して 掲示板ベースのポータルサイトと、SNSベースのサイトの２つを運営しています。
お礼
どうもありがとうございます。 サイト内の一部はすでにCMSで運営していますが、10年近くの間に溜まった大量のコンテンツを移したり作りかえるようなことは考えておりません。 運営の方法ではなく、ログイン認証を問題としていますので、今回の質問に対する範囲での回答を期待しています。どうぞよろしくお願いいたします。
関連するQ&A
- SSLを使用した場合ユーザ認証はBASIC認証でいい？
Apacheを使用して個人用途（他人にはいっさい公開しない）サイトを作成しようとしています。 （しばらくはLAN内で使用するが、後にインターネットからもアクセス可能にする予定） セキュリティはできるかぎり確保したいので暗号化通信、ユーザ認証を考えています。 SSLは導入できそうなところまできましたが、ユーザ認証はどうしたらいいか悩んでいます。 いまのところBASIC認証とダイジェスト認証があがっていますが、SSLにて暗号化するならBASIC認証でいいのでは？と考えています。 ほかの選択肢はあるのでしょうか？ サーバOS:VineLinux3.2 Apache:1.3
- ベストアンサー
- ネットワーク
- なぜ@NiftyはBASIC認証でユーザー認証しているのか？
日本で初めてインターネットを提供開始した@niftyでは会員サイトでのユーザ認証をBASIC認証を使用しています。 Yahoo!やGoogle,goo,infoseekなど大手ポータルサイトなどはBASIC認証ではなくクッキーとセッションIDを使用したユーザ認証を使用しています。 なぜ、最高のセキュリティを保たなければならないISPでもある＠Niftyが今でもBASIC認証を使用しているのでしょうか？ BASIC認証でのセキュリティは大丈夫なのでしょうか？ メリット、デメリットなど教えてください。
- ベストアンサー
- ネットワーク
- phpを用いたダイジェスト(digest)認証後のログアウト処理方法
いつもお世話になっています． 早速ですが，タイトルの件について質問します． 現在作成しているサイトでダイジェスト認証を行いたく，以下のプログラム digest_auth() を利用して認証を行っています． URL: http://techblog.ecstudio.jp/tech-tips/digestauth.html ※説明のため，"[1]，[2]，[3]"を追記しています． ----------------------------------------------------------------------- function digest_auth($auth_list,$realm="Restricted Area",$failed_text="認証に失敗しました"){ // [1] if (!$_SERVER['PHP_AUTH_DIGEST']){ $headers = getallheaders(); if ($headers['Authorization']){ $_SERVER['PHP_AUTH_DIGEST'] = $headers['Authorization']; } } // [2] if ($_SERVER['PHP_AUTH_DIGEST']){ // PHP_AUTH_DIGEST 変数を精査する // データが失われている場合への対応 ※ 文字数制限のため中略． （暗号化のための準備．) if ($auth_list[$data['username']]){ // 有効なレスポンスを生成する $A1 = md5($data['username'].':'.$realm.':'.$auth_list[$data['username']]); $A2 = md5($_SERVER['REQUEST_METHOD'].':'.$data['uri']); $valid_response = md5($A1.':'.$data['nonce'].':'.$data['nc'].':'.$data['cnonce'].':'.$data['qop'].':'.$A2); if ($data['response'] != $valid_response){ unset($_SERVER['PHP_AUTH_DIGEST']); }else{ return $data['username']; } } } // [3] //認証データが送信されているか header('WWW-Authenticate: Digest realm="'.$realm.'", nonce="'.uniqid(rand(),true).'", algorithm=MD5, qop="auth"'); header('HTTP/1.1 401 Authorization Required'); header('Content-type: text/html; charset='.CHARSET ); die($failed_text); } ----------------------------------------------------------------------- index.php より 上記関数 digest_auth() を含む degest.php へリンクさせ，ログイン及び認証させています． degest.php では”ログアウト”を index.php へリンクさせ，戻る仕様としています． ここで，一度ログアウトした際に，認証データがクライアント側にあるため，再度 index.php よりログインする際，プログラム中の[1] や [2] により処理され，入力ダイアログ[3]は出てきません． ブラウザを閉じることで，認証データ（セッション？）が消え，ログアウトしたことになるということは見つけましたが，今回は認証データを任意に消したいというものです． ログアウトした際に，クライアント側のセッション情報を消せばよいのかとおもい，ログアウト先の index.php 内で以下の処理を行ってみました． URL: http://www.php.net/manual/ja/function.session-destroy.php ----------------------------------------------------------------------- (文字数制限のため省略) リンク先 "例1" ---------------------------------------------------------------------- しかし，うまくログアウトすることができませんでした．つまり，入力ダイアログ[3]が表示されませんでした． また，$_SERVER['PHP_AUTH_DIGEST']の値がセッション情報から得られいて，セッション情報を消しても，[1]によりヘッダー情報から$_SERVER['PHP_AUTH_DIGEST']の情報を補っているためかとおもい，[1]を消してから再度トライしてみましたが，やはりダメでした． 確認だけで当たり前の現象ですが，[1]を消して，さらにunset($_SERVER['PHP_AUTH_DIGEST'])を最初に行うことで認証情報を消し，再度入力ダイアログが現れる現象を確認しました． （もちろん，正しい値を入力してもまた聞かれる状態です．．） 現時点では，なんらかの方法により，クライアント側の認証データ（セッション？）を消すことで，ログアウトができると考えています． 以上より，今回用いているダイジェスト認証処理を行った後のログアウト処理方法についてどなたか御教授ください． よろしくお願いします．
- ベストアンサー
- ネットワーク
- SESSION機能を使ったログイン認証
SESSION機能を使ってログイン認証をＰＨＰで作りたいのですが・・・ いろいろなサイトを回ってみてもＰＥＡＲを使ったものやBASIC認証のものばかりでどうも・・・うまくいかないのです。 何かやり方もしくはいいサイトご存知でしょうか？ ・ｄｂにあるパスワードとメールアドレスを入力したパスワードとメールアドレスに照合したもの ・パスワードとメールアドレスに合った会員の方の名前を「ようこそ○○さん」と表示したい
- ベストアンサー
- PHP
- Digest認証で、グループウェアは守られますか？
こんばんは。 いま、小規模グループウェアを構築中です。一般的なレンタルサーバーにphpGroupWareを置いて使っています。サーバーはＳＳＬ対応ですが、諸事情でＳＳＬ通信は使えません！ そこで、Digest認証を考えています。Digest認証を使えば非SSL環境で通信が盗聴されたとしてもパスワードは一般的に流出しませんよね？ その後、phpGroupWareのIDとパスワードも盗聴されたとします。そのIDとパスワードを入力する画面に辿り着く前にDigest認証でブロックされる。 →よって非ＳＳＬでもDigest認証を掛ければ安全！ というのは正しい認識でしょうか？ その時にphpGroupWareで表示した情報は盗聴されると思いますが、それは考慮しません。もちろんＭＤ５も日が経てば安全性には疑問が出てきたり、また盗聴ではなくキーロガーを仕掛けられたら元も子もないですが、そういう可能性は無視でお願いします。あくまでもネットワーク盗聴についてでお願いします。 それでは、よろしくお願いいたします。
- ベストアンサー
- ネットワーク
- ログイン認証ができません！！
下記のようなメッセージが画面に書かれているのですが、クッキーを受け入れるにしてもログイン認証できないのですが、どのようにすればいいのでしょうか？ ～メッセージ～ セッション管理にクッキーを使用しています。ブラウザがクッキーが受け入れるように設定してください。 ログイン後、サーバーとの無通信状態が一定時間続くか、ブラウザを終了すると自動的にログアウト処理されます。 パスワードを一定回数連続で間違えた場合、同一IPからの認証は一定時間はできなくなります。
- 締切済み
- その他（インターネット接続・通信）
- SSLで、セッションを保ちたい。
PHPでコミュニティサイトのようなものを作っているのですが、個人情報もある程度扱うことになっているため、SSLを導入することになりました。 そこで、とりあえずレンタルサーバの無料サービスである、共有認証SSLを用いて、ログインや住所登録をしてもらうことにしようと思ったのですが上手くいきません。 やりたいことは、ログインのときや、住所登録（または変更）のときだけSSL通信にして、そのほかの会員制の掲示板への書き込みなどは、普通にhttpでやりたいのですが、色々試していると、どうもSSL(https)から、普通のhttpに戻るときに、セッション変数が持ちまわせていないことが原因だと分かってきました。 アドレスは以下のような感じなので、 http://www.example.com/ https://userID.securesites.com/ おそらく見えるファイルはどちらも同じなのですが、実質的に別サーバ扱いであるために、セッション変数が持ちまわせないのかな？という風に今は考えています。 この推測は正しいでしょうか？ セッション変数を持ちまわすには、独自認証SSLにすれば解決するのでしょうか？？ 独自認証SSLの場合アドレスでいうと、以下のようなものになります。 https://www.example.com/ また、共有認証でも、ログイン後、httpに戻ったときにちゃんとログインした状態を保持する方法はありますか？ その他、セッションハイジャックの対策など、注意すべき点などがございましたら、ご教授お願いします。よろしくお願いします。
- 締切済み
- PHP
- Basic認証のログアウト
Basic認証のログアウト http://okwave.jp/friend.php3?q=1876674 この質問と同様ですが、 この回答からすると、一度Basic認証をすると、 Webブラウザを再起動する以外には、 特別なソフトウェアの使用が必要で、 クッキーなどのリセットだけでは駄目という理解で良いのでしょうか？
- ベストアンサー
- その他（インターネット接続・通信）
- basic認証でpop認証を利用
「basic認証」のIDパスワードに、どこかのメールサーバのpop認証を 使いたいと持ちかけられまして。 pop認証用のID/PWを取得してbasic認証用のデータを 作るとかなら分かるのですが、「htaccessにスクリプトを 仕込んでpop認証をできるのでは」と言われています。 basic認証（digest認証でもいいです）を他の認証システムと ダイレクトに連携する方法ってあるんでしょうか？ （個人的には無理だと思っているのですが．．．）
- 締切済み
- その他（プログラミング・開発）
- セッション脆弱性を克服するには？
またお世話になります。 いつも的確な回答を頂いて助かっていますm( __ __ )m 【仕様】 ・ ログイン認証ページのみ SSL で、それ以外のページは 【非SSL】 です。 ・ ログイン認証時にセッションIDをクライアントのクッキーに保存し、サーバー側では MySQL にセッションIDとログイン情報を保持します。 ・ 認証以降のページでは、クライアントから送信されてくるクッキーセッションIDを元に MySQL のデータと照合し、ユーザーのログイン状態を維持します。 ・ 言語は PHP を使っています。 よくあるセッション管理サイトだと思います。 そして、セッションIDさえ盗まれなければセキュリティとして問題無いと考えています。逆に言うとセッションIDが盗まれると極端に弱いと思います。 【私の考える脆弱性】 ・ ログインページ以外が 非SSL ということから、セッションIDの盗聴が可能かと思います。 ・ 普通に使用していても悪意あるサーバーを経由したらトレースされて簡単にセッションIDが抜かれると思います。 ・ ログインした状態のユーザーが怪しいリンクをクリックしてクロスサイト攻撃でクッキーを抜かれる可能性もあります。 質問は、なぜ、こういった多くの問題が予測できるのに この「教えて！Goo」の認証もログインページはSSLですが、それ以外は非SSLです。といった具合に多くのサイトがこのような認証方式を取っているのか？ もう一つ質問は、私は先に上げたような脆弱性を防ぐ方法がわからないのですが、何か画期的な方法でセッションハイジャックなどを防御しているのでしょうか？ もしくはセッションIDが盗まれてもそのセッションIDでのアクセスを無毒化するような方法があるのでしょうか？ 以上です。 よろしくお願いします。
- ベストアンサー
- ネットワーク
お礼
なるほど。変則的な方法ですがBASIC認証を使い続けるなら、こういう方法しかないかもしれないですね。 再ログインのダイアログは、できれば避けたいですし。 どうもありがとうございました。