自動生成されたパスワードをハッシュしないことのリスクは何ですか？
まとめ
パスワードをハッシュする主な理由は、ユーザーがパスワードを再利用しているため、漏洩したパスワードによってユーザーの機密情報が開示されるためです（cf. this question 。）。
パスワードが自動生成され、ユーザーが変更できない場合でも、パスワードの（ソルトされた）ハッシュのみを保存する十分な理由はありますか？
具体的な例
たとえば、デバイスAがHTTPS経由でWebサービスBを呼び出すなど、通信する必要がある2つのコンポーネントがあります。悪意のある俳優がBに接続してAのふりをするのを防ぐために、Aはパスワードを提供します。パスワードを自動生成し、AとBの構成ファイルに入れます。
ここで、Aは明らかにプレーンテキストのパスワードを必要としますが、Bはハッシュのみを必要とします（BはAから受け取った値をハッシュし、それをファイルにあるハッシュと比較できるため）。したがって、私のセキュリティを意識した直感は、Bの構成ファイルにのみハッシュを格納する必要があることを示していますが、長所と短所を見ると、それほど明白ではありません。
Bにハッシュのみを格納する利点：
- B自体が危険にさらされずにBの構成ファイルが危険に危険にさらされる場合、攻撃者はパスワードを使用してAになりすますことができます（B自体が危険にさらされている場合、攻撃者は明らかにしませんパスワードはもう必要ありません。）
Bにハッシュのみを格納することの短所：
- Aが壊れて置き換えが必要な場合は、元のパスワードがなくなったため、Bのハッシュを変更する必要があります。 （または、クライアントが前提AとBを実行するときに、パスワードを安全に保管する必要があります。パスワードは安全に保管されません。または、[〜＃〜] i [〜＃〜 ]パスワードをどこかに安全に保管する必要があります。これは、私にとって追加の作業と責任のリスクです。）
私が見逃した他の長所/短所はありますか？
パスワードをハッシュ化する主な理由は、ユーザーがパスワードを再利用しているため、漏洩したパスワードがユーザーに関する機密情報を開示するためと思われます
これは誤った説明です。ハッシュの主な理由は、攻撃者がデータベースへのアクセス（データベースへの直接またはそのバックアップへのアクセス）を取得した場合にパスワードを開示から保護するためです。パスワードがユーザーによって作成されたものであるか、または何らかのツールによって生成されたものであるかは関係ありません。
弱いパスワードはハッシュによって「改善」できるというのはあなたの言うとおりです。しかし、ハッシュによって脆弱なパスワードを安全にすることはできません。例えば。攻撃者が100 000個の脆弱なパスワードを含むデータベースを取得した場合、Argon2のような「リソースが消費される」ハッシュを使用しても、攻撃者はそれらすべてを簡単にテストできます。ハッシュがパスワード品質のチェックに取って代わるべきではないのはそのためです。ユーザーがパスワードを変更する場合、十分な複雑さ（長さ、ランダム性）を確保するためにパスワードを検証する必要があります。これは、実際のユーザーのパスワードにも、「デバイスA」のような「テクニカル」ユーザーのパスワードにも同様に適用できます。
私の意見では、ハッシュの生成（デバイスAのパスワードを更新/置換する必要がある場合）は非常に簡単です。そして、これはAが危険にさらされた緊急の場合だけでなく、定期的に実行する必要があります。月に1回または3か月に1回。管理者はそれのためのツールを持っている必要があります。そのため、パスワードの更新には数秒かかります。そのため、デメリットはありません。
TLDR：実際の欠点はなく、利点のみがあります。