できるだけパスワードを扱うコードを自前で書かないようにしてください。 特にローカルなアプリケーションの場合、通常行うユーザのログイン認証にまかせて しまうようにしてください。 アプリケーションが CGI スクリプトの場合、Web サーバが用意している防御に できるだけまかせてください。 ただし Web サーバにおける認証の扱い方については下記を参照してください。 アプリケーションがネットワーク経由で利用するものなら、平文でパスワードを 送らないでください(できるだけ)。というのは、ネットワークを盗聴することで、 いとも簡単に横取りされて、後で使われてしまうからです。 パスワードを「暗号化」しても、その暗号化アルゴリズムで固定の鍵を使って いたり、何かしかの非公開アルゴリズムを使っていたりするなら、本質的に平文で パスワードを送っているのと同じです。
ネットワークで利用するなら、少なくともダイジェスト・パスワードの使用を考えて ください。 ダイジェスト・パスワードはハッシュで生成するパスワードです。通常は、サーバが クライアントに何かデータ(たとえば、日付、時間、サーバ名)を送り、クライアント はこのデータとユーザのパスワードを組み合わせ、この値(「ダイジェスト・ パスワード」と呼びます)をハッシュします。そしてハッシュした結果をそのまま サーバに返します。 サーバはこのハッシュ値を検証します。 これはうまくいきます。というのは、パスワードはどんな形でも実際には送られない からです。パスワードはハッシュ値の元として使われるだけです。 ダイジェスト・パスワードは普通の意味では「暗号」とは見なされませんので、法律 で機密用の暗号に制限を設けている国でも認められています。 ダイジェスト・パスワードは、直接しかけてくる攻撃には弱いのですが、ネットワーク の盗聴に対しては有効です。 弱点の 1 つに、ダイジェスト・パスワードの動作があります。サーバはハッシュして いないパスワードをすべて持っていなければならず、これがサーバを攻撃の対象 として魅力あるものにしています。
アプリケーションでユーザがパスワードを設定できるのなら、パスワードをチェック して、「適切な」パスワードだけを許可してください(辞書に載っていない、一定 以上の文字数である、等)。 適切なパスワードの付け方を見つけたいなら、 http://consult.cern.ch/writeup/security/security_3.html を見てはどうでしょうか。 PAM が使えるなら利用しましょう。交換可能なパスワード検証機能がサポートされる からです。