差分
/* 最後に */
== はじめに ==
ある程度の複雑さをもったパスワードに関しては、これはパスワード管理ファイルをサイトから流出させ、専用のコンピュータを用意してパスワードを見つける処理を行うというのが前提となります。 2012年に発生した45万件のパスワードを流出させた[http://www.zdnet.com/the-top-10-passwords-from-the-yahoo-hack-is-yours-one-of-them-7000000815/ Yahooのケース]<ref>Emil Protalinski,''The top 10 passwords from the Yahoo hack: Is yours one of them?'',ZDNet,July 12, 2012,http://www.zdnet.com/article/the-top-10-passwords-from-the-yahoo-hack-is-yours-one-of-them/</ref>、2013年に発生した3,800万件のパスワードを流出させた[http://www.zdnet.com/adobe-admits-2-9m-customer-accounts-have-been-compromised-7000021546/ Adobeのケース]<ref> Rachel King,''Adobe admits 2.9M customer accounts have been compromised'',ZDNet, October 3, 2013,http://www.zdnet.com/article/adobe-admits-2-9m-customer-accounts-have-been-compromised/</ref>などがこれにあたります。
以下に3つのパスワード管理のパターンを説明し、次に、どのような方法でパスワードを見つけていくかの説明を加えます。
== 管理方式からパスワード方式を分類してみる===== パスワードを防御なしに管理 パスワードを防御なしに管理する ===
[[ファイル:Pwd-pic-1.png|450px|thumb|right|保存されているパスワードは保護されない]]
* 欠点: パスワードファイルが流出するとユーザ認証は壊滅的なダメージとなる。
=== 一方向性ハッシュ関数を導入する 一方向性ハッシュ関数を導入し管理する ===
[[ファイル:Pwd-pic-2.png|450px|thumb|right|一方向性ハッシュ関数のみ導入]]
一方向性ハッシュ関数とは、値xに対しハッシュ関数Hを用いて計算した値H(x)から、逆をたどってxを見つけることは極めて困難であるという性質を持つ関数です。一方向性ハッシュ関数にはSHA256、SHA512といったものだけではなく、暗号化関数を使ったメッセージ認証コードなども同様に使えます。たとえば古典的UNIXのパスワード生成にはDES暗号を使っているDESから、逆をたどってxを見つけることは極めて困難であるという性質を持つ関数です。一方向性ハッシュ関数にはSHA256、SHA512といったものだけではなく、共通鍵暗号を使ったメッセージ認証コードなども同様に使えます。たとえば古典的UNIXのパスワード生成にはDES暗号を使っているDES-CBC-MACというメッセージ認証コード法が使われています。MAC<ref>D. Wagner and I. Goldberg. ,''Proofs of security for the UNIX passwordhashing algorithm.'',Advances in Cryptology – ASIACRYPT ’00, Lecture Notes in Computer Science Vol. 1976,T. Okamoto ed., Springer-Verlag, 2000. http://www.cs.berkeley.edu/~daw/papers/crypt3-asia00.ps</ref>というメッセージ認証コード法が使われています。
よく「パスワードを暗号化」するという表現を使うので、暗号化するなら、復号もできるだろうと類推してしまいそうになりますが、これは一方向にしか計算できません。
パスワードを入力し、それを一方向性ハッシュ関数で計算した値を、事前に登録しておいた一方向性ハッシュ関数で計算した値と比較します。たとえばWindowsXPなどで使っていたLMハッシュ(LAN Manager hash)<ref>''Network security: Do not store LAN Manager hash value on next password change'',November 15, 2012,https://technet.microsoft.com/en-us/library/jj852276</ref>は、この方式です。
* 欠点: 同じパスワードは同じ出力なので事前に辞書を作ることが可能。
=== ソルトを加えたパスワード管理 さらにソルトを加えたてパスワード管理する ===
[[ファイル:Pwd-pic-3.png|450px|thumb|right|Salt(ソルト)を加えることにより同じパスワードの類推を困難にする]]
* 利点: 事前のパスワード解析を無効にできる。
* 欠点: なし(現状で必要な条件は満たしている)。 == 最後に == 最初にいったことの繰り返しになりますが、パスワード方式そのものの弱点は利用者がたとえば''qwert''とか''99999''といった愚かなパスワードをつけてしまうと意味がなくなることです。どんなにシステム側でパスワードを保護していても、人間側が愚かなパスワードを使えばなんの意味も成しません。近年の各種 GNU/Linux ディストリビューションでは包括的なパスワード認証のためのフレームワークとして [http://www.linux- (必要な基準は満たしている。)pam.org/ Linux-PAM] を採用しています。これには弱いパスワードを受け付けないといった機能も入っています。このように人間側に対しても色々な工夫をしなければ、パスワード方式は安全とはいえません。人的リソースを管理をするのもオペレーティングシステムの重要な役割の1つです。また、あちらこちらのパスワード認証でパスワードを使いまわしているユーザもいます。どこか1つが破られたら、パスワードの使い回しているアカウントは次々に破られていきます。 では、すべてのアカウントですべて異なる複雑なパスワードを使えば良いのでしょうか?残念ながら、人間はそんな記憶力はありません。そしてそのような方式を導入して問題をユーザのパスワード管理や運用の不備に責任転嫁するのは正しいアプローチだとはいえません。パスワード認証方式を取り巻く問題は色々な面で問題が浮き彫りになってきているのが現状です。今後、パスワード認証方式がどれだけ生き残れるのか、あるいは生き残り続けるとして、どのような運用をすれば良いのか、そもそもパスワード認証方式の代替案があるのか、そしてまたそれは普及するのか、などなど問題は山積しているといっても過言ではないでしょう。
== 脚注 ==
----
[[目次]]へ
このページへのショートURL:
http://uc2.h2np.net/i/8b.html