2

私は多くの研究を行ってきましたが、これが私が必要としていることを達成するための最良の方法であるかどうかを判断することはできません。

汎用のWebアプリがあり、それに合わせて汎用のモバイルアプリを作成したいと思います。ユーザーがデータを保存したり、ユーザー固有のデータにアクセスしたりするには、ログインする必要があり、ログインは私のWebアプリのRESTAPIを介して認証される必要があります。

そのため、APIにはモバイルアプリの秘密鍵と公開鍵があります。公開鍵はリクエストの送信元(モバイルアプリ)を教えてくれ、秘密鍵はクエリ文字列をハッシュするための「ソルト」として使用されます。クエリ文字列は、リクエストが届いたときにWebサーバーで再ハッシュされ、有効性が比較されます。 。

ログインするには、ユーザーはユーザー名とパスワードを入力し、上記の方法に従ってクエリ文字列変数として送信されます。クエリはもう一方の端で有効性がチェックされ、ユーザー名とパスワードのペアがデータベースに対してチェックされます。ログインが正しければ、そのユーザーと公開鍵に対してランダムな「認証トークン」が生成され、デバイスにローカルに保存するためにモバイルアプリに返送されます。

次のリクエストがモバイルアプリから着信すると、クエリ文字列変数の1つは、データベース内の「認証トークン」テーブルに対して(アプリの公開鍵を使用して)有効性がチェックされる以前の「認証トークン」です。有効な場合は、リクエストを実行してください。

ここでの私の質問は、私はこれを正しく理解したかということです。これは私が必要なことを達成するための最良の方法ですか?要求が傍受された場合、公開鍵と認証トークンの両方が表示されるため、最後のステップは本当に安全ではないようです。明らかに、リクエストはクエリ文字列のハッシュともう一方の端の秘密鍵に対してチェックされます。これにより、リクエストが悪意のある場所から送信されていないことが確認されます。

他に役立つステップや、見逃したことはありますか?たとえば、リクエストの5/10分の時間枠に対してチェックする必要があるタイムスタンプ変数もあるはずだと読んでいました。5/10分より古いタイムスタンプとリクエストは拒否する必要があります。これは重要ですか?

ありがとうございました。

4

1 に答える 1

2

あなたが説明しているのは、基本的に2本足のOAuthの自作バージョンです。基本的に使用できる実装はたくさんあります。セキュリティ関連のものに関しては、私は通ります。他の人がすでにそれを行っている場合は、車輪の再発明をしないでください。OAuathは、そこにある多くの大きなサイト(Twitter、Facebook、GitHub、Googleなど)で使用されており、OAuth標準に組み込まれた多くの調査を行っています。だから私はそれらを使用することをお勧めします。

送信するメッセージが傍受される可能性があることが懸念される場合は、HTTPSを使用する必要があります...これは、ユーザー名とパスワードの組み合わせをネットワーク経由で渡す場合は、一般的には良い考えです。

于 2012-06-09T12:15:58.330 に答える