サービス側がパスワードを平文で保存する10の理由

（タイトルは釣りです）

「おいおい、おれのパスワードがメールで送られ来たよ」
という事例があとを経たず歴史は繰り返すなー、と思う今日この頃。
何故に平文で保存するのか？を自分なりに想像してみた
間違いとか、追加とかあったら教えて

1. 知らない
ハッシュ値で保存しておいて、入力されたパスワードを、そのハッシュ値で
比較すればよいということを知らない。
プロなのに無知。しかし、このパターンが一番多い気がする。

2. 電話サポートが簡単
電話で問い合わせがあった時に、パスワードを再発行してもらうより
その場の電話で口頭でパスワードを言ったほうが早く済む。客も喜ぶ（人もいる）
僕は、自分のパスワードを口頭で伝えられたらいやーな気分になりますが

3. めんどくさい
保存とはちょっと違うけど HTTP の Basic 認証とか csv pserver 認証とかって
符号化してるだけで簡単に復号できるようになってるのってめんどくさいから？
そんな理由。
サービス側じゃないけど、 ~/.sitecopyrc や ~/.pypirc の中身を見ると
ドキドキする (手元にないけど、.cvspass も平文で保存してなかった気がする）

4. 検証、テストの都合
電話サポートと似てるけど、テストとかユーザーの問い合わせの時に、
DB に入ってるパスワードをそのまま打ち込んで動作検証できたら楽・・・
そういうことがどれくらいあるのか知らないけど。

5. パスワードを変更させるのが面倒
パスワードを忘れた時に、
「パスワード再発行フォーム」→「新しいパスワードをメール送信」
よりも、元のパスワードを送るほうが間違いにくくてサポート電話が減る。
2. の変形、自動化されたパターン。

6. パスワード変更の UI の古いパスワードに正しい数だけ * を入れたい
古いパスワードを * で表示した時に、文字数が違うと違和感。
パスワード変更 UI を作った人は誰もが思ったことはあるはず。
だからといって、誘惑に負けて * の数のためだけに平文で保存してはいけない。
そもそも、元のパスワードの長さがわかっちゃうことも脆弱性だし。


7. サブシステムとのブリッジの都合
複数のサブシステム同士で認証する場合に、どっかで平文で持ってると
あとあとにサブシステムが増えた場合や、サブシステムの認証方法に変更が
あった場合に好都合。業務システムではこれも結構ありそうな気がする。

8. Kerberos 認証
チケット許可チケット(TGT）を発行するサーバーには、平文でパスワードを
おいておかないと、トークン作れないのでしょうがない。
Kerberos の実装のひとつである ActiveDirectory も、平文パスワードを
（読み取る方法ないけど）厳重にしまってるはず

9. Kerberos 認証もどきの、パスワードと何かを混ぜてハッシュするようなシステム
あるの？
セキュリティの専門家でもなければ車輪の再発明はしないほうが良いと思う。

10.その他
思いつきませんでした。募集してます。

まぁ、許されるのは 8. だけですね。
Web サービスならとりあえずハッシュしとけ！って感じ。
MD5 のコリジョンが危険、っていう話も聞くけど、世の中はもっと大きな危険が溢れているのだ。