Twitchで生放送中!

Twitchで生放送中!

はなげブログ

IT関連

SSLを使用せずに暗号化して通信するパスワード認証ページを作る

今まで、このブログの編集ページへのログインは、一切の暗号化をせずに通信していたんだが、
ためしにパスワードを暗号化させて送ってみたくなってやってみた。

PHPとJavascriptでチャレンジ・レスポンス方式のワンタイムパスワード認証をしてみた。
暗号化はSHA256を使用。

サンプルページ
http://hanagebigwave.6.ql.bz/chaptest/admin.php

にわか知識な私が作ったので、きっと問題を抱えているだろうな。
そういった意味でソースは公開しない。
(いや、公開しておかしい点を指摘してもらうのもいいかもしれない)

具体的には下の図のような処理をしている。



とりあえず、現時点でわかっている、今回の処置をしても改善されない脆弱性を挙げていく。

1. セッションハイジャック

ログインしていることをセッションが保持することになるが、(セッションIDをセッションCookieに記録させる際に)セッションIDが平文でユーザーに送られてしまうからパケット盗聴によるセッションハイジャックが可能という点は、暗号化しないページと変わらず。

ページが読み込まれるたびにsession_regenerate_idでセッションIDを変更するようにしているが、ユーザー がページを閉じた後は(ユーザーがログアウトをしてくれない限り)セッションIDは変わらないから最後のセッションIDを盗聴されていたとしたらセッションハイジャックが可能だろう。

ログインしたときのUAをセッションに保持させて、それと一致するかチェックする手法を併用してみたが、ターゲットとなるユーザーのUAを、クラッカーが知ることができれば余裕で通過できちゃうはず。

2. パケット改竄によるhtml書き換え

さらに、パケット改竄によりログイン画面のhtmlが書き換えられた場合には、平文のパスワードを送信させることが可能になってしまう。

3. ブルートフォースアタック

チャレンジコードとレスポンスコードが両方とも盗聴された場合を考慮して、
ブルートフォースアタック(総当り攻撃)されても問題ないような複雑である程度長いパスワードを用意しなければならない。

以上の点が、パスワードを暗号化しないで送信した場合と同様、改善されない問題点である。

今回の修正で改善されるのはせいぜい、
・パケット盗聴をされてもパスワードがばれない
・ユーザーの送信内容を傍受され同一の送信内容を盗聴者がサーバに送信したとしてもログインできない
という点だけであろう。

2012/07/24 追記
入力されたパスワードを暗号化した後削除してからフォームが送信される。
したがって、ブラウザにパスワードを保存させること(オートコンプリート)ができない。
パスワードをブラウザに記憶させたい派のユーザーからすれば不便である。なんとかしたい。
(ユーザーというのは自分しかいないのだが・・・)
投稿:2012/07/23 04:50
更新:2012/07/31 20:38

コメント(0)

名前
コメント