パスワードの危機(その2) − あるべき姿

セキュリティの基本とはなんだろうか? コンピュータウィルス対策? ファイアウォール? プライバシーポリシー? 否。単純な話、 パスワードを正しく管理することがセキュリティの基本中の基本だ。 何をいまさらというかもしれないが、実は、Webが急速に普及したここ2,3年の間に パスワードの扱い方に関する これまで常識がいつのまにか忘れ去られようとしており、 いま、非常に危険な状況にある。

「パスワードは暗号化(ハッシュ化)して保存する =管理者にもわからない状態で保存する」 というのが本来あるべき姿なのだ。

詳しい説明に入る前に、用語説明と断りを書いておく。 暗号化はなんとなくわかっていただけると思うが ハッシュ化という単語にはなじみが無い人が多いだろう。

  • 暗号化とは?
    自由に決められる「鍵」を使い、文字や数値を ある一定の規則(暗号化関数という)で変換し、 一見では内容がわからない情報にすること。 「鍵」を知っている者はもとに戻して(復号化)内容を知ることができる
  • ハッシュ化とは?
    文字や数値をある一定の規則で変換すること。変換にはハッシュ関数、 別名一方通行関数を使う。 一方通行という名のとおり、変換されたものをもとに戻す手段は無い
    例えば、「abcd123」という文字列をMD5というハッシュ関数で変換し、 それを文字として表すと 「79cfeb94595de33b3326c06ab1c7dbda」となる。 この32桁の文字から元の「abcd123」を割り出す方法は無い (もしできたらNASAかCIAあたりからスカウトがくるだろう)。
このように、暗号化とハッシュ化は似てるが違う。 パスワードの保存に適しているのはハッシュ化のほうなのだが、 単に「ハッシュ化」と書いてもピンとこないと思われるため、 この先の話ではあえて「暗号化(ハッシュ化)」と書くことにする。

さて、話を戻そう。
IT関連技術者ではない一般ピープル(?)な人が想像する Webサイトにおける認証の仕組みとは、 たとえば次のようなものではないだろうか。

  1. ユーザーがユーザー登録(会員登録)する。 その際にユーザーIDとパスワードを登録する。 Webサイトはそれらをそのままデータベースに記録する。
  2. ユーザーがWebサイト上でIDとパスワードを入力する
  3. Webシステムは入力されたIDをもとにデータベースからパスワードを探し出す
  4. 入力されたパスワードと、データベースにあったパスワードを照らし合わせ、 合致すれば認証OK。間違っていれば「IDまたはパスワードが違います」を表示
一見すると当然と思える仕組みだが、重大な欠点がある。 データベースの閲覧権限のある管理者は ユーザーのパスワードを知ることができてしまうのだ。 本来のあるべき姿とは、次のような仕組みである。
  1. ユーザーがユーザー登録(会員登録)する。その際にパスワードを入力させるが、 Webサイトはパスワードを暗号化(ハッシュ化)してデータベースに記録する。
  2. ユーザーがWebサイト上でユーザーIDとパスワードを入力する
  3. Webシステムは入力されたIDをもとにデータベースからパスワードを探し出す
  4. 入力されたパスワードを暗号化(ハッシュ化)し、 データベースにあったパスワード=すでに暗号化(ハッシュ化)済み= と照らし合わせ、合致すれば認証OK。 間違っていれば「IDまたはパスワードが違います」を表示
この手法は次のような利点と欠点がある。
  • 管理者ですらユーザーのパスワードを知ることができないため安全性が高い。
  • 万が一会員データベースが漏洩しても、 パスワードは暗号化(ハッシュ化)されているので、 第三者にログインされてしまうといった最悪の事態を避けることができる。 (ただし誕生日だとか自分のイニシャルだとか類推しやすい簡単なパスワードを使った場合は別。 それはそんなパスワードを登録した人が悪い)
  • 管理者にもパスワードはわからないので、 「パスワードを忘れたのですがどうしたらよいのでしょう」 というユーザーに対しては新しいパスワードを発行して古いパスワードを上書きし、 新しいパスワードを安全な方法でユーザーに伝えなくてはならない。 データベース上のパスワードを見てそれを教えればいいという 簡単な方法ではないので業務がやや面倒になる。 (しかし安全性には変えられないはずだ
このようなパスワードの取り扱い方法は目新しいものでも複雑で高価なものでもなんでもない。 少なくとも10年、もしかしたら20年くらい前からある安価で安全性の高い手法であり、 現在でも多くのコンピュータシステムで利用されている。 ところが、前回の記事で書いたECサイトのように、 パスワードを暗号化(ハッシュ化)せず平文のままでデータベースに保存しているWebシステムが、 ここ2,3年の間に急増してしまった。 恐ろしいことに、それに対して違和感も危機感も感じられていない。 (次回に続く)

トラックバックURL

このエントリーのトラックバックURL:
http://www.ywcafe.net/mt/mt-tb.cgi/115

トラックバック

» BLOG IT! from パスワードの危機(その2) − あるべき姿 - Webビジネスコンサルタントのネタ帳 from masa's memo
パスワードの危機(その2) − あるべき姿 - Webビジネスコンサルタントのネタ帳暗号化とは?自由に決められる「鍵」を使い、文字や数値をある一定の規則(暗号化... 続きを読む

コメント

ハッシュ暗号は逆引き辞書で一応突破可能ですね。

パスワードは桁数を出来るだけ多くする、辞書に載っている単語(特に人名など)は避けるといった話はいまものこっていますが、桁数は兎に角、何故辞書に載っているような単語がダメなのか、最近余り語られていないような気がする今日この頃です。

ハッシュ化する事は当然大事ですが、
パスワードを再発行する際の本人認証をどうするかが問題です。
次回はその対応方法等について記していただけると有り難いです。(むしろ熱望)

パスワードを再発行する再の本人認証ですか・・・。
難しいですね。パスワードヒント方式がよく使われてるけど
「パスワードを忘れるような人はヒントも忘れる」
の法則があって(笑)、あまり役には立ちません。
アマゾンのパスワード再発行システムのように、
「メールはその人にしか読めない=
メールを読める人が本人だ」
という前提に基づいたフローを作るのが
現実的ではないかと。

ろばQさんも書かれていますが
>この32桁の文字から元の「abcd123」を割り出す方法は無い(もしできたらNASAかCIAあたりからスカウトがくるだろう)。
というあたりは、john the ripperで長時間かけてぶん回せば一瞬〜数分から宇宙の寿命以上までの時間で割り出すことが可能なので。
「現実的な時間で割り出すことが出来ればスカウトが来る」というニュアンスにしたほうが誤解が少ないかも。

コメントする

(初めてのコメントの時は、コメントが表示されるためにこのブログのオーナーの承認が必要になることがあります。承認されるまでコメントは表示されませんのでしばらくお待ちください)


画像の中に見える文字を入力してください。