私はjBCryptライブラリを使用して、ユーザーが私のアプリを使用して登録するときにユーザーパスワードをハッシュします。
私は次のように、基本的なハッシュ関数をソルトとともに使用しています。
String pass = BCrypt.hashpw(rawPass, BCrypt.gensalt());
登録時に1〜2分のハングに気づき、デバッガーをチェックして、BCryptが原因であることを確認しました。
パスワードのソルトは本当にそれだけの処理能力を必要としますか？もしそうなら、それをハッシュするためにプレーンテキストのパスワードをサーバーに送信するのが良い代替案でしょうか？この問題に関する私の当初の考えは、どこにでも送信される前にハッシュすることでした。何か案は？
これは、Core2Duoプロセッサを搭載したMacラップトップでかかった時間をリストした記事です。したがって、はい、Bcryptはモバイルデバイスでは非常に遅い可能性があります。
もう1つの一般的な問題は、初期化SecureRandomが非常に遅くなる可能性があり、十分なランダムデータがないためにハングする可能性があることです。これは、マシンやオペレーティングシステムによって異なります。それについては他の場所でたくさんの議論がありますが、それを使用して自分で初期化するか、ランダムデータ生成を分離するために個別に呼び出してから、への呼び出しの時間を計ることnew SecureRandom()によってテストすることをお勧めします。gensalthashpw
もう1つの質問は、なぜ実際にクライアントでハッシュしたいのかということです。クライアントに保存してローカルにログインしている場合、それは理にかなっているかもしれませんが、サーバーに送信され、通常のログインでサーバーにプレーンテキストのパスワードを送信する必要がある場合は、何も得られません。また、よくある誤解は、パスワードをサーバーに送信する前に（ログイン時に）ハッシュすると、実際にはプレーンテキストのパスワードを送信するのと同じであるにもかかわらず、ある程度の保護が提供されるというものです。攻撃者は、アクセスできるようにするためにハッシュを取得するだけです。
パスワードのハッシュは、パスワードストア自体が危険にさらされた場合に、攻撃者がアクセスを取得する（または少なくともパスワードの速度を低下させる）のを防ぐ手段です。
したがって、パスワードがサーバーに保存されている場合は、パスワードをプレーンテキストで（安全なチャネルを介して）送信し、サーバーがパスワードのハッシュ方法を決定する必要があります。