3

これはログイン画面を備えた既存のシステムです。現在、いくつかのサービスを REST サービスとして公開しています。この Rest(jersey) サービスの認証トークン ログイン システムを構築します。ユーザーがユーザー名とパスワードを送信すると、サーバーは次のように計算されたトークンを返します。

sha1(username+password+currenttime(or any random number))

ユーザーはこのトークンを使用してアプリにログインし、さらにリクエストを行います。サーバーは、タイムスタンプとユーザー ID を使用してトークンのコピーをデータベースに保持し、タイムスタンプが有効な場合はそのユーザーをログインさせます。

HTTPSが使用されることを考慮して、いくつか質問があります。

私のデザインはすべて問題ないように見えますか? (ハッシュの生成とDBに保存する方法)私には、POSTリクエストでプレーンなユーザー名とパスワードを送信する必要があることが最も弱点に見えますが、HTTPSであるため、問題にはならないと思います。

もう1つ、最初のリクエストについては、既存のシステムであるため、DBにユーザーパスワードを持っていませんが、それらのソルトハッシュバージョンを保持しています。すべてのクライアントにこのソルトアルゴリズムを提供してパスワードのハッシュを送信するのは安全ではないと思うので、パスワードではなくハッシュを比較します。これは意味がありますか=

4

2 に答える 2

1
  1. 通常、HTTP ヘッダーでトークンを渡します。

  2. POST と PUT のどちらを使用するかは問題ではありません。

  3. リプレイ タイプの攻撃を防止するために私が提案するもう 1 つの方法は、各 POST 要求にナンス (常に増加する値) を含めることです。次に、サーバーは最後に使用されたナンスを追跡し、以前に使用されたナンスを使用するリクエストの実行を防ぎます。

于 2012-12-26T13:57:48.737 に答える