言うまでもなくパワード管理はセキュリティ上非常に重要な管理項目です。十分な安全性が確保できるよう配慮しなければなりません。しかし、大手サイトであっても適切とは言いがたい管理が行われている場合も少なくありません。

平文のパスワードをサイトの管理画面から参照できるのは論外です。決して行ってはならない行為です。パスワードを参照できるようにしてしまうと、スクリプトインジェクション等でセッションをハイジャックされると、攻撃者がパスワードを盗み読み、恒久的に成りすましが可能になります。さすがに平文パスワードが表示されるサイトは少数だとは思いますが、このような実装は決して行わないようにしてください。

多くのユーザは複数のサイトで同じユーザ名とパスワードを利用しています。パスワードが漏洩すると自分管理しているサイトのサービスのみでなく、ユーザが利用しているほかのサイトのサービスにも影響すると考えるべきです。しかも、ほとんどのWebサイトはパスワードの有効期限を設定していません。一度パスワードが漏れると少なくとも何年間もの間、第三者に成りすまされアカウントを不正利用される可能性があります。

この連載でも解説しましたが、SQLインジェクションを完全に防ぐのは容易です。すべてエスケープするかすべてのクエリにプリペアードクエリを利用すればSQLインジェクションは防げます。しかし、万が一SQLインジェクションに脆弱であってもパスワードが盗まれることを防ぐため、パスワードは暗号化したもののみを保存すべきです。データベースサーバ本体やデータ自体を厳重に管理していても、パスワード自体はシステム管理者でも判らない状態にするのが基本です。

パスワード等の保存にはSHA1ハッシュ関数を利用することが一般的ですが、単純にSHA1でハッシュ化すると辞書攻撃に脆弱になってしまいます。これでは万が一、SQLインジェクションなどでハッシュ値として保存したパスワードが漏洩すると、辞書攻撃に脆弱なパスワードがクラックされてしまいます。

辞書攻撃を防ぐにはパスワードと固定のランダム文字列（salt）を一緒にハッシュ化します。ハッシュ化したパスワードとslatとなるランダム文字列が一緒に盗まれると、簡単にフルートフォース攻撃でクラックされるパスワードも少なくないでしょう。saltはベータベース以外の場所（通常はファイル）に出来る限り秘密を維持できるように保存しておきます。パスワードは8文字以上で辞書攻撃に強いパスワードを設定するようユーザには勧めるべきです。

slatを利用すれば、仮にデータベースのデータのバックアップが紛失するような事故があっても辞書攻撃によりパスワードがクラックされるリスクを軽減できます。

対策のまとめ

• 平文のパスワードは決して保存しない
• パスワードは必ずハッシュ化して保存
• 可能であればslat付きでハッシュ化
• パスワード変更は登録時に設定したメールに変更用のURLを送付
• Web UIでパスワード変更を許可する場合、現在のパスワードを聞かない（フィッシング防止）
• Web UIでパスワード変更を許可する場合、別の秘密情報（質問と答えのセット等）を利用する
• ユーザが推測不可能なパスワードを設定するように勧める
• できればパスワードの有効期限を設定して定期的にパスワードの更新を勧める