デスクトップアプリケーションのハッシュ、ソルト、キーを保存する場所
デスクトップシークレット内のアプリケーションシークレットとキーをどこにどのように保存するべきかを理解しようとしています。たとえば、FacebookアプリのキーまたはDropboxのキーとシークレット。
だから私はこれらの値をハッシュ、ソルト、暗号化などするべきだと読んだ。これは、誰かが私のコードをリバースエンジニアリングしてキーを見るのを防ぐためです。
これはすべて問題なく動作しますが、これらすべての方法で、最終的にはキー自体ではなく、どこかにソルトまたはハッシュ値を格納しています。確かに、ハッカーがソルト/ハッシュ、そして場合によってはソースコードにアクセスできる場合、暗号化されたキーを解読して、とにかく私のパスワード/キー/シークレットを取得することができますか？
私が読んだ最も安全なオプションの1つは、この値をデスクトップアプリにまったく保存せず、Webサービスを呼び出してキー（おそらく暗号化されている）を取得することです。しかし、私の質問は、この場合でも、まともなハッカーは確かにメモリダンプなどを実行して、Webサービスから返された値が何であるかを確認することです。
次善の策は、あいまいなことです。
私は完全に何かを逃していますか？
余談ですが、とにかく、facebook/Twitter/dropbox/etcのキー/シークレットはハッカーにとってどのような用途になりますか？とにかく、ユーザーの資格情報またはアクセストークンを使用するには、ユーザーの資格情報またはアクセストークンが必要ですか？
アドバイスや提案はいただければ幸いです。
[〜＃〜] tldr [〜＃〜]：クライアントアプリケーションで何も秘密にしておくことはできません。見つけにくくすることしかできません。秘密鍵を難読化して、攻撃者がそれをリバースエンジニアリングしたいほど困難にする必要があります。
エンドユーザーのデバイスに展開する必要があるクライアントアプリケーションは、リバースエンジニアリングの対象となるため、秘密にすることはできません。 難読化 を使用することで、アプリケーションの特定の部分をリバースエンジニアリングするプロセスを困難なものにすることができます。
ハッシュ関数は一方向の関数であるため、ハッシュとソルトを使用しても役に立ちません。これは、特定の入力のハッシュが期待されるものと同一であることを検証するために使用できます。復号化する方法がないため、データの暗号化には使用できません。
AESなどの対称暗号化を使用できますが、データを復号化するには暗号化キーが必要であるため、攻撃者も利用できます。
攻撃者はクライアントアプリケーションと同じようにWebサービスを呼び出すことができるため、サーバーで秘密を保持し、Webサービスを呼び出すことは役に立たない。
したがって、秘密を保護する実際の唯一の方法は、難読化を使用することです。これにより、攻撃者がリバースエンジニアリングを行う価値がなくなります。
私見では、APIの秘密鍵は機密データですが、重要な機密ではありません。誰でも自分のAPIキーを取得でき、あなた自身が指摘したように、ユーザーデータへのアクセス許可は付与されません。サービスプロバイダーがAPI呼び出しを実行しているユーザーを追跡するだけであり、特定のAPIで使用状況、制限、さらには料金を監視することもあります。したがって、リスクは、誰かが呼び出しのAPI帯域幅を盗んだり、APIの使用料を支払ったりすることです。明るい面-このようなキー（facebook、Twitter ...）は非常に一般的ですが、今日ではほとんどすべてのアプリケーションで使用されているため、攻撃者がアプリケーションから離れるには、通常よりも少し難しくするだけで十分です。単独で、プレーンテキストで配置している別のアプリケーションからsercret APIキーを取得します。
ここ は、いくつかの素晴らしいシンプルなアイデアを含むブログ投稿です。