language-agnostic - ハードコードされたパスワードはソルト/ハッシュする必要がありますか？

Question

StackOverflowには、データベースのないシンプルなログインシステムに関する多くの質問があります。「それをするのは本当に理にかなっているのか」と思ったとき、私は最近のものにソルトハッシュアプ​​ローチを提案しようとしていました。

私は何年もの間、塩漬けのハッシュをデータベースに保存してきましたが、なぜそれがより安全なのかを理解しています。データベースが危険にさらされた場合、データベースに含まれる情報により、誰も私のシステムにログインできなくなります（プレーンテキストのパスワードをデータベースに保存していた場合とは異なります）。 db）。

しかし、データベースを含まない設定では、ハッシュとソルティングはセキュリティ上の利点を提供しますか？私が考えることができる唯一の理由は、攻撃者が私のサーバー側コードへの読み取り専用アクセスを取得した場合、パスワードを把握することができないということです。これはありそうなシナリオですか？攻撃者がファイルへの書き込みアクセスを取得するとすぐに、攻撃者は何でもできるからです。

だから私の質問は、非常に単純なデータベースのないログインシステムをセットアップするとき、パスワードをソルト/ハッシュするべきか、それともプレーンテキストとして保存するべきかということです。

Answer 1

はい、それでもそれらをハッシュしてソルトするという利点があります。スクリプトのソースコードが漏洩した場合、人々はハードコードされたパスワードまたはグーグルをハッシュに使用し、入力値を見つける可能性があります。ソルトハッシュではどちらも不可能です。

Answer 2

「私のソースコードは、データベースよりも攻撃者に読み取られる可能性が大幅に低いか」という答えを理解できれば、この質問に答えられると思います。

そうではないことをお勧めします。バックアップの方法などによっては、ソースがリークする可能性がやや低くなる可能性があります。それでも、リークする可能性が非常に低いため、リスクを無視できるとは思えません。データベースに対する同じリスクを無視しないでください。データベース内のパスワードをソルト/ハッシュする必要がある理由は、攻撃者がその内容を表示できることを意味するデータベースの特別なプロパティがあるからではありません[*]。攻撃者はあらゆる種類のものを何らかの方法で見ることができるからです。

実際、システムで作業している人は誰でもソースにアクセスする必要があるかもしれませんが、システムで作業しているすべての人が必ずしもライブDBのコンテンツにアクセスする必要があるわけではないことを考えると、ソースコードはデータベースよりもリークする可能性が高くなります。開発者が不正直だとは思いませんが（パスワードの漏洩よりも問題が深刻です）、ソースの共有に関するロジスティクスでは、バックアップに関するロジスティクスよりも、誤って漏洩する可能性のある方法が多く（またはまったく異なる）導入される可能性があります。 DB。

個人的には、あなたの状況では、ハッシュ/ソルトされたパスワードだけを含む小さなファイルをサーバー上に作成します。アプリのさまざまなインスタンスをインストールするユーザーは、実際のアプリケーションコードとは別に、独自のパスワードを含む独自のバージョンのこのファイルを生成できます。彼らは、ソースコードと同じ書き込みアクセス制限でそれをロックダウンする必要があります。

このファイルを「読み取り専用データベース」と呼ぶか「サーバーコードの一部」と呼ぶかは、パスワードを「ハードコードされた」と呼ぶかどうかに影響する可能性はありますが、攻撃者がファイルを簡単に表示できるかどうかには影響しません。 "。

[*]もちろん、特定のデータベース、SQLインジェクション攻撃などに特有の潜在的な欠陥があります。これらは、データベース内のパスワードをソルトおよびハッシュする必要がある決定的な理由ではありません。

Answer 3

さて、スティーブジェソップがすでに概説したように。ソースコードが漏洩したり、手に入る可能性が高くなります。パスワード（私が理解していること）をハードコーディングする場合は、2つの部分のデータ構造として保存してみませんか=>使用されるソルトとハッシュされたパスワード。あなたはそれを知っていますが、それはソースコードには決して現れません。これは、DB接続文字列などで行うことでもあります。その下の変数にあるキーで暗号化します。したがって、ソースコードに正しく表示されることはありません。交差しない限り、メモリダンプにさえないかもしれません。