2

秘密鍵を使用して REST API と (https 経由で) 通信するアプリケーションを構築しています。ユーザー/ハッカーがそのキーを発見し、偽のデータをサーバーに送信する可能性のある独自のアプリケーションを構築することは望ましくありません。アプリケーション内でその「文字列」を保護するための最良のオプションは何ですか?

私が考えていたオプションは次のとおりです。

1) その文字列をアプリケーション内にハードコーディングし、アセンブリを難読化します。まだいくつかの難読化解除方法でこれを解読できると思います。

2) app.config でそれを渡し、組み込みの .NET メカニズムを使用してインストール時に暗号化します。私が理解しているように、復号化キーはウィンドウ内のどこかに保存されており、ユーザーには表示されません。これを取得するには、誰かがシステムに関する十分な知識とハッキングのスキルを持っている必要があります。はいの場合でも、ユーザーがインストール パッケージをダウンロードすると、それを解凍して秘密鍵を確認できますよね?

他に選択肢はありますか？

クライアント マシンで何かを保護する方法がないことはわかっています。100% のセキュリティ方法はありません。

バルテック

4

3 に答える 3

2

攻撃者の手の届かない秘密があります: ユーザーのパスワードです。あなたができる最善のことは

  • REST キーを再生しにくくする (使用しないことで)
  • 呼び出しを単一のユーザーのセッションまで追跡できるようにする

ブラウザがユーザーを認証する方法を模倣する方法を次に示します。OAuth2 クライアント側 Web アプリケーション フローは別の例です。

  1. ユーザーのパスワードを尋ねる
  2. おそらく保護したいのと同じ REST API を使用して、ユーザーを認証します。定義上、これは認証された呼び出しではありません。ログインフォームを考えてみてください。HTTPS 接続では常に公開されています。
  3. サーバー側で、乱数を生成し、呼び出しnonceて保存します。
  4. ユーザーはまだログオンを待っていますnonce。. それは彼自身のRESTパスワードになります

ここで、REST 呼び出しを行う必要があるリッチ クライアントのどこかをユーザーがクリックすると、

  1. ユーザー名と nonce のペアを REST 呼び出しに追加する
  2. サーバーで、REST 呼び出しが着信したときに、username-nonce が有効であることを確認します。
  3. API である種のログオフを呼び出し、nonce使用しない場合はしばらくすると有効期限が切れます。

nonce 自体は推測しにくいはずです。GUID は当てはまりません。GUID の SHA-1 (またはそれ以上) は問題ありません。

これは大変ですよね？確かに、それがあなたの唯一の希望です。サーバー アーキテクチャとクライアント ライブラリは、HTTP BASIC 認証など、再利用できる認証スキームを既にサポートしている可能性があります。

于 2013-01-29T19:50:28.967 に答える
1

シークレットをクライアントに保存しないでください。サーバーに保存して使用します。

シークレットをクライアントに送信する場合は、次のことを確認してください。 - 転送中、およびディスクまたはメモリに保存するときに暗号化します。 - (短い) 有効期間を与えて、復号化または発見されたときに無効にします。

あなたの言うとおりです。誰かがシステムの管理者である場合、システムを信頼して何かを安全に保つことはできません。

ユーザーが管理者でない場合は、システムと管理者のみがアクセスできる証明書ストアまたはファイル システムのその他の特別な部分を使用できます。

于 2013-01-29T14:24:26.483 に答える
1

単一の秘密鍵の問題は、秘密鍵が出ると、データを本当に信頼できないことです。

デバイスから取得されるあらゆる形式の資格情報がハッキングされる可能性があります。

したがって、少なくとも、各デバイスから一意の資格情報を取得します。
そうすれば、不正なデータが疑われる場合、それらの資格情報をシャットダウンし、それらの資格情報に関連付けられているデータを確認できます。

資格情報は、ユーザー/パスワード、証明書、または秘密鍵である可能性があります。
証明書を要求するようにアプリを設定できますか。

于 2013-01-29T15:58:37.927 に答える