登録操作では、キー導出の操作を行う場合（PBKDF2など）、以前の値が必要になるため、並列化できないパスワードクリプトがあり、それは線形操作だと思いますか？
このプロセスを遅くすることは、たとえばブルートフォースに対してパスワードがより強力になるため、ユーザーにとっては有益ですが、別の問題があります: DOS 攻撃です! 登録の各操作に1秒かかる場合、NGinxのようなロードバランサーを使用すると、毎秒8つの同時登録操作が処理され、アプリケーションがブロックされますか? 他の操作を追加すると、たとえば 2 秒とすると、アプリケーションは良くないでしょうか?
それで、何か提案はありますか？Tornado は I/O 操作で非同期操作を行うため、Tornado を使用しても問題は解決しません...
PBKDF2のようなキー ストレッチング関数を使用すると、反復回数 (または他の関数の同等のパラメーター) を調整することで、パスワードのハッシュにかかる時間を制御できます。力ずくでパスワードを解読しにくくすることと、DoS 攻撃を回避することとの間には、トレードオフがあることを観察したあなたは正しいです。これら 2 つの考慮事項のバランスを取るには、反復回数を選択する必要があります。
最新の CPU は 1 秒あたり数百万回のハッシュ反復を計算できることに注意してください。たとえば 1000 回の反復回数を使用したとしても、1 つのパスワードを 1000 回反復してハッシュするのに約 1 ミリ秒しかかからないにもかかわらず、ハッシュをまったく反復しないよりも 1000 倍難しくなります。
ログイン DoS 攻撃を回避または緩和する方法は他にもあります。たとえば、IP ベースのスロットリングを実装して、各 IP アドレスが 1 分間に限られた数のログイン試行しかできないようにすることができます。もちろん、分散型 DoS 攻撃はそれを回避できますが、潜在的な攻撃者にとって克服すべきハードルは依然としてあります。
また、ログイン アンチ CSRF トークンを実装する場合(実装する必要があります)、ログイン試行を行う前にトークンを取得するための余分なラウンド トリップを要求することで、特定の単純なタイプのログイン DDoS 攻撃から保護します。 CAPTCHAは、ログイン DoS 試行に対処するためのもう 1 つの便利な方法です。最後に、ログインフォームへの DoS 攻撃が成功してもサイトの残りの部分がダウンしないように、適切なリソース制限を使用して、すべてのログイン要求を別のサーバーやプロセスのセットに制限したい場合があります。
どうしても気を使いたい場合は、パスワードをハッシュするのとほぼ同等の暗号化されたプルーフ オブ ワークをクライアントに送信するように要求することもできます。たとえば、クライアントにランダムな文字列を送信し、ランダムな文字列にサフィックスを加えたものがnゼロ ビットで終わる値にハッシュされるように、その文字列にサフィックスを返すようクライアントに要求できます。ここで、2 nはおおよその反復回数です。このようなシステムのクライアント側を実装するために使用できるJavaScript 暗号化ライブラリが存在します。