差分

移動先: 案内、 検索

システムにおけるパスワード管理の概要

2,291 バイト追加, 2018年7月4日 (水) 16:31
/* 最後に */
== はじめに ==
パスワード管理の方法と、パスワードを入手された時の問題点を整理してみましょう。その前に、パスワードに123456やpasswordといったものやアカウント名adminでパスワードがadminといったものを使っている「これはひどい」といいたくなるパスワードでは、さしたる事前の準備も必要なく、いくつか試せばいいので、いくらパスワードの管理をシステム側で頑張っても無理です。パスワード管理の方法と、パスワードを入手された時の問題点を整理してみましょう。その前に、パスワードに ''123456'' や ''password'' といったものやアカウント名 ''admin'' でパスワードが ''admin'' といったものを使っている「これはひどい」といいたくなるパスワードでは、さしたる事前の準備も必要なく、いくつか試せばいいので、いくらパスワードの管理をシステム側で頑張っても無理なのはいうまでもありません。
これはさすがに、ウカツなパスワードとしか呼びようがありませんが、これはユーザだけが悪いわけではなく、システムがこのようなパスワードを許容すること自体が、システムの欠陥だと私は思います。最近のシステムではユーザがパスワードを選ぶ際に一定の強度を満たしていない場合は警告を出したり受け付けないといったものも多く、ずいぶんと状況は改善されつつあります。これはさすがに、愚かなパスワードとしか呼びようがありませんが、これはユーザだけが悪いわけではなく、システムがこのようなパスワードを許容すること自体が、システムの欠陥ともいえます。最近のシステムではユーザがパスワードを選ぶ際に一定の強度を満たしていない場合は警告を出したり受け付けないといったものも多く、ずいぶんと状況は改善されつつあります。
以下に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
<ref>
D. Wagner and I. Goldberg. ,
* 欠点: 同じパスワードは同じ出力なので事前に辞書を作ることが可能。
=== ソルトを加えたパスワード管理 さらにソルトを加えたてパスワード管理する ===
[[ファイル:Pwd-pic-3.png|450px|thumb|right|Salt(ソルト)を加えることにより同じパスワードの類推を困難にする]]
このソルトは隠さなくてもかまいません。長ければながいほど逆引きの攻撃辞書のサイズが巨大になります。ソルトはランダムデータですが、そんなに大きなものは必要なく70年代では12ビット程度が使われており、もし将来的にも使うと考えるとしても64ビットこのソルトは隠さなくてもかまいません。長ければながいほど逆引きの攻撃辞書のサイズが巨大になります。ソルトはランダムデータですが、そんなに大きなものは必要なく70年代では12ビット程度が使われており、もし将来的(といっても2020年あたりまで)にも使うと考えるとしても64ビット(8バイト)程度あれば十分でしょう。
これでやっと普通のパスワード管理の基準を満たすことができます。ここでの普通っていうのは、ただ単純に数として多くあるいう意味ではなく、理想に近い意味での普通ですこれでやっと普通<ref>Perfume,''Dream Fighter'',Writer Yasutaka Nakata,Producer Yasutaka Nakata,Label Tokuma Japan Communications,TKCA-73390,November 19, 2008ここでの普通は、ただ単純に広く使われているという意味ではなく、「[https://www.youtube.com/watch?v=rBX5YGPNDbs&t=43s 真ん中ではなく理想に近い]」という意味です。 </ref>。 のパスワード管理の基準を満たすことができます。
* 利点: 事前のパスワード解析を無効にできる。
* 欠点: なし（現状で必要な条件は満たしている）。 == 最後に == 最初にいったことの繰り返しになりますが、パスワード方式そのものの弱点は利用者がたとえば''qwert''とか''99999''といった愚かなパスワードをつけてしまうと意味がなくなることです。どんなにシステム側でパスワードを保護していても、人間側が愚かなパスワードを使えばなんの意味も成しません。近年の各種 GNU/Linux ディストリビューションでは包括的なパスワード認証のためのフレームワークとして [http://www.linux- (必要な基準は満たしている。）pam.org/ Linux-PAM] を採用しています。これには弱いパスワードを受け付けないといった機能も入っています。このように人間側に対しても色々な工夫をしなければ、パスワード方式は安全とはいえません。人的リソースを管理をするのもオペレーティングシステムの重要な役割の1つです。また、あちらこちらのパスワード認証でパスワードを使いまわしているユーザもいます。どこか1つが破られたら、パスワードの使い回しているアカウントは次々に破られていきます。  では、すべてのアカウントですべて異なる複雑なパスワードを使えば良いのでしょうか？残念ながら、人間はそんな記憶力はありません。そしてそのような方式を導入して問題をユーザのパスワード管理や運用の不備に責任転嫁するのは正しいアプローチだとはいえません。パスワード認証方式を取り巻く問題は色々な面で問題が浮き彫りになってきているのが現状です。今後、パスワード認証方式がどれだけ生き残れるのか、あるいは生き残り続けるとして、どのような運用をすれば良いのか、そもそもパスワード認証方式の代替案があるのか、そしてまたそれは普及するのか、などなど問題は山積しているといっても過言ではないでしょう。
== 脚注 ==
----
[[目次]]へ
 
 
このページへのショートURL:
http://uc2.h2np.net/i/8b.html
「https://uc2.h2np.net/index.php?title=特別:携帯機器差分/1226...1478」から取得