強力なハッシュを使用してアプリケーション固有のパスワードを実装するにはどうすればよいですか？
私は、アプリケーション固有のパスワードがセキュリティを向上させるための良い選択であると思われるサービスを実装しています。なぜ、いつ意味があるのかについての質問は、ここですでに説明されています Googleアカウント：アプリケーション固有のパスワードを使用することの意味
今、私はその方法に興味があります。特に、bcryptやscryptのような強力なハッシュを使用します。
- Google、iCloud＆Coはアプリ固有のパスワードのハッシュを保存していると思います。
- すべてのアプリ固有のパスワードが同じユーザー名にマップされるとすると、それは、指定されたパスワードのハッシュを、指定されたユーザー名のすべての既知のハッシュと比較する必要があることを意味しますか？
- もしそうなら、そして私が100から200ミリ秒の間のどこかでmaxtimeでbcryptやscryptのような暗号化アルゴリズムを使用すると言うなら、最悪の場合の待機時間を最小にするためにハッシュと比較を並列化する必要はありませんか？
- 彼らがアプリケーション固有のユーザー名を使用しないことを選択した正当な理由はありますか？例えばたとえば、アカウント「foo」があり、「：」はユーザー名に使用できません。「foo」アカウントのbar-app固有のユーザー名として「foo：bar」を使用してみませんか？そうすれば、リレーションユーザー名<->パスワードは再び1：1になります。これは、ユーザーが複数の名前を覚えておく必要がないためですか？
あなたの考えに感謝します。
私はそのようなシステムを実装しませんでした。
しかし、私はまだあなたの質問に答えることができます（私は願っています）。
アプリケーションごとに異なるパスワードはセキュリティを強化するための優れた機能であり、パスワードが壊れてもすぐにすべてのアプリにアクセスできるわけではありません。
アプリケーションごとに異なるパスワードでログインする場合の問題は、パスワードの量です。 Googleには10個のアプリがあるので、10個の異なる（良い）パスワードを覚えておく必要があります。これは、すべてのサービスに同じものを使用する標準ユーザーにはほとんどありません（悪いものでもかまいません）。パスワードマネージャーがなければ、この負担を克服することは不可能であり、人々は「ねえ、私は一度ログインしました、それで十分ではありません！？」と言うので不平を言い始めます。
技術的には、複数のパスワードと単一のパスワードの速度に（ほぼ）違いはありません。そのようなシステムを実装する場合は、あなたが言及した2番目のアプローチのようなものを使用するので、ユーザー名に使用しているアプリのタグを付けます（これは平均的な攻撃を引き起こす可能性があるため、文字列ではないかもしれませんが、関連するデータがあります） 。そのため、ユーザーはログインしてパスワードを入力し、アプリのパスワードデータベースを開いて名前を調べ、パスワードハッシュを実行して、計算されたタグを保存されているタグと比較します。それらが一致する場合はアクセスを許可し、一致しない場合はアクセスを拒否します。
同じユーザー名で多数のタグを保存する場合（ユーザーが同じアカウントに複数のパスワードを使用できるため、最悪のパスワードの強度に制限されるため、愚かです）、単純にタグを1回計算し（同じソルトを使用したと仮定）、一致するものを探します。賢い場合は、さまざまな塩を使用しているため、パフォーマンスが大幅に低下します。 （最悪の場合、ログイン時間はアカウントの数に比例して増加します）、並列化できない限り、他のユーザーはログインに必要なCPU時間を待たなければならないため、ログインが遅くなる可能性があります。