== はじめに ==
パスワード管理の方法と、パスワードを入手された時の問題点を整理してみましょう。パスワード管理の方法と、パスワードを入手された時の問題点を整理してみましょう。その前に、パスワードに ''123456'' や ''password'' といったものやアカウント名 ''admin'' でパスワードが ''admin'' といったものを使っている「これはひどい」といいたくなるパスワードでは、さしたる事前の準備も必要なく、いくつか試せばいいので、いくらパスワードの管理をシステム側で頑張っても無理なのはいうまでもありません。
その前に、パスワードに123456やpasswordといったものやアカウント名adminでパスワードがadminといったものを使っている「これはひどい」といいたくなるパスワードでは、さしたる事前の準備も必要なく、いくつか試せばいいので、いくらパスワードの管理をシステム側で頑張っても無理です。
これはさすがに、ウカツなパスワードとしか呼びようがありませんが、これはユーザだけが悪いわけではなく、システムがこのようなパスワードを許容すること自体が、システムの欠陥だと私は思います。最近のシステムではユーザがパスワードを選ぶ際に一定の強度を満たしていない場合は警告を出したり受け付けないといったものも多く、ずいぶんと状況は改善されつつあります。これはさすがに、愚かなパスワードとしか呼びようがありませんが、これはユーザだけが悪いわけではなく、システムがこのようなパスワードを許容すること自体が、システムの欠陥ともいえます。最近のシステムではユーザがパスワードを選ぶ際に一定の強度を満たしていない場合は警告を出したり受け付けないといったものも多く、ずいぶんと状況は改善されつつあります。
ある程度の複雑さをもったパスワードに関しては、これはパスワード管理ファイルをサイトから流出させ、専用のコンピュータを用意してパスワードを見つける処理を行うというのが前提となります。 2012年に発生した45万件のパスワードを流出させた[http://www.zdnet.com/the-top-10-passwords-from-the-yahoo-hack-is-yours-one-of-them-7000000815/ Yahooのケース]、2013年に発生した3,800万件のパスワードを流出させた[http://www.zdnet.com/adobe-admits-2-9m-customer-accounts-have-been-compromised-7000021546/ Adobeのケース]などがこれにあたります。
以下に3つのパスワード管理のパターンを説明し、次に、どのような方法でパスワードを見つけていくかの説明を加えます。ある程度の複雑さをもったパスワードに関しては、これはパスワード管理ファイルをサイトから流出させ、専用のコンピュータを用意してパスワードを見つける処理を行うというのが前提となります。 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|300px450px|thumb|right|保存されているパスワードは保護されない]]
パスワード認証というと、ユーザからの入力の文字列と、既に登録しているパスワードの文字列を突き合わせることだと思っている人も意外といるのではないかと思います。
簡単に実装することができますが、ただし、このパスワードファイルが外部に流出した時点で、サービスの存続にかかわるレベルで、システム全体のユーザ認証が崩壊します。なぜならば、そのままの形ですべてのパスワードを利用することが出来るからです。
ファイルへのアクセスをコントロールすることで安全性を保っていると理解してしまう人がいるでしょうが、逆をいえば、それだけしか保護をしておらず、情報流出する可能性の前提に立っていません。潜在的に1つのエラーがシステム全体をカタストロフな状態に導く可能性がある脆弱な状態におかれています。
このシステムは、大きな問題をはらんでいるのは、改めて強調しなくとも多くの方には理解されているだろうと思います。その一方で、このようなシステムは、そんなに多くはないだろうと楽観的に考えるかも知れません。でも、パスワードを忘れたときに親切にも元々のパスワードを教えてくれるタイプのシステムは、まわりを見渡せばけっこうあるはずです。
* 欠点: パスワードファイルが流出するとユーザ認証は壊滅的なダメージとなる。
=== 一方向性ハッシュ関数を導入し管理する ===
[[ファイル:Pwd-pic-2.png|450px|thumb|right|一方向性ハッシュ関数のみ導入]]
=== 一方向性ハッシュ関数を導入する ===
[[ファイル:Pwd一方向性ハッシュ関数とは、値xに対しハッシュ関数Hを用いて計算した値H(x)から、逆をたどってxを見つけることは極めて困難であるという性質を持つ関数です。一方向性ハッシュ関数にはSHA256、SHA512といったものだけではなく、共通鍵暗号を使ったメッセージ認証コードなども同様に使えます。たとえば古典的UNIXのパスワード生成にはDES暗号を使っているDES-picCBC-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-2asia00.png|300px|thumb|right|一方向性ハッシュ関数のみ導入]]ps</ref>というメッセージ認証コード法が使われています。
一方向性ハッシュ関数とは、値xに対しハッシュ関数Hを用いて計算した値H(x)から、逆をたどってxを見つけることは極めて困難であるという性質を持つ関数です。一方向性ハッシュ関数にはSHA256、SHA512といったものだけではなく、暗号化関数を使ったメッセージ認証コードなども同様に使えます。たとえば古典的UNIXのパスワード生成にはDES暗号を使っているDES-CBC-MACというメッセージ認証コード法が使われています。
よく「パスワードを暗号化」するという表現を使うので、暗号化するなら、復号もできるだろうと類推してしまいそうになりますが、これは一方向にしか計算できません。
パスワードを入力し、それを一方向性ハッシュ関数で計算した値を、事前に登録しておいた一方向性ハッシュ関数で計算した値と比較します。たとえば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>は、この方式です。
生の文字列を持っている先ほどの方法よりは格段に安全性は上がりますが、例えば同じ入力のものは同じ出力値を持ってしまう弱点を持っています。そのため辞書に載っているようなパスワードであれば、事前に処理してハッシュ値辞書を作成することが出来きます。つまり、辞書攻撃には極めて脆弱なパスワードシステムだといえます。
辞書を作るのに膨大な時間がかかると考えるかも知れませんが、英数字8文字のすべての文字の組み合わせのための逆引き辞書を 作るのに秋葉原で手に入る機材レベルで30時間もあれば十分作成できます。しかも辞書を作るのに膨大な時間がかかると考えるかも知れませんが、英数字8文字のすべての文字の組み合わせのための逆引き辞書を作るのに秋葉原で手に入る機材レベルで30時間もあれば十分作成できます。しかも[http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/ ophcrack]<ref>Philippe Oechslin,''Making a Faster Crytanalytical Time-Memory Trade-Off'', Advances in Cryptology - CRYPTO 2003, 23rd Annual International Cryptology Conference, Santa Barbara, California, USA, August 17-21, 2003, Proceedings. Lecture Notes in Computer Science 2729 Springer 2003, ISBN 3-540-40674-3</ref>サイトでは既にWindows XPやVistaのための辞書テーブルが既に用意されており、それを使えば検索成功率99パーセントだそうです。
先ほどの紹介したAdobeの流出したパスワード情報は、このタイプで、さらに悪いことには、ユーザが入力するパスワードのヒント情報も入っており、そこからまず類推可能なパスワードを探し当て、次に同じパスワードを持つユーザをピックアップしてゆくということが出来てしまうという、極めて憂慮すべきシステムでした。
* 利点: パスワードを見つけるためにはパスワード解析をする必要がある。
* 欠点: 同じパスワードは同じ出力なので事前に辞書を作ることが可能。
=== さらにソルトを加えたてパスワード管理する ===
[[ファイル:Pwd-pic-3.png|450px|thumb|right|Salt(ソルト)を加えることにより同じパスワードの類推を困難にする]]
=== ソルトを加えたパスワード管理 === 一方向性ハッシュ関数だけだと逆引きの攻撃辞書が使えるので、それを困難にするようにソルト(salt)と呼ばれる、ユーザ毎に異なるランダムな値を加えたのちに一方向性ハッシュ関数に入力する方法をとります。
[[ファイル:Pwd-pic-3.png|300px|thumb|right|Salt(ソルト)を加えることにより同じパスワードの類推を困難にする]]
一方向性ハッシュ関数だけだと逆引きの攻撃辞書が使えるので、それを困難にするようにソルトこのソルトは隠さなくてもかまいません。長ければながいほど逆引きの攻撃辞書のサイズが巨大になります。ソルトはランダムデータですが、そんなに大きなものは必要なく70年代では12ビット程度が使われており、もし将来的(saltといっても2020年あたりまで)と呼ばれる、ユーザ毎に異なるランダムな値を加えたのちに一方向性ハッシュ関数に入力する方法をとります。にも使うと考えるとしても64ビット(8バイト)程度あれば十分でしょう。
このソルトは隠さなくてもかまいません。長ければながいほど逆引きの攻撃辞書のサイズが巨大になります。ソルトはランダムデータですが、そんなに大きなものは必要なく70年代では12ビット程度が使われており、もし将来的にも使うと考えるとしても64ビット(8バイト)程度あれば十分でしょう。
古典的なUNIXのパスワード処理法では、さらに一方向性ハッシュ関数を複数回呼び出し計算時間をより多くかけさせるという手法を使っています。ただし一度に多数のユーザの対応をしなければならないようなシステム、例えばウェブサイトのパスワード認証などで行うのは、認証するサーバー側に負荷がかかりすぎる可能性があるので、本当にこの手法を選択すべきかどうかは熟慮が必要です。基本的には、複雑さを増すにはパスワードに使える文字種類を多くしたり、文字数を増やすことが重要です。
これでやっと普通のパスワード管理の基準を満たすことができます。ここでの普通っていうのは、ただ単純に数として多くあるいう意味ではなく、理想に近い意味での普通です。 (cfこれでやっと普通<ref>ここでの普通は、ただ単純に広く使われているという意味ではなく、「[https://www. Dream Fighter by Yyoutube. Nakata)com/watch?v=rBX5YGPNDbs&t=43s 真ん中ではなく理想に近い]」という意味です。 </ref>のパスワード管理の基準を満たすことができます。
* 利点: 事前のパスワード解析を無効にできる。
* 欠点: なし（現状で必要な条件は満たしている）。 == 最後に == 最初にいったことの繰り返しになりますが、パスワード方式そのものの弱点は利用者がたとえば''qwert''とか''99999''といった愚かなパスワードをつけてしまうと意味がなくなることです。どんなにシステム側でパスワードを保護していても、人間側が愚かなパスワードを使えばなんの意味も成しません。近年の各種 GNU/Linux ディストリビューションでは包括的なパスワード認証のためのフレームワークとして [http://www.linux- (必要な基準は満たしている。）pam.org/ Linux-PAM] を採用しています。これには弱いパスワードを受け付けないといった機能も入っています。このように人間側に対しても色々な工夫をしなければ、パスワード方式は安全とはいえません。人的リソースを管理をするのもオペレーティングシステムの重要な役割の1つです。また、あちらこちらのパスワード認証でパスワードを使いまわしているユーザもいます。どこか1つが破られたら、パスワードの使い回しているアカウントは次々に破られていきます。 では、すべてのアカウントですべて異なる複雑なパスワードを使えば良いのでしょうか？残念ながら、人間はそんな記憶力はありません。そしてそのような方式を導入して問題をユーザのパスワード管理や運用の不備に責任転嫁するのは正しいアプローチだとはいえません。パスワード認証方式を取り巻く問題は色々な面で問題が浮き彫りになってきているのが現状です。今後、パスワード認証方式がどれだけ生き残れるのか、あるいは生き残り続けるとして、どのような運用をすれば良いのか、そもそもパスワード認証方式の代替案があるのか、そしてまたそれは普及するのか、などなど問題は山積しているといっても過言ではないでしょう。 == 脚注 ==<references/> ----[[目次]]へ このページへのショートURL: http://uc2.h2np.net/i/8b.html
