パスワードをソルトつきハッシュ化してDBに保存するのがベストプラクティス…とは限らないという話 - kazuhoのメモ置き場

フレームワークの責務とセキュリティ - MugeSoの日記についての感想文です。 世の中にはたくさんの通信プロトコルが存在し、中には、特定の条件でパスワードを含む文字列をハッシュ化した値を検証しなければならないものも含まれています。 例えば、HTTP Digest認証の場合は、MD5("realm:user:password")を保存しておく必要がありますし、APOPの場合は生のパスワードを、CRAM-MD5の場合はMD5("password")を保存しておく必要があったはず。 で、こういった様々なプロトコルに対応可能な認証データベースを準備しようとすると、パスワードを復号可能な方式で保存しておく必要があります*1。 ただ、パスワードを復号可能な方式で保存するとか、開発者あるいは管理者としてやりたくないというのはもちろんそうなので。で、長期的には世の中どこへ向かってるかというと： 選択肢a

[kazuhooku]

blogged

[atsushifx]

フレームワーク作成というかシステム開発時のアーキテクチャーの問題。フレームワーク側でパスワードhash化などのセキュリティ機能を入れておくのは便利だけど改修などに弱い。認証関連は別レイヤーがベターっぽい

[lejay4405]

ちょっとよくわかんない…

[oxy_oxynotes]

ちっさいところは複数の三者間認証を利用するのが一番かもね

[takezaki]

複数のプロトコルを組み合せるときに生パスワードが必要になるケースこそ脆弱性のような気がする

[Jxck]

もとの話は Basic 認証のパスワードについてなので、レイヤが変わってる気がする。選択肢 b) で認証サブシステムが分かれていないパターンかな？

[elf]

#kazuhooku #security #password

[UDONCHAN]

へー

[asuka0801]

「パスワードを復号可能な方式で保存しておく必要があります」　・・・はぁ？その時点で設計ミスでしょ

[y-teraoka]

dovecot のコードを読もうと思ってたのだった

[yass]

" で、長期的には世の中どこへ向かってるかというと / 選択肢b) 経路をTLS(SSL)暗号化し、パスワードは平文のまま認証サブシステムまで到達する。認証サブシステムは独自の最適と考える方式でパスワードを保存する "