問題タブ [salt]

のPHPマニュアルエントリでcrypt()提供されている情報を読みましたが、Blowfishアルゴリズムをトリガーするソルトの形式がまだわかりません。

手動入力によると、16文字の文字列の先頭として「$2$」または「$2a$」を使用する必要があります。ただし、後で示す例では、はるかに長い文字列' $2a$07$usesomesillystringforsalt$'を使用しています。これは、提供する文字列がモデルに合うようにスライスおよびダイシングされることを示しています。

私が直面している問題は、実際にフグのアルゴvsをトリガーすることですSTD_DES。例：

そのハッシュは明らかに渦巻きではなく、実際STD_DESにはソルトの最初の2文字だけがソルトに使用されています。ただし、PHPマニュアルの例では、ソルトは''で始まる$2a$07$ため、これら3つの文字を同じコードに追加すると、次のようになります。

07$たとえば、ここで''04$として示されている文字に多少の差異を与えることができ、15$両方とも機能しますが、機能01$し03$ない（空白の文字列を生成する）、およびなどの値を使用し99$て、再び85$元に戻すことができることに気付きました。 STD_DES。

質問：

$2a$マニュアルで信じられているように、crypt関数にblowfishメソッドを使用するように指示する''文字列に続くこれらの3文字の重要性は何ですか。

マニュアルによると、' 'はフグの方法を使用する$2a$ように指示するのに十分なはずです。crypt()では、次の3文字の意味は何でしょうか。では、これらの3つの文字が非常に重要である場合、ソルトの正しい形式は何ですか？

この質問は、PHP のcrypt(). この質問では、salt の最初の 7 文字はカウントされないため、salt ' $2a$07$a' は、salt の 1 文字とメタデータの 7 文字のみであるため、長さ 1 であると言われます。

22 文字を超えるソルト文字列を使用する場合、生成されるハッシュ (つまり、切り捨て) に変更はありません。また、21 文字より短い文字列を使用する場合、ソルトは自動的にパディングされます (' $' 文字が表示されます)。これはかなり簡単です。ただし、20 文字のソルトと 21 文字のソルトが指定された場合、21 文字の長さのソルトの最後の文字を除いて 2 つが同一である場合、両方のハッシュされた文字列は同一になります。22 文字の長さのソルトは、最後の文字を除いて 21 の長さのソルトと同じですが、ハッシュは再び異なります。

コードの例:

生産します:

どうしてこれなの？

編集：

一部のユーザーは、文字列全体に違いがあることに気付いていますが、これは事実です。ではsalt_20、オフセット (28, 4) は ですがda$.、 ではsalt_21、オフセット (28, 4) はda2.です。ただし、生成される文字列には、ハッシュ、ソルト、およびソルトを生成するための指示 (つまり$2a$07$) が含まれることに注意することが重要です。違いが生じる部分は、実際にはまだ塩です。実際のハッシュは変更されていませんUxGYN739wLkV5PGoR1XA4EvNVPjwylG。

したがって、これは実際には、生成されたハッシュの違いではなく、ハッシュを格納するために使用されるソルトの違いであり、これがまさに当面の問題です: 2 つのソルトが同じハッシュを生成しています。

Rembmer: 出力は次の形式になります。

ここで、## は、アルゴリズムが実行される反復回数を決定する log-base-2 です。

編集2：

コメントでは、ユーザーが私の出力を再現できなかったため、追加情報を投稿するように要求されました。次のコードの実行:

次の出力が生成されます。

お役に立てれば。

以下に示す多段階認証を実装しました。

角かっこ（[および]）はハッシュを表します

クライアントには、認証に使用されるキーとシークレットがあります。サーバーには、キー、ソルト、および[シークレット+ソルト]を含む行を含むデータベーステーブルがあります。

次に、サーバーは受信したハッシュを自身の情報と照合します。

私の懸念は、これにより、攻撃者がサーバーからソルトを取得し、レインボーテーブルを作成してそのアカウントをハッキングできるようになることです。これについてどう思いますか？

ソルトの唯一の目的はレインボー テーブルの攻撃を防ぐことだと聞きましたが、それ以上の価値があるのでしょうか? 辞書ベースの攻撃も防げませんか? そして、ブルートフォースについてはどうですか、そこで塩は役に立ちますか? 理由を教えてください。

次に、マイクロタイム、128 文字のソルト、および 10 億から 100 億の間の乱数を取り、それらを一緒にハッシュするアルゴリズムがあるとします。これにより、優れたレベルのセキュリティが提供されますか? たとえ攻撃者がそれらの詳細の 1 つを知っていたとしても、残りを計算することは計算上実行不可能であるように私には思えます。そうですよね？

ありがとう、

ベン

編集:明確にするために、攻撃者はハッシュ アルゴリズムにアクセスできないため、システムに情報をスパム送信することはできません。彼らが持っているのはハッシュだけであり、それがどのようにコンパイルされたかを理解する必要があります. ハッシュがどのように生成されたかを知っていたとしても、長いソルトを使用してすべての組み合わせをブルート フォースしようとすると、非現実的になりますか?

また、ハッシュはユーザーのパスワードやユーザー名ではなく、認証に使用されるランダムな文字セットです。そのため、ソルトと乱数を保存する必要はなく、結果のハッシュだけを保存する必要があります。その場合、以下のコードのようなもので表される上記のシステムは、攻撃者がユーザーのハッシュが何であるかを現実的に推測することを防ぐのに適したシステムでしょうか?

上記の数十億ではなく、わずか 1000 ～ 9999 であることはわかっています。

再度、感謝します。

何かについてのフィードバックをお願いします。

基本的に、$uniqueID という値があります。これは、= ID + 名の最初の文字 + 姓の最初の文字 + 文字列「CAN」です。

次に、$salt = sha1($uniqueID); のように $uniqueID をソルト値に変換しました。

次に、md5() を使用して、ユーザーのパスワードをハッシュ値に変換しました。

次に、正しいデータ型を使用して、これら 2 つの値を別々にデータベースに格納しました。

これが2種類のユーザー検証を保護する安全な方法になるかどうか疑問に思っていましたか? パスワードの検証はユーザーが行い、$uniqueID はスクリプトを介して行います。

新しいパスワードを作成する必要があるため、パスワードを思い出させるサービスは提供しません。

また、セッションにいくつかのセキュリティを実装しました。

標準の HTTP 認証スキーム (FORM または DIGEST) と共にソルト付きパスワードを使用することは可能ですか?

私は GlassFish を使用しています。保護されたページをリクエストすると、フォームまたは nonce を含む回答がサーバーから直接返されます。サーバーメカニズムにフックして 302 応答にソルトを挿入する明らかな方法がわかりません (これは良い考えだと思いました)。したがって、私が返すパスワードは、ソルトなしでハッシュすることができます。

そうですか？
ありがとうございました。

I have a potential client that set up their website and membership system in ASP.NET 3.5. When their developer set up the system, it seems he turned off the security/hashing aspect of password storage and everything is stored in the clear.

Is there a process to reinstall/change the secure password storage of ASP.NET membership without changing all of the passwords in the database? The client is worried that they'll lose their customers if they all have to go through a massive password change.

I've always installed with security on by default, thus I don't know the effect of a switchover. Is there a way to convert the entire system to a secure password system without major effects on the users?

典型的なPHPインストールにめったに含まれないライブラリに依存せずに、PHPで暗号的に安全な32バイトのソルトを生成する最良の方法は何ですか?

グーグルで調べたmt_randところ、十分に安全とは見なされていないことがわかりましたが、代替案は見つかりませんでした. ある記事では、からの読み取りを提案しまし/dev/randomたが、これは Windows では機能しません。また、非常に遅いです。

セキュリティと速度の適度なバランスが必要です (つまり、/dev/random通常のように 512 バイトを生成するのに 20 秒もかからないようにする必要があります) 。

Web サイトをフロントエンドとして使用しており、すべてのユーザーは標準の ASP.NET メンバーシップ プロバイダーで認証されています。パスワードは、SQL データベース内に「ハッシュ」されて保存されます。

ここで、管理機能を備えたデスクトップ クライアントを書きたいと思います。とりわけ、ユーザーのパスワードをリセットする方法が必要です。保存されたメンバーシップ データを使用してデータベースにアクセスできますが、パスワードのソルトとハッシュを手動で作成するにはどうすればよいですか? System.Web.Membership 名前空間の使用は不適切と思われるため、新しいパスワードのソルトとハッシュを手動で作成する方法を知る必要があります。

専門家がステップアップ！:)

I've read through many of the questions on SO about this, but many answers contradict each other or I don't understand.

You should always store a password as a hash, never as plain text. But should you store the salt (unique for each user) next to the hashed password+salt in the database. This doesn't seem very clever to me as couldn't someone gain access to the database, look for says the account called Admin or whatever and then work out the password from that?