1

C# (.NET 4.0、SQL CE 4.0 データベース) を使用してスモール ビジネス アプリケーションを作成しています。データベースは暗号化されています (SQL CE はデータベースの暗号化をサポートしています) が、私の知る限り、 http://msdn.microsoft.com/en-us/library/aa257373( v=sql.80 ).aspxパスワードから:

最大 40 文字です。文字、記号、数字、または組み合わせを含めることができます。回復できません。

ユーザーはアプリケーションのパスワードを入力しますが、これはおそらく複雑で安全なものではありません。したがって、データベース暗号化用のより安全なパスワードを作成するために、何らかの方法でユーザー パスワードを変更したいと考えました。私が知っていることから、パスワードからバイトを派生させる Rfc2898DeriveBytes Classがあります。しかし、データベースのパスワードには有効な文字 ( SQL Server CE パスワードに許可された文字? ) が必要です。つまり、 toBase64String()を使用できない可能性があります。

これまでの私の考えは、データベースのランダムで安全なパスワードを作成し、それをファイルに保存することです。ファイルは、ユーザーパスワードから派生したキーで AES256 を使用して暗号化されます。これを行うより良い方法はありますか？

また、それぞれがアプリケーション用の独自のパスワードを持つ複数のユーザーが、同じデータベース パスワードで同じデータベースにアクセスできるようにするにはどうすればよいでしょうか?

お時間とご回答ありがとうございます

4

3 に答える 3

2

これを直接行うことはできません。すべてのユーザー パスワードを同じデータベース パスワードに変換する関数は、DB 暗号化の目的を無効にします。DBパスワードをアプリに保存するのと同形です。

これは、それを回避する簡単な方法がないということではありません。

  • 2 番目のファイルを用意する - 暗号化されていない SQL CE データベースまたはプレーン テキスト ファイル

  • この中に単純なテーブルがあります：

    User | EncryptedPassword(すべての弦)

  • すべてのユーザーに対して、このファイル (テキスト ファイルの場合は 1 行) に、ユーザー名とユーザー パスワードで暗号化された DB パスワードを含む行があります (明らかに、pw のバイナリ ハッシュ、base64 として保存されます)。

  • ユーザーがログインするとき、指定されたパスワードを使用しEncryptedPasswordてこのユーザーのフィールドを復号化します。これはDBパスワードである必要があり、DBを開くために使用できるようになりました

  • これは、正しい SQL データベース パスワードの提供に失敗すると、間違ったユーザー パスワードが検出されることも意味します。

于 2012-04-05T20:31:06.100 に答える
1

ToBase64String()文字、数字、スラッシュのみで構成される文字列を返すように思えます。これは、SQL CE の要件に適合します。を使用Rfc2898DeriveBytesして 20 バイトを生成し、そこから 40 文字の base64 文字列を生成できます。ソルトはユーザーごとに異なる必要があります。たとえば、ユーザー名とサイト名を連結して使用できます。

于 2012-04-05T20:28:11.540 に答える
0

パスワードを強化するためのアルゴリズムを知っている人なら誰でも、そのアルゴリズムを再適用して、弱いユーザー パスワードで暗号化を攻撃することができます。その点で、パスワードに「何か」を追加することは良い考えですが、完全な解決策ではありません。

一般的に、あなたが話している概念は塩漬けです。入力をハッシュする前に追加のデータでソルトします (「回復不能な」パスワードは、実際にはパスワードのハッシュであるように聞こえます)。（提供したリンクされた記事から）パスワードが接続文字列で使用されているように見えます。これが有効な文字セットを制限するものです。

パスワードをソルトハッシュとして保存するユーザーアカウントを作成するときは、サーバー側でソルト値を決定し、そのユーザーに関連付けて安全な方法で保存する必要があります。パスワードを作成または変更するときは、ユーザーごとのソルト値をハッシュ アルゴリズムに組み込む必要があります。

暗号化に単一の中央キーを使用しないでください。ユーザー提供のパスワードにソルトを追加するだけです。

アップデート

ユーザー固有のパスワードではなく単一のパスワードを使用してデータベースを配布する必要がある場合 (たとえば、ユーザーごとに個別にコピーを暗号化できない場合)、2 つの分離された問題があります。

  • 許可されていない人がデータベースを閲覧できないようにするにはどうすればよいですか?
  • ユーザーを認証するにはどうすればよいですか?

最初の問題に対処するには、適度に長いパスワードをアプリケーションに安全に埋め込むことをお勧めします。ただし、「安全に埋め込む」ことは、断固たる攻撃者に対して達成するのは困難です。そこでは、だれかがデータベース (「映画リスト」または「クレジット カード番号」?) に侵入するためにエネルギーを投資する価値がある可能性を推定し、誰かが実際に侵入できる場合に会社または顧客に与える損失を判断する必要があります。侵入する (たとえば、とにかくプログラムを購入しない誰かに「収益を失う」か、顧客の秘密が危険にさらされるのを許すか、...)。

データベース キーを保護するために最大限の努力が必要であると判断した場合は、ハイエンドの難読化ソリューションを使用してください。AES で暗号化されたキーをファイルに保存する場合でも、コードは暗号化されたデータを復号化してキーを取得する必要があることに注意してください。コードが十分に難読化されていない場合、誰かがデバッガーをプログラムにアタッチして、プログラムがキーを復号化できるようにすることは簡単です。その意味では、AES はほとんどメリットがありません。ただし、最善の難読化を行っても、最も熟練した断固たるハッカーを防ぐことはできません。

2 番目の箇条書きについては、プログラムへの (およびデータベースへの間接的な) ユーザー アクセスを承認する必要があります。1 つのアプローチは、単純なユーザー名/パスワードのハッシュ アプローチを使用することです。ユーザー テーブルを SQL CE データベースに格納できます。結局、ユーザーが認証に成功したかどうかにかかわらず、プログラムはそのデータベースにアクセスできます。

于 2012-04-05T20:27:15.380 に答える