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

PHP セキュリティ


以下のCookieを使ってログインを維持する仕組みはセキュリティの観点から問題ありますでしょうか?

●ログインプロセス
1)ユーザーがIDとパスワードを入力
2)DBを照会し、合っていた場合はハッシュキーを発行。
DB側にそのハッシュキーを維持
3)2)で発行したハッシュキーをユーザーに対してCookieで付与

ログイン完了

●ログイン確認プロセス
1)Cookieに文字列があるか確認
2)文字列がある場合はその文字列をDBから検索
3)文字列がDBに保存されている場合、新しいハッシュキーを発行し、DBとユーザーのCookieを更新。ログインOKと表示。
文字列がDBに保存されていない場合はログインしていないと判断。

この場合、ログイン維持に全てCookieを利用しており、セッションは使っていません。

ユーザーは毎回アクセスする度にCookieで保持しているハッシュキー(Token)が更新され一応これでセキュリティは保持しているつもりです。

大きな欠陥などあれば教えてください。

●質問者: webtomake
●カテゴリ:ウェブ制作
○ 状態 :終了
└ 回答数 : 1/1件

▽最新の回答へ

1 ● pyopyopyo
●100ポイント

ログインプロセスの2)で,ハッシュキーはどうやって計算しますか?
ハッシュキーが予測可能だと,それがセキュリティホールになります


いわゆるセッションを自前で実装したように見えますが,なぜPHP標準のセッションを使わないのでしょうか?


webtomakeさんのコメント
ハッシュキーはランダムで生成した値をハッシュ化していますので、とくに計算はしていません。あくまでも一定期間の通行手形みたいな感じで発行するパスコード的な役割を果たしています。 セッションを実装しない理由は、すでにCookieで十分機能が果たせているからだと思ったからです。セッションであってもCookieであっても、最終的な目的は同じですし、アクセスする度にCookie内のハッシュキーを変更すればセキュリティ面でのリスクも下がるので、これはセッションのsession.use_trans_sid = 0と同じかと思ったからです。こうなるとセッションを使う必要が無いような気がします。

pyopyopyoさんのコメント
ランダムに生成した数値をハッシュ関数で文字列に変換,ということですね. 文字列に規則性がなければ予測不可能なので安全だと思います あと「セッションであってもCookieであっても、最終的な目的は同じですし」とありますが,Cookieにはセキュリティー上の問題があるので,普通はセッションを使います. どういうことかというと,cookieはクライアント側で保持しますので,中身が簡単に改ざんできるのです.一方セッションはサーバー側で保持するので中身の改ざんが難しいです. PHPが標準でセッションを提供しているのもそのためです.

TransFreeBSDさんのコメント
横からですが。 sessionもキー(sid)を共有するのにcookieを使ってますよ。 そのため、改竄が無意味となるようランダムキーを使うわけで。 今回のはセッション機構の一部を自前で構築しようという話ですが、通常はこなれているphpのsessionを使った方が穴が少ない気がします。 ただ、phpのsessionも多数の環境で動くように妥協したり、汎用性を持たせるために複雑な部分があるので、単純で見通しの良い実装を慎重に構築すれば性能もセキュリティも確保出来るかもしれません。 でも出来ないかもしれません。 そこまでセキュリティに気を使うのであれば専門書やこなれた実装を探す方が良い様に思います。 それに、穴はこういった部分にもありますが、ユーザー側の取扱いとかサーバへの物理アクセスとか他にも大穴が開いている事も珍しくないですし、トータルで考えないと無意味になってしまいますよ。

tobeoscontinueさんのコメント
DBに保存されたハッシュキーを削除する条件はどうなっているのでしょう。 クライアントがもう使っていないハッシュキーがDBに存在し続けるとDB内に 大量のハッシュキーがたまってしまい攻撃に対して弱くなってしまうように思います。
関連質問

●質問をもっと探す●



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