1.id、passを入力して認証、ログインしている間ずっとPOSTでidpassをランダムにいじって作ったオリジナル変数を引き継いでいく手法
2.id、passを入力して認証、クッキーにセッションidもしくはそれっぽいものを保存して確認する手法
2がphpでは一般的な手法だと思いますが、この二つの方法でのメリットデメリットをセキュリティ方面で教えてください。
できればデメリットを中心に教えてもらえると助かります。
1のidpassをランダムにいじって作ったオリジナル変数(イメージ)
$subid=md5($id+$pass);
$subid=substr($subid,1,5);
if($subid==$_POST['subid']){}
2の手法では,セッションID をアクセスごとに変える事によって,ワンタイムのセッションキーとして使えるため,多少安全性が高められます.
1の手法であっても,セッションキーを使う形にすれば,同レベルの安全性が得られますが,POST で送るという制約から,単純な a タグのリンクは使えなくなります.(JavaScript を使う場合を除く)
2のデメリットは,実際のセッション情報は,セッションキーに基づいた DB (通常はファイルベース)を持っている事で,ここのセキュリティが脆弱では,すべてのセッション情報を見られてしまいます.
また,取り扱うセッション数が多くなると,この DB の速度がネックになってきます.(ラッパーをかませて,RMDBS で取り扱う事も可能です)
また,Cookie を使うと,cookie に対応していないエージェント(携帯電話など)では使えません.
2の手法では,セッションID をアクセスごとに変える事によって,ワンタイムのセッションキーとして使えるため,多少安全性が高められます.
1の手法であっても,セッションキーを使う形にすれば,同レベルの安全性が得られますが,POST で送るという制約から,単純な a タグのリンクは使えなくなります.(JavaScript を使う場合を除く)
2のデメリットは,実際のセッション情報は,セッションキーに基づいた DB (通常はファイルベース)を持っている事で,ここのセキュリティが脆弱では,すべてのセッション情報を見られてしまいます.
また,取り扱うセッション数が多くなると,この DB の速度がネックになってきます.(ラッパーをかませて,RMDBS で取り扱う事も可能です)
また,Cookie を使うと,cookie に対応していないエージェント(携帯電話など)では使えません.
ありがとうございます。
>セッションキーに基づいた DB (通常はファイルベース)を持っている事
iniの設定を変えて場所を変えるとか、いろいろやれば安全性を高められそうですね。
1.
hiddenを簡単に盗める
2.
セッションハイジャックの危険性があります。
セッションIDを予想し、直接指定してアクセスすることができます。
もしくは通信中の傍受ですとか、キャッシュやクッキーなどから確認されてしまう
恐れがあります。(運用側の問題も含めて)
SSL等でリスクを軽減する事が可能ですが、
当然、個人情報の漏洩の可能性があります。
あとは、クッキーが使えない場合もありますので、
セッションをURLへの埋め込み、まわすのもありです。
1のhidden問題はパスワード認証のあとなので、どうかなーと思っているんです。
通信傍受されたりこっそり覗き見されなければ硬いんじゃないかと。
2は予測できない13行ぐらいのランダム噛ませれば盗まれない限りほぼ不可能になると思っています。
「1」は id、pass が変わらない限りオリジナル変数が変わらないのがデメリットです。
このオリジナル変数が第三者に知れてしまうと、オリジナル変数を使って第三者がログインできてしまいます。
「2」のセッションIDを使う方法だと、セッションIDの有効期限を設ければ、セッションIDが第三者に知れてしまっても有効期限が切れれば第三者はログインできなくなります。
1は上の方と同じくどーかなとおもってます。対応はもちろんしますけど。
2の有効期限は難しいですね。いつも悩みます・・・何分にするかと。
2のデメリットで
仮にセッションidの中にユーザーのログイン情報等があると、
URLにセッションidをつけるだけで、そのユーザーでログインしてる状態になりますね。
ありがとうございます。ハイジャックですね。
ありがとうございます。
>セッションキーに基づいた DB (通常はファイルベース)を持っている事
iniの設定を変えて場所を変えるとか、いろいろやれば安全性を高められそうですね。