🚀 go-pugleaf

<692cac$7es$1@po.sumirin.co.jp>の記事において
kshimz@sfc.co.jpさんは書きました。

 | > # 暗号化されているというのはこの際問題にならないと思います。
 | 
 | それを言いだすと、SunOS 4.x などの /etc/passwd も同じなのでは ?
 | こちらの方が、ファイル名が公知なだけに問題は大きいと思いますが。

/etc/passwdですけど、確かに「暗号化されている」と表現される場合が
多いですし、その関数である crypt(3) の名称もそうですし、man page
見ても暗号化という表現をしていますが、実際には暗号(可逆性がある)
ではなく一方向ハッシュ(可逆性がない)です。

/etc/passwdファイルの第2フィールドの文字列から元の平文のパスワード
を得る方法はありません。
認証はユーザから入力された平文のパスワードを同じ一方向ハッシュ関数
に通し、その結果と保存してあるハッシュ値を比較することによって行い
ます。

認証システムにおいて、保存してあるパスワードデータベースから元の
平文のパスワードが得られないということはその安全上重要です。

もし平文のパスワードが何らかの方法で得られるのなら、管理者やその
システムを作った人(メーカとか)なら解かれてしまいます。このことは
オールマイティに解く方法があるということであり、こういう秘密は
不思議な事に広まって行くのが世の常であり、安全性ということを考え
た場合大きな問題になります。

# ソースコードが公開されているUNIX系OSのことを考えれば明白ですよ
# ね?

また、平文のパスワードを保存するのは危険だからといって、それを
暗号化しても、その暗号を解くための新たなパスワードをどこかに保存
しておかなくてはいけなくなりますから、この方法では解決されません。

実際認証システムにおいては、このサーバ側に平文のパスワードを保存
しなくて済むアルゴリズムをなんとか見つけようと苦心惨澹しているよ
うで、ワンタイムパスワードでのチャレンジ・レスポンス方式
(POPのAPOP認証など)とランポート方式(opieなど)を比較してみると
面白いかもしれません。

さて、問題になっているクライアントにパスワードを保存することです
が、これはすべてセキュリティ上問題があります。
それは原理的にパスワードの可逆性を必要とせざる得ないからです。

またUNIXなどのようにパスワード認証を持ちアクセス制限可能な環境で
あっても平文のパスワードを保存しておくことには問題があります
(~/.netrcとか)。

ちょっと席を立った時にその時だけ使われるのと、パスワードそのもの
を盗まれ、継続的に使われ続けることになるのとでは、随分違います。

というわけでとてもわかりやすい結論が得られます。

   Win95だろうがUNIXだろうが個人環境だろうが暗号化されていようが
   パスワードを保存するのは全部だめ。


(注) /etc/passwdは可逆性はないのですが、辞書攻撃は有効ですし、
    今となってはキー空間が十分でないので、シャドー化は必須と言っ
    てもよいと思います。「塩」は省略。

--
Masafumi SHIRAIWA