2

そのため、最近、パスワードを保護する方法について多くの研究を行っています. 基本的なことは理解できたと思います。そのため、php でパスワードを保護する独自の関数を作成しようとしています。

しかし、パスワードのソルト化に関しては、私はやや混乱しています。ランダムな一意のソルトを作成し、それをパスワードに追加してハッシュし、最終的にハッシュされていないソルトとハッシュされたパスワード/ソルトの組み合わせをデータベースに一緒に保存します。これにより、ハッカーがデータベースとハッシュ化されたパスワードへのアクセスを取得した場合、ハッカーの検索スペースが増加します.

したがって、これはセキュリティの完全なやり過ぎのように思えますが、ソルトは常にパスワードの前または後ろに追加されています。SINGLE ユーザーのパスワードを見ると、この一意のソルトは検索スペースに影響しませんか? 各ユーザーは独自のソルトを持っているため、すべてのユーザーの全体的な検索スペースが劇的に増加します.

ユーザー名/2の長さなど、パスワード内の予測可能な半ランダムな場所にソルトを挿入するアルゴリズムを作成する方が安全ではないでしょうか? たとえば、私が提案したセキュリティ機能の手順は次のとおりです。

Create a random salt
take username length %(mod) password length
insert the salt at the spot determined
hash

実行例:

random salt = 12345
len("imauserwithalongname") % len("mypass") = 2
valueToHash = my12345pass

これで、クラッカーは php/source を見ずにソルトをどこに置くべきかわかりません (間違っていたら訂正してください)。

また、セキュリティはアルゴリズムの秘密性ではなくキーのセキュリティに依存する必要があることも知っていますが、システム全体がアルゴリズムの秘密性に依存しない限り、それに基づいてレイヤーを追加しても問題はないと思います。

編集:これを行うと、クラッカーの検索スペースが劇的に増加しますか?

また、パスワードの長さに依存する場所にソルトを配置すると、たとえユーザーごとであっても、辞書攻撃を使用する目的が損なわれるのではないでしょうか?

4

4 に答える 4

3

別の場所に塩を挿入しても、検索スペースは増加しません。ユーザーごとにランダムなソルトを使用している場合、ハッカーはユーザーごとに各ソルトが何であるかを知りません。ハッシュされていない文字列内でのその位置の知識は重要ではありません。

bcryptまたはを使用しPBKDF2ます。どちらのアルゴリズムも、salt とサイクル数を強制します。あなたが十分に辛抱していれば、PHP 5.5 はそれを可能にしますpassword_hash($password)。

于 2013-01-25T06:07:00.633 に答える
1

そのため、php でパスワードを保護する独自の関数を作成しようとしています。

うわー、ちょっと待って。

暗号学者から私たち単なる人間に受け継がれた格言がありますが、これは何年もの間真実でした. ことわざは次のようになります。

独自の暗号を発明しないでください。

大きな声で言ってから、もう一度言ってください。

あなたがパスワードを保護しようとしているだけなのは知っていますが、私はそれを邪魔にならないようにしなければなりませんでした。あなたが達成したいことをするために、たくさんの試行錯誤された方法があります。

調査を行っていただいたことに感謝しますが、インターネットには恐ろしい恐ろしい情報があふれているため、役立つ記事を紹介します。

素敵な短いリスト。

参考になるキーワードをご紹介します。

  • Bcrypt
  • Scrypt (PHP がサポートされている場合は、誰かがこれを削除してください)

再び非常に短いリストです。

あなたの特定の懸念に対処するため。ソルトは、攻撃者が有効なパスワード/ハッシュの組み合わせのテーブルを事前計算するのを防ぐように設計されていると言うので、非公開にする必要はありません。ただし、弱いハッシュ アルゴリズムを使用すると、値がすぐに失われます。

あいまいさによるセキュリティは、見た目ほど優れていません。ハッカーが DB へのアクセス権を取得した場合、ファイルシステムへのアクセス権も取得する可能性が非常に高くなります。彼らがあなたのソースにアクセスできるようになった場合、パスワードを保存する独自の方法は議論の余地があります。

要約すると、カスタム アルゴリズム + 弱いハッシュ = 安全ではありません。

代わりに、試行錯誤された鍵導出関数/鍵強化アルゴリズムを使用したいと考えています。

これらは、コンピューターがハッシュを生成するのを非常に困難にするように設計されており、攻撃者がパスワードをブルート フォースすることを非常に困難にします。

Bcrypt はソルトをパスワードの横に保存し、非常に安全であることが証明されています。実際、セキュリティの専門家がパスワードをハッシュする方法として現在推奨しているほど十分に安全です。

PHP 5.5 では、Bcrypt に基づいた単純なパスワード ハッシュ API が導入されました。5.5 未満のバージョンには、まったく同じことを行うパスワード ハッシュ互換ライブラリがあります。

それはあなたにとって十分なはずです。

于 2013-01-25T08:24:34.663 に答える
0

個人的にはやり過ぎだと思います。ハッシュをソルトする最も効率的な方法は、動的なレコード固有のものと静的なものをシステム上の読み取り専用ファイルに格納することです。これは、ハッシュをソルティングする非常に効率的で安全な方法です。

于 2013-01-25T06:04:20.667 に答える
0

塩の目的を誤解していると思います。ソルトはハッシュ値とともに平文で保存されるため、攻撃者の検索スペースを増やすことはありません。ソルトの目的は、攻撃者が単一のレインボー テーブルを構築できず、保存されているすべてのパスワードを取得できないようにすることです。

すべてのパスワードに同じソルトを追加する場合、攻撃者はインターネットから事前に計算された既存のレインボー テーブルを単純に使用することはできず、まさにこのソルト用の新しいレインボー テーブルを作成する必要があります (既存のレインボー テーブルには、" horse」ですが、horse8ze*w398dhek3+qmxno0 のようなパスワードではありません。残念ながら、この単一のレインボー テーブルを使用して、すべてのパスワードを取得できます。

そのため、すべてのパスワードに一意のソルトを使用します。攻撃者は、パスワードごとに個別のレインボー テーブルを作成する必要がありますが、既に一致するものを見つけた (?) 場合、テーブルを後で他のパスワードに再利用することはできません。つまり、ブルートフォースはレインボーテーブルを構築するよりも高速であるため、レインボーテーブルを役に立たないようにしました。

そのため、salt はパスワードごとに一意である必要があり、可能であれば予測できないものにする必要があります。これらの基準を決定論的コンピューターで満たすのは困難です。できる最善の方法は、オペレーティング システムのランダム ソースを使用してソルトを構築することです。BCrypt や PBKDF2 などのパスワード用の優れたハッシュ アルゴリズムは、ハッシュを繰り返して遅くし、各反復でパスワードと元のソルトを組み合わせます。パスワードとソルトを連結しただけではありません。

塩をどこかに秘密にするというあなたの考えは、秘密を追加します（塩はどこにありますか？）、攻撃者があなたのコードを知らない限り、それは機能します。データベースを取得する (SQL インジェクション) ことは、コードにアクセスすることよりも確かに簡単ですが、ペッパーを使用すると同じ目標をはるかに簡単に達成できます。

これをチュートリアルで要約しようとしましたが、見たいと思うかもしれません。

于 2013-01-25T08:16:45.473 に答える