2

私は、Android/iPhoneアプリまたはWebサイトアプリケーションで使用するためのAPIを保護するための手法を検討してきました。
私は好きなテクニックを1つ見つけましたが、それが良いのか悪いのかはわかりません（非常に長いプロセスであることを除けば）。

処理（最初はユーザー側）：
最初に、ユーザーのパスワードをハッシュすることによってソルトが作成されます。
次に、要求されたURL（クエリ文字列を介して最後にユーザー名が追加されたもの）とソルトをハッシュすることにより、署名が作成されます。
最後に、ユーザー名と署名をハッシュすることによってトークンが作成されます。
トークンはヘッダー内でサーバーに渡されます（毎回）。

最初のリクエスト：
最初のリクエストは検証エンドポイントに対するものであり、クエリ文字列としてdevice_idを含める必要があります。
同じ処理（上記と同じ）がサーバーで実行され、トークンがユーザーから送信されたものと一致する場合、device_idはデータベースに保存され、将来の参照のためにそのユーザー名に割り当てられます（デバイスIDは要求されたURLにあります）その後、ユーザー名/デバイスを確認するために使用されます。

後続のすべてのリクエスト：
処理はユーザー側で行われる必要があり、サーバーはすべてのリクエストに対して終了します。トークンは毎回異なります（リクエストされたURLが変更されるため）。
まだ記述されていないため、コードは含まれていません。

4

1 に答える 1

5

認証モデルは共有シークレット認証です。あなたの場合、ユーザーのパスワードは共有シークレットとして機能します。ユーザーとサーバーへのパスワードを事前に取得するための安全な方法があることを確認する必要があります。リクエストに署名するには、すべてのリクエスト ヘッダーとデータを含むメッセージを作成します。次に、そのリクエストをハッシュします。次に、そのハッシュ (トークン) がリクエストと共に渡されます。サーバーは、サーバー上で同じ署名およびハッシュ プロセスを実行し、トークンが一致することを確認します。

あなたの例では、この疑似コードでトークンを作成したいようなサウンドです:

Token = hmac-sha1( Hash(Pasword + Salt) + RequestUrl + UserName )

あなたのやり方は悪くありませんが、私はあなたの方法を Amazon の REST Auth モデルと比較し、彼らが詳述したより近いバージョンを実装します. http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

それらの実装:

"Authorization: AWS " + AWSAccessKeyId + ":"  + base64(hmac-sha1(VERB + "\n" 
                                 + CONTENT-MD5 + "\n" 
                                 + CONTENT-TYPE + "\n" 
                                 + DATE + "\n" 
                                 + CanonicalizedAmzHeaders + "\n" 
                                 + CanonicalizedResource))

除外したいくつかのフィールドを含める正当な理由があります。たとえば、次のようなものがあります。

  • タイムスタンプはリプレイ攻撃を防ぐためのものです。
  • content-MD5 は、リクエスト データの改ざんを防ぐためのものです (POST および PUTS に関連)。
于 2013-01-15T14:51:41.030 に答える