2

それで、私はここ数週間、次の問題を理解しようとしてきましたが、状況がどれほど矛盾しているように見えるので、この時点で私はほとんど選択肢を使い果たしています。

SharePointで動作するように開発されたアプリケーションがありますが、基本的にはASP.NETコードです。暗号化された接続文字列があり、それをメモリで復号化し、構成オブジェクトに保存してデータベースにアクセスします。私の構成オブジェクトは静的（Service Locatorパターンを介してアクセス可能）であり、後でLINQ-to-SQLデータコンテキストをシードするために使用します。

復号化用の私の内部キーは、クラスに非公開で保存されますprivate static readonly string myPassword = "MyPassword";（ほんの一例ですが、実際のパスワードはより複雑で有効です）。そのフィールドを参照する単一のステートメントはどこにもありません。ただし、新しいをインスタンス化する別の復号化メソッド（インスタンスメソッド）のパラメーターとして使用する静的メソッドのステートメントを除きますDESCryptoServiceProvider。

それでも、本番サーバーのログに次の例外が発生することがあります。

Exception type: CryptographicException
Exception message: Specified key is a known weak key for 'DES' and cannot be used.

そのため、接続文字列の復号化は失敗し、もちろん、データベースにはアクセスできなくなります。ふざけて、アプリケーションがダウンしています。

これはどうして可能ですか？

免責事項：これは私が維持している古いアプリケーションです。ここで説明するのはトラブルシューティングに役立つものですが、内部での動作を変更することはできません。これが最善のアプローチではないことに同意する人もいますが、アプリケーションは2年以上問題なく実行されており、突然これらの例外によって停止されています。

更新：例外のスタックトレースで明確にするように要求されましたが、NDAの理由で1つの完全なスタックトレースを提供できません。私が言えることは次のとおりです。

  • 例外をスローするオブジェクトはSystem.Security.DESCryptoServiceProvider.CreateDecryptor(Byte[] rgbKey, Byte[] rgbIV)メソッドです
  • 元のキー（実際に使用するキー）は検証を行い、例外を生成しません。それでも、検証されない現在の値がどれであるかがわからないまま、この例外が発生することがあります（常にではありません）。
  • のインスタンスは、DESCryptoServiceProvider静的に、プライベートに、ヘルパークラスに格納されます
  • System.Web.HttpApplication.InitModulesCommon()これはすべて、アプリケーションの内部部分を初期化するために、によってトリガーされます

また、ここに隠されたスタックトレースがあります：

at System.Security.Cryptography.DESCryptoServiceProvider.CreateDecryptor(Byte[] rgbKey, Byte[] rgbIV)
at SymmetricEncryption.Decrypt(String contents, String key)
// our helper, just a wrapper, based from this class: http://www.codeproject.com/Articles/1967/Encryption-Decryption-with-NET
at EncryptedConnectionStringHelper.DecryptUserAndPass(String connectionString)\
// our container for parsing the connection string and decrypting the user and password, not the full connstring is encrypted
at OurModule.Init(OurConfigurationSection config)
at OurModule.Boot(OurConfigurationSection config)
at OurModule.Boot()
at OurModule.Init(HttpApplication context)
at System.Web.HttpApplication.InitModulesCommon()
at System.Web.HttpApplication.InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers)
at System.Web.HttpApplicationFactory.GetNormalApplicationInstance(HttpContext context)
at System.Web.HttpApplicationFactory.GetApplicationInstance(HttpContext context)
at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)

このアプリケーションは、このモジュールを次の方法で登録します。

public class OurModule : IHttpModule
{
    public static bool initialized = false;

    public void Init(HttpApplication context)
    { 
        if (!initialized) {
            subscribe(context);
            OurModule.Boot();
            initialized = true;
        }
    }
4

2 に答える 2

1

ラッパーを見てくださいSymmetricEncryption.Decrypt。私の推測では、問題はそこにあると思います。パスワードからキーを作成する方法。PasswordDeriveBytesまたはその他の中途半端なソリューションを使用していますか?

失敗した場合は、「MyPassword」よりも優れたキーを取得してみてください。

失敗すると、web.config 暗号化を使用できる可能性があります。Scott Gu がここに書いています。

于 2012-09-04T16:21:25.033 に答える
0

何かがオブジェクトを変化させているようには聞こえません。「何か」（スタックトレースを投稿した場合はより明確になります）がDESキーを検証しているようです...そしてそれが既知の弱いキーであると不平を言っています。

もちろん、より安全になるようにパスワードを変更するのが理想的ですが、それができない場合は、その例外がどこから来ているのかを正確に調べ、検証の方法とタイミングを制御する設定があるかどうかを確認する必要があります。

（例外メッセージだけでなく）完全なスタックトレースをまだログに記録していない場合は、それが最初に行う必要があります。

于 2012-09-04T14:47:25.260 に答える