私はAppEngineでRESTサービスを実行しています(これは関係ないかもしれません)。各RESTリクエストにはユーザーIDとパスワードが付いています。各リクエストの開始時に、パスワードをハッシュして、処理前に自分のレコードと一致するかどうかを確認します。複数のリクエストに対する効率的なパスワードのハッシュ
これは理論的にはうまくいきますが、実際にはユーザーからのリクエストが4秒または5秒ごとに発生します。 BCrypt 500msで各リクエストのパスワードをハッシュします。どのような無駄です!
明らかに、私は、BCryptの時間を最適化したくありません。ハッシュをキャッシュする標準的な方法はありますか? memcacheは、最近ハッシュされたパスワードとそのハッシュのテーブルを保存する安全な場所ですか?私はその時点でMemcacheにユーザーの平文のパスワードを保存することもできると思います。私は500msのハッシュの代わりに3msのmemcacheルックアップをしたいと思いますが、セキュリティは最優先です。何らかのセッション抽象化を実装する方が理にかなっていますか?
アドバイスありがとうございます!
追加のコンテキスト用の編集:これは機密文書の学生データ(等級)を保存する等級表アプリケーションです。教師と生徒はWi-Fiなどのあらゆる場所からログインします。成功したリクエストはすべてhttpsで送信されます。
Google Appsエンジンの操作が長続きするほど基本的なものではないと期待しています...セッションクッキーを発行するのはかなり標準的ですが、安全な接続でなければ盗難/ハイジャックの対象となります...あなたのアプリケーションに関するもう少しコンテキストが、おそらくpplがより有用な答えを出すのを助けるでしょう - あなたの容認できる公差は何ですか...これは銀行のアプリケーションですか? (Googleのアプリケーションでホストされているのであれば疑問だが、理論的な質問...):) – Nathan
@Nathan:ここで問題の一部は、bcryptが遅いと思われることです* http://en.wikipedia.org/ wiki/Key_stretching)。しかし、Rhuideanによれば、パスフレーズを使って、(a)大きい、(b)ランダムな、(c)短命のセッションキーを確立することができます。したがって、オンラインでもブルートフォースでも攻撃者が何らかの形でセッション鍵の格納されたハッシュを取得した場合、サーバを要求またはオフラインでフラッディングします。だから、パスフレーズよりもセッションキーのハッシュのラウンド数を減らすことができます。ほとんどの場合、ゼロラウンドを使用でき、プレーンなセッションキーを保存することができます。 –
@Nathan:OPで探していたコンテキストを追加しました。@SteveJessopというセッションキー用のより速いハッシュについて考えてくれてありがとう。私はこのルートに行くとおそらくゼロを使うだろうと思っていますが、難しさを調整することは考えていませんでした。 –