Postgresのドキュメント によると、Postgresのパスワード認証方法はMD5ハッシュを使用してパスワードを保護します。
パスワードベースの認証方法は、md5とパスワードです。これらの方法は、パスワードが接続を介して送信される方法、つまりそれぞれMD5ハッシュとクリアテキストを除いて、同様に動作します。
パスワードの「スニッフィング」攻撃を心配している場合は、md5をお勧めします。可能であれば、プレーンなパスワードは常に避けてください。ただし、md5をdb_user_namespace機能とともに使用することはできません。接続がSSL暗号化によって保護されている場合、パスワードを安全に使用できます(SSLの使用に依存している場合は、SSL証明書認証の方が適している場合があります)。
MD5ハッシュアルゴリズムが安全であるとはもはや見なされなくなったと、多くの情報源から聞いています。これは、Postgresにパスワードベースの認証を使用することを避けるべきであることを意味しますか?その場合、どの代替方法を使用する必要がありますか?
SSLを使用している場合、PostgreSQLの動作は問題ありません。 SSLを使用していない場合でも、ネットワーク全体で認証を実行している場合、PostgreSQLの動作が悪臭を放ちます。彼らのMD5とのゲームは価値がありませんが、MD5を使用しているからではありません。 MD5には独自の問題がありますが、そこにはひどく誤用されています。
「クリアテキストパスワード」認証では、クライアントはユーザー名とパスワードを表示し、サーバーがサーバーに保存されているものと一致する場合、サーバーはそれらを受け入れます。
「md5」認証では、クライアントは値(たまたまパスワードとユーザー名の連結のMD5ハッシュ)を表示し、サーバーがサーバーに保存したものと一致する場合、サーバーはその値を受け入れます。
両方の場合で、クライアントはサーバーに一連のバイトを表示しますが、常に同じシーケンスです。攻撃者がネットワークをタップしてこれらのバイトを監視し、サーバーに接続して同じバイトを送信してエントリを許可すれば十分です。バイトがMD5ハッシュの結果であることは、ここでは完全に無関係です。このMD5ハッシュはパスワードと同等であると言われています。接続が盗聴される可能性がある限り(つまり、SSLがない場合)、セキュリティは低下します。
MD5計算の詳細については このページ を参照してください。彼らはそれを「暗号化」と呼びますが、これはまったくありません(ハッシュは暗号化ではありません)。
このMD5を使用するとセキュリティが低下すると主張することもできます。プレーンテキストのパスワードを使用すると、(Kerberos、LDAPなどを使用して)別の認証サーバーに転送できます。次に、認証サーバーは強力なストレージ技術を使用できます( パスワードハッシュ を参照)。 PostgreSQL固有のMD5ハッシュでは、これは適用できません。 「md5」認証方式を使用する場合は、これらすべての「md5」値をそのまま含むデータベース内のテーブルに対抗する必要があります。たとえば、バックアップテープや古いディスクを手に入れられる攻撃者は、すぐにデータベース上で多くの無料アカウントを取得します。
そして、私は、これらすべてがMD5暗号の弱点とは何の関係もないと主張しています。 MD5がSHA-512に置き換えられた場合でも、このすべてが当てはまります。
はい、MD5の使用は安全です。クライアントが認証を要求すると、サーバーはランダムなソルト値を送信します。クライアントはその値とパスワードを使用してMD5ハッシュを生成します。ランダムソルトが使用されているため、攻撃者は辞書攻撃を使用できません。また、クライアントが認証されるたびにソルトが変更されるため、これは古い認証要求を再生する機能ではありません。
詳細 ここ AuthenticationMD5Passwordセクション。
TLDR。適切に設定し、長いパスワードを使用すれば、安全です。
1。postgresでは、md5 auth-method
はクライアント側のハッシュを意味します(ディスカッション: 1 、 2 )、これはハッシュpasswordを同等にします。データベース内のハッシュは、クライアントから受信したハッシュと比較されます。攻撃者は、md5をクラックする時間を費やすことなく、盗まれたpg_shadowテーブルのハッシュを直接使用できます。
ハッシュが最終的に盗まれると想定し、クライアント側のハッシュを回避する方がはるかに安全です。
実際にコードを確認するだけで、非常に簡単です。 https://github.com/postgres/postgres/blob/master/src/backend/libpq/crypt.c#L141 < —この行への直接リンク:
if (strcmp(crypt_client_pass, crypt_pwd) == 0)
port->hba->auth_method == uaMD5
を実行するとどうなるかをご覧ください。はい、ハッシュクリアテキストを傍受することはできません。再びソルトとハッシュが行われます。しかし、他の攻撃によって盗まれた場合、クラッキングすることなく直接使用できます。
2。当然のことながら、password auth-method
とcreate user whatever with encrypted password
を使用すると、postgresでサーバー側のmd5ハッシュを使用できます。
これらの方法は、パスワードが接続を介して送信される方法、つまりそれぞれMD5ハッシュとクリアテキストを除いて、同様に動作します。
SSLを使用してクリアテキストのパスワードを保護します。おそらくそのハッシュの保存方法を知っておくべきでしょう— saltは再利用されます:
/* Encrypt user-supplied password to match stored MD5 */
if (!pg_md5_encrypt(client_pass, // const char *passwd
port->user_name, // const char *salt
strlen(port->user_name),
crypt_client_pass)) // char *buf
ランダムに生成された使い捨てのユーザー名を作成してソルトとして使用することもできますが、それが良いアイデアかどうかはわかりませんが、これはエラーが発生しやすくなります。
一般的な推奨事項はmd5から移行することですが、パスワードハッシュのためにまだ壊れていません。関連する質問: MD5が1996年以降クラックされているのに、なぜ人々はまだMD5を使用/推奨しているのですか?
短いパスワードは使用しないでください。長くて高品質のランダムパスワードは、依然として安全です。
簡単に推定すると、これらの(残念ながらかなり古い)リンクにはいくつかの数字があります。
http://blog.codinghorror.com/speed-hashing/
https://security.stackexchange.com/a/33684/41687
更新:irc.freenode.netの#postgresqlチャネルからのRhodiumToadに感謝します。md5がパスワードハッシュのためにまだ壊れていないことを明確にしてください。長い長いパスワードは保存されますその日。
TCPクライアントアプリケーションからPostgresサーバーへのストリームキャプチャ(Npgsqlコネクタを備えたC#))をご覧ください。
そこで、パスワード、ユーザー名、ソルトからmd5ハッシュを見ることができます(黒い小さな矢印を見てください)。
では、安全な接続(SSL/TLS)が使用されている場合の外観を見てみましょう。
ご覧のとおり、安全な接続を使用している場合、MD5の結果は接続に「表示」されません。したがって、PostgreSQLとのこのデータ交換方法は安全であると考えることができます(Webサーバーや他のデータベースサーバーなどでも同様のことが起こります)。パケットスニファを使用して、データで実際に何が起こっているのかを理解することは常に良いことです;-)