2

に基づいて、REST API に HMAC を実装しようとしています。

http://www.smartjava.org/content/protect-rest-service-using-hmac-play-20

私がまだ混乱していることの 1 つは、SECRET をクライアントに渡す方法です。クライアントは、iPhone、Android で、市場からダウンロードされます。

私が考えていたのは、ユーザーがPINのようなSECRETとして入力したものを使用することでした。サーバーはこのPINを経由して取得します

1) クライアントはサーバーから公開鍵を取得します 2) 公開鍵で PIN を暗号化します 3) サーバーは PIN を db に保存します 4) その時点から、PIN は SECRET として使用されます

これに穴はありますか？

4

3 に答える 3

2

これは原則として問題ありません。ただし、ピンは通常 4 桁のみです。攻撃者が公開鍵を取得し、9999 個の組み合わせすべてを暗号化することは難しくありません。次に、暗号化されたキーとクライアントからの暗号化されたデータを比較して、秘密を見つけることができました。ピンに 50 個のランダムな文字を埋め込むことで、この問題を回避できます。サーバーは、パディングされたデータを復号化し、最後の 50 文字を単純に破棄する必要があります。

于 2012-09-26T20:34:20.607 に答える
1

穴があります。

ステップ3で、PINがデータベースに保存されます。サーバーは、PINを保存する要求が正当なユーザーからのものであることを知る方法がありません。

これを機能させるには、PINを次のいずれかに保存する必要があります。

  • アカウント作成時
  • 古いPINが提供された場合

そうは言っても、PINは非常に弱く、壊れやすいままです。4桁のピンは、平均して約5000回の試行で推測されます。

于 2012-09-26T21:12:02.557 に答える
0

私はセキュリティの専門家ではありませんが、クライアントがリクエストごとにランダムなシードを送信した場合はどうなるでしょうか? クライアントとサーバーの両方が、共有アルゴリズムに基づいて秘密鍵を生成する際にこのシードを使用します。ただし、特定のシードと返されたハッシュとの関係がどの程度攻撃可能かはわかりません。

于 2012-10-09T14:06:53.997 に答える