以下のCookieを使ってログインを維持する仕組みはセキュリティの観点から問題ありますでしょうか？
●ログインプロセス
１）ユーザーがIDとパスワードを入力
２）DBを照会し、合っていた場合はハッシュキーを発行。
DB側にそのハッシュキーを維持
３）２）で発行したハッシュキーをユーザーに対してCookieで付与
ログイン完了
●ログイン確認プロセス
１）Cookieに文字列があるか確認
２）文字列がある場合はその文字列をDBから検索
３）文字列がDBに保存されている場合、新しいハッシュキーを発行し、DBとユーザーのCookieを更新。ログインOKと表示。
文字列がDBに保存されていない場合はログインしていないと判断。
この場合、ログイン維持に全てCookieを利用しており、セッションは使っていません。
ユーザーは毎回アクセスする度にCookieで保持しているハッシュキー（Token）が更新され一応これでセキュリティは保持しているつもりです。
大きな欠陥などあれば教えてください。
No.1
377
98
100pt
ログインプロセスの２）で，ハッシュキーはどうやって計算しますか？
ハッシュキーが予測可能だと，それがセキュリティホールになります
いわゆるセッションを自前で実装したように見えますが，なぜPHP標準のセッションを使わないのでしょうか？
39
39
1
1
横からですが。
2016/07/16 13:59:27sessionもキー(sid)を共有するのにcookieを使ってますよ。
そのため、改竄が無意味となるようランダムキーを使うわけで。
今回のはセッション機構の一部を自前で構築しようという話ですが、通常はこなれているphpのsessionを使った方が穴が少ない気がします。
ただ、phpのsessionも多数の環境で動くように妥協したり、汎用性を持たせるために複雑な部分があるので、単純で見通しの良い実装を慎重に構築すれば性能もセキュリティも確保出来るかもしれません。
でも出来ないかもしれません。
そこまでセキュリティに気を使うのであれば専門書やこなれた実装を探す方が良い様に思います。
それに、穴はこういった部分にもありますが、ユーザー側の取扱いとかサーバへの物理アクセスとか他にも大穴が開いている事も珍しくないですし、トータルで考えないと無意味になってしまいますよ。
DBに保存されたハッシュキーを削除する条件はどうなっているのでしょう。
2016/07/18 16:54:51クライアントがもう使っていないハッシュキーがDBに存在し続けるとDB内に
大量のハッシュキーがたまってしまい攻撃に対して弱くなってしまうように思います。