2016-11-07 9 views
2

私はデータの完全性について考えようとしていました。私はdbにシリアル化しようとしているオブジェクトを持っています。それがシリアル化されると、私はそれをハッシュして、DBに別の列としてデータと共に格納しようとしていました。シリアライゼーションとハッシュ

次に、私がデータベースからデータを取得すると、ハッシュをチェックして、ハッシュが一致すればデータをデシリアライズすることができました。

ここにポイントがありますか、それともCPUを浪費していますか?シリアライズされたオブジェクトを格納し、データがデータベース内で改ざんされていないことを検証する他の方法はありますか?データを格納するプログラムは、データを読み取るプログラムと同じでなくてもよい。

私の具体的な例は、EmailMessageオブジェクトを作成することです(System.Net.Mail.MailMessageはシリアル化できないため)、シリアル化してハッシュを作成します。両方ともデータベースに格納されます。後で私はシリアル化されたEmailMessageとハッシュを取ることができます。私はEmailMessageを取得し、別のハッシュを作成します。元のハッシュが新しいハッシュと同じであれば、MailMessageオブジェクトを生成して送信します。それ以外の場合は、TamperedWithException()を作成します。

以下のコードは、ハッシュを作成するために使用しているコードです。私はシリアル化を行うためにjson.netを使用しています。

public static class MD5HashHelper 
{ 
    public static string CreateHash(string str) 
    { 
     string hash; 
     using (System.Security.Cryptography.MD5 md5 = System.Security.Cryptography.MD5.Create()) 
     { 
      hash = BitConverter.ToString(
       md5.ComputeHash(Encoding.UTF8.GetBytes(str)) 
      ).Replace("-", String.Empty); 
     } 
     return hash; 
    } 
    public static bool CompareWithHash(this string str, string hash) 
    { 
     string strHash = CreateHash(str); 

     return strHash.Equals(hash,StringComparison.Ordinal); 
    } 
} 

この特定のテーブルはまだ暗号化されていません。攻撃者は変更を加えて別のハッシュを作成する可能性があります。これはおそらくこれを行うより良い方法があると思う理由の一部です。以下は

はシリアライズです:

public static class JSONHelper 
{ 
    public static string ToJSON(this object obj) 
    { 
     string json = JsonConvert.SerializeObject(obj); 
     return json; 
    } 

    public static T JSONToObject<T>(this string json) 
    { 
     Object obj = JsonConvert.DeserializeObject<T>(json); 
     return (T)Convert.ChangeType(obj, typeof(T)); 
    } 
} 
+0

が私には合理的なようです:-) StackOverflowの中のランダムな男(私)よりも他の誰かからのセキュリティアドバイスを持っていると思います。 –

+1

私はそれが合理的だと思うことに同意する...しかし、私は)1)あなたのハッシュアルゴリズム(つまり、なぜ攻撃者がデータを再ハッシュできないと仮定する)、2)あなたが暗号化しているかあなたのデータベース、3)あなたのアプリケーション環境内であなたのデータベースよりも高い価値を持つ場所が攻撃ベクトルの観点からないかどうか。 –

+0

ハッシングとシリアライズのためのコードサンプルをいくつか追加しました。攻撃ベクトルに関しては、これは発信通信であり、着信アプリケーションデータには影響しません。 –

答えて

0

塩は限りそれは秘密にされるように役立つ可能性があります。しかし、それは正当な署名者が利用できるようにしなければならないため、おそらく攻撃者が利用できるため、問題になります。ハッシュソルトはハッシュを気にしていませんか?私の攻撃:データを読み、変更し、新しいハッシュを作成し、変更したデータを保存し、DBにハッシュします。

このような攻撃に対する解決策はありますが、保護するものと誰からのものの価値を定義する必要があります。ハッシュは、一般的に、両方を同時に利用できない場合にデータを処理します。たとえば、アップルは1つのチャンネルでアップデートを提供し、そのハッシュを別々のチャンネルであるセキュリティ電子メールリストに電子メールで送信します。

一般的に、HSMなどの厳しいアクセス制限やハードウェアなしでは、すべての攻撃者から安全なアクセスを試みることはできません。それでも、莫大な予算を持つ国家があり、最後にはRubber-hose cryptanalysisです。

0

私が正しくあなたの状況を取得する場合、あなたの恐怖は誰かが可能性があることです。

  1. データベース
  2. へのアクセス権を持っているあなたの「改ざん防止」スキーマ
  3. の基本は、それが基づいて実現実現普通MD5ハッシュ
  4. に鍛造1鍛造物体
  5. のMD5と元のハッシュと元のオブジェクト変更されたオブジェクト
  6. 代替を偽造

このシナリオで最も恐ろしいのは、攻撃者が不正侵入防止メカニズムを欺くために、単一のシステムデータベースにアクセスする必要があることです。

最初の試みでは、アプリケーションシステムに「秘密鍵」を追加することもできます。コードでは、ハッシュされる文字列に固定接頭辞(塩)を追加することができます。攻撃者はデータベースへのアクセスとデータを改ざんするためのこの「秘密」情報の両方を必要とします。

しかし、@zaphが明らかに強調しているように、これは攻撃者(データベースにアクセスできるようになっている)に秘密にすることができるほど堅牢です。

、それはさらに悪いことに、この「塩」は、単にデータの書き込みを行うアプリケーションでは必要ありませんが、その

プログラムを提案するとして、それはまた、データを読み込むアプリケーションと共有する必要がありますデータを記憶することは、データを読み取るプログラムと同じでなくてもよい。

私たちはさらにスキームを複雑にしたいなら、「公開鍵」システムを使用することができます。MD5は、「書き込みアプリケーション」秘密鍵でMD5を暗号化して保存するため、新しいハッシュを偽造することができずにメッセージオブジェクトを検証します。

...しかし、我々は、このに入る場合は、真剣に、あなたはより良い

+1

よく作りました。 「良いプログラマ」として、私はハッシュのように、塩の穀物で私のアドバイスを取る。 –

+0

よろしくお願いします!しかし、私はセキュリティ専門家として資格がないということを強調したいと思っています。私はまだあなたの質問に対する他の適格回答を読むことを願っています。 – Insac

関連する問題