背景:現在のサーバープロバイダーは、パスワードをプレーンテキストでデータベースに保存することは問題ないと言っており、メール認証にCRAM-MD5を使用しているため、そうする必要があると述べています。私の脳は同意しません。しかし、データベースにパスワードをプレーンテキスト形式で保存することだけがここで発生する唯一のセキュリティ問題ではない可能性があることや、CRAM-MD5が現在でも「安全」であると見なすことができるかどうかさえわかりません。
InfoSecの観点からは、「SSL接続を使用せずに電子メールサーバーと通信する際の認証にCRAM-MD5を使用する」というフィードバックをいただければ幸いです。前もって感謝します。
edit:暗号化の観点については、チェック https://crypto.stackexchange.com/questions/8391/what-are- the-potential-security-impacts-of-using-cram-md5-for-emails-when-not-
CRAM-MD5では、ハッシュ関数によるパスワードのイメージだけでなく、サーバーが実際のパスワードを知っている必要があります。したがって、サーバーがHMAC-MD5をサポートする必要がある場合は、パスワードをプレーンテキストで保存する必要があります。 (サーバーはパスワードを暗号化できますが、暗号化キーも知っている必要があるため、役に立ちません。)
CRAM-MD5は、パスワードがクリアテキストで送信されるのを防ぐように設計されています。これは、受動的な攻撃者に対するある程度の保護を提供します。攻撃者が通信を傍受できてもメッセージを挿入できない場合、攻撃者は、チャレンジCと値HMAC-MD5(P、C)を取得します。ここで、Pはパスワードです。力ずくでこの情報からパスワードを見つけるより良い方法はありません。ただし、ブルートフォースはパスワードの問題です。少なくとも slow function を使用し、ハッシュの公開はいずれにせよ回避し、妥協案として扱う必要があります。
人間が選択した覚えやすいパスワードの代わりに、サーバーに保存される「パスワード」(より正確には共有シークレット)は、人間のパスワードの低速ハッシュである可能性があります Adnanによる注記 。これにより、MD5ハッシュからのブルートフォース攻撃が排除されるため、パッシブ攻撃者に対するセキュリティが向上します。 (ただし、これを行う人は非標準のツールを使用しており、SSLを使用するためのセキュリティについて十分に深刻であると考えられます。)CRAM-MD5は、認証手順のみを認証し、残りのセッションは認証しません。そのため、クライアントになりすますことができるアクティブな攻撃者は、認証を実行させてから、クライアントを遮断(または変更したデータを送信)し、セッションで自分のコマンドを送信できます。具体的には、攻撃者はTCPクライアント向けのパケットを受信できる必要があります。または、攻撃者はTCP向けのパケットを受信できる必要があります。サーバー、またはクライアントがサーバーではなく攻撃者と通信するようにする偽のDNS応答を送信します。このような攻撃者は、認証フェーズ中にクライアントとサーバー間のリレーとして機能し、サーバーとの通信を続行できます。攻撃には、上記の総当たり以外の方法で、パスワードの侵害が含まれます。
SSL経由でCRAM-MD5を使用すると、この認証の問題が解決します。 SSLは安全なセッションを提供し(つまり、参加者はセッション中に変更できません)、サーバーをクライアントに対して認証します(ユーザーが盲目的に無効な証明書を受け入れない場合)。 CRAM-MD5は、認証の問題の3番目の部分、つまりサーバーでのクライアントの認証をもたらします。
パスワードが無作為に生成された十分な長さの文字列である場合、SSLを介したCRAM-MD5は問題ありません。パスワードがランダムに生成されたものである場合、サーバーにプレーンテキストで保存しない理由はありません。それは単なるキーです。パスワードが人間が覚えられるものである場合、CRAM-MD5は不適切です。これは、ほとんどの人間のパスワードがブルートフォースによってクラックされる可能性があり、1つのサーバーを超えて再利用されることが多いためです。
SSLを使用する場合、クライアントにSSL接続経由でパスワードを送信させるのではなく、CRAM-MD5を使用する価値はほとんどありません。クライアントが誤ってパスワードをサーバーのなりすましに送信した場合、パスワード自体はすぐに侵害されないという小さな利点があります(クラックされた場合のみ—サーバーのなりすましが絶え間なくチャレンジを送信し、その結果テーブル(レインボーまたはその他)もっともらしいパスワード上のHMAC-MD5値)。パスワードがランダムな文字列である場合、これは利点になる可能性があります(サーバーが攻撃者と同じチャレンジを送信しない限り、攻撃者はクライアントから送信された値を使用して偽装することはできません)。パスワードが人間のパスワードである場合、そのような利点はありません(とにかくパスワードが解読される可能性があるため)。パスワードをプレーンテキストで保存する必要があることは、明らかに不利です。
この場合、3つの関連する弱点があります。
不適切なパスワードの保存:プロバイダーのデータベースが侵害された場合、パスワードが直接公開されます。 CRAM-MD5の一部の実装では、パスワードをプレーンテキストで保存しませんが、ハッシュされたパスワードはまだ無塩です。これまでのところ、パスワードをソルトする既知の実装はありません(ソルトはクライアントにも知られている必要があります)。
実際のデータはプレーンテキストで移動します:SSLを使用しない場合、メールは完全に MiTM に公開されます。
オフライン攻撃:攻撃者が認証に使用される情報(サーバーから送信されたチャレンジ、クライアントから送信された応答)を取得すると、攻撃者は次のことができるようになります。パスワードをブルートフォースオフラインにします。
Chosen-plaintext attack:攻撃者はサーバーになりすますことができるため、必要なチャレンジ値を送信し、クライアントの応答を観察することもできます。これにより、最終的にパスワードがわかりやすくなります。
注意してください、これらの攻撃はいずれもMD5自体の脆弱性とは関係ありません。
結論として:CRAM-MD5はこの目的のために安全ではありません。あなたのプロバイダーは、パスワードをプレーンテキストで保存するための言い訳はありません。ここでの問題は、より良いソリューションを実装することに消極的であるだけです。
攻撃者がチャレンジをクライアントに転送できるため、MITMに対する保護は提供されません。プレーンテキストのパスワードの保存を要求することは悪いことであり、交換ではそれに対して辞書攻撃が実行される可能性があります。
このスキームについて心配していることは正当な理由であり、個人的には別の電子メールプロバイダーを使用することをお勧めします。
まず、プレーンテキストを使用する必要はありません。
パスワードの変更バージョンを少なくとも保存できます。
if (length(key) > blocksize) then
key = hash(key) // keys longer than blocksize are shortened
end if
if (length(key) < blocksize) then
key = key ∥ [0x00 * (blocksize - length(key))] // keys shorter than blocksize are zero-padded ('∥' is concatenation)
end if
o_key_pad = [0x5c * blocksize] ⊕ key // Where blocksize is that of the underlying hash function
i_key_pad = [0x36 * blocksize] ⊕ key // Where ⊕ is exclusive or (XOR)
2つのXORされたキーを保存します。システムが危険にさらされても、同じパスワードを使用する他の場所にあるユーザーのアカウントは危険にさらされないという事実により、セキュリティが強化されます。どうやらDovecotはこれを行います。
MD5自体は、ブルートフォースが非常に簡単です。 MITM攻撃者は、チャレンジを既に知っているため、パスワードをブルートフォース攻撃する可能性があります。
現在、このような問題のほとんどすべてに対する解決策は、SSLを使用することです。
まず、平文のビットはでたらめです-ほとんどのPOP/SMTP * nixソリューションは、これを必要としないように後付けできます。これで邪魔にならない...
... CRAM-MD5には衝撃的な脆弱性があります-MD5ネクタイに起因します。ただし、プレーンテキストよりも優れています。外観と「OMGWTFBBQ-ness」の順に:
CRAM-MD5は、事実上、チャレンジレスポンスと結合されたMD5( (key XOR padding) concat MD5(key XOR morepadding) concat value)
です。キーはユーザーのパスワードです。値はチャレンジです。したがって、課題が不明な場合、それは完璧です。残念ながら、プレーンテキストで送信されるため、そうではありません。
基本的に、できる限り避けてください。最近、GPUは恐ろしい数のMD5ハッシュを計算できます。ただし、簡単な解決策は、SSLをたくさん使用することです。証明書は最近、ピーナッツの価値があります。