複数のリクエストに対する効率的なパスワードのハッシュ

Question

私はAppEngineでRESTサービスを実行しています（これは関係ないかもしれません）。各RESTリクエストにはユーザーIDとパスワードが付いています。各リクエストの開始時に、パスワードをハッシュして、処理前に自分のレコードと一致するかどうかを確認します。

これは理論的にはうまくいきますが、実際にはユーザーからのリクエストが4秒または5秒ごとに発生します。 BCrypt 500msで各リクエストのパスワードをハッシュします。どのような無駄です！

明らかに、私は、BCryptの時間を最適化したくありません。ハッシュをキャッシュする標準的な方法はありますか？ memcacheは、最近ハッシュされたパスワードとそのハッシュのテーブルを保存する安全な場所ですか？私はその時点でMemcacheにユーザーの平文のパスワードを保存することもできると思います。私は500msのハッシュの代わりに3msのmemcacheルックアップをしたいと思いますが、セキュリティは最優先です。何らかのセッション抽象化を実装する方が理にかなっていますか？

アドバイスありがとうございます！

追加のコンテキスト用の編集：これは機密文書の学生データ（等級）を保存する等級表アプリケーションです。教師と生徒はWi-Fiなどのあらゆる場所からログインします。成功したリクエストはすべてhttpsで送信されます。

Answer 1

あなたの現在の方法では、試行されたパスワードをmemcacheのbcrypted形式にマッピングすることをお勧めします。 memcacheに平文のパスワードを保存する理由がある場合は、代わりにmd5またはsha1ハッシュをキーとして使用してください。

追加の手順は実際には必要ありません。 memcacheに保存されたアイテムは他のアプリに漏れません。

Answer 2

REST APIの通常の経験則は、完全にステートレスのままにすることですが、と同様にgotoのように、要件に応じて時間と場所があります。クライアントが一時的なセッション鍵を保存するという考えに反論していない場合は、一時的にセッション鍵を再生成する必要があります。

クライアントがリクエストを行うときに、ユーザーがユーザーIDとパスワードと共にセッションキー変数を送信しているかどうかを確認します。そうでない場合は、現在のサーバー時刻とパスワードに基づいてパスワードを生成し、クライアントに渡します。作成時間とともに自分のデータベースに保管します。次に、クライアントがセッション鍵を含む要求を行うと、ハッシュを必要とせずに、データベースに格納されているセッション鍵と直接比較することで検証できます。数時間ごとに鍵を無効にする限り、セキュリティ上の懸念はあまりないはずです。あなたが現在パスワードとユーザーIDをクリアで送信している場合は、既にセキュリティ上の問題があります。