私が見逃している概念全体を単純化する、これらすべての基本的な何かがあると確信していますが、ここに行きます：
OK、セキュリティのためにパスワードをソルト＆ハッシュしますが、それを行うコードはどうですか？
ホストまたはvpsを使用している場合、そこでコンパイルしたソースを「誰か」が入手することはできませんか？または、データベースにアクセスできる場合、暗号化/復号化を実行するプログラムにアクセスして、アルゴリズムを取得するまでブルートフォース攻撃を行うことはできませんか？
100％安全なものはないことはわかっていますが、このコンテキストでセキュリティをどのように改善できるでしょうか。
ソルトは、データが危険にさらされた場合に、辞書やレインボーテーブルの攻撃からデータをある程度保護します。ブルートフォースは不可能ではありませんが、速度が遅く、パスワードハッシュごとに再度実行する必要があります。塩漬けが行われなかった場合、ブルートフォース攻撃ははるかに簡単に達成できます。
一部の人の言うこととは反対に、ソルトは特別な方法で保護されていません（また、保護する必要もありません）が、ハッシュに追加されたプレーンテキストで存在します。ただし、ハッシュごとに一意である必要があります。そうでない場合、この使用には意味がありません。これは、すべてのハッシュに使用され、保護する必要があるペッパーとは対照的です。この区別のため、コショウへのアクセスが制限されることが保証されていない限り、塩漬けが一般的に好まれます（簡単な作業ではありません）。
セキュリティを強化したい場合は、共有ホストを使用しないでください。また、データベースへの直接アクセスを許可しないでください。また、事前に選別されていない人がシステムにアクセスすることを許可しないでください。実用的な意味では、これらは常に実行可能なオプションではありません。だから、塩を使ってそれと一緒に暮らすだけです:)
ハッシュアルゴリズムに関して、ソースコードに「隠された」ものは何もありません。実際、アルゴリズムを自分で実装するのではなく、強力なハッシュの実証済みのよく知られた実装を使用する必要があります。
塩は保護する必要がある部分です。そのソルトはコードの一部ではなく（またはそうではないはずです）、ある種のファイルストレージ/データベースに保存する必要があり（アプリケーションによって異なります）、ユーザーごとに適用する必要があります（ユーザーJoeはユーザーFredとは異なるパスワードのソルト）。
確かに、各ユーザーのパスワードで使用されるソルトを保護することは非常に重要です。そこで、適切なファイルシステム/データベースのアクセス許可が機能します。
別の注意点として、コードは許可されていないユーザーからも保護する必要がありますが、ソルトを保護する理由ではありません（少なくとも直接ではありません...誰かがソルトにアクセスできる場合、またはコードを自分のコードに置き換える場合は、認証チェックを完全にバイパスします）。