Firesheep問題への対応方法，セッション鍵をハッシュ関数＋Saltでワンタイムパス化．

とりあえずは暫定で書いてみよう．
この対策はJavaScriptが使える環境でないと無理な上に，うまく実装しないときっとバグるし，現実的かはわからない．
でもきっと全部SSLになったらそれはそれでコストがしんどいもんね．
あそうかCookieのとなりにセッション鍵管理のプロトコル仕様・・・（ｒｙ．

セッション鍵が盗まれるとあっという間にパクられる．→セッション鍵を盗まれなければいい，か，セッション鍵がワンタイムであればいい．

どういうことか．

学校の講義で出てきたワンタイムパスワード「S/Key」方式を思い出した．これは，元のパスワードを99回とかの多い回数でハッシュ関数にかけた暗号化パスと，その回数を（初期化時に）サーバ側に送信し，手元に元のパスワードを保存しておく．サーバは保存してある暗号化パスよりも，ハッシュ関数が1回少ない暗号化パスを送れとクライアントに要求し，クライアントは元のパスワードをサーバから指示された回数だけハッシュ関数にかけて送信する．サーバは，送られてきた暗号化パスにさらに1回ハッシュ関数をかけて，保存されている暗号化パスと比較し，同じであれば認証し，送られてきた暗号化パスとそのハッシュ回数を保存し，元の暗号化パスは捨てる．
http://okaweb.ec.kyushu-u.ac.jp/lectures/ds/98-Reports/tumura.html

まぁ，この最初のパスそのものをネットワークに送信しないって言うのや，ハッシュ関数に99回もかけるとかいうのは，やりすぎってことで・・・．

簡単にいくと，最初のSSL通信で，あらかじめセッションID，Salt（乱数）を共有しておく．SSL保護からはずれた後，サーバは次のリクエストの際に，前のセッション鍵＋Saltのデータに1回ハッシュ関数をかけた値を，そのセッションIDに対応するセッション鍵として期待しておく．クライアントはJavaScriptを使って，リクエスト送信直前，またはレスポンス受信直後（こっちはキャッシュとかもあるし可能なの！？）に，次のセッション鍵を計算してCookieに格納しておく．次回のアクセスの際には，そのセッション鍵が用いられる．これによってセッション鍵を，Saltという共有知識を使って，ワンタイムパス化することができるのでは．

1回目のセッション鍵はSaltに1回ハッシュ関数をかけただけのものが使われるかもしれないけど，（その辺もし危険だったとしたら）必要に応じて乱数＋Saltとかにすればよいと思う．また，サーバとクライアントでハッシュ回数の同期がとれないかもな問題に関しては，サーバ側の方が多くハッシュを行っているのはまぁ普通おかしいのでエラーにするとして，クライアント側からハッシュしたトータル回数をリクエスト時に送信して，もしサーバ側のほうが少ない回数だったらそれに追いつくようがんばってサーバが計算するようにする．あまりにも大きい回数を指定されるとDoS攻撃になるかもしれないので，許容範囲を決めておき，同期されてなさが度を越えている場合はエラーにすればよい．

というのが私が考えた対策．わかりづらいとか，それではダメっぽいというのは意見をください・ｗ・！

ん？まてよ・・・そういえば，Cookie以外の「サーバに決して送信されない」Saltのためのストレージが存在しない気がする・・・；ｗ；