web-dev-qa-db-ja.com

パスワードとしてパスワードハッシュを使用していますか？

わかりました、これはおそらく本当に愚かな考えですが、実際にはわかりませんなぜそれは悪い考えでしょう。多分誰かが私を啓発することができます。

Bcryptのようなパスワードに優れたハッシュアルゴリズムを入力して、そのハッシュ自体をWebサイトのパスワードとして使用できないのはなぜですか。

アバランシェ効果により、ユーザーは通常のパスワードの微妙な派生を使用して、実際のWebサイトで使用するための適切な（そしておそらくはより良い）パスワードを作成できます。

たとえば、ユーザーのパスワードが「password123」であり、いくつかの異なるサイトにログインしたいとし、次のようにサイト名をパスワードの先頭に追加するとします。

Amazon.com = "amazonpassword123"

Facebook.com = "facebookpassword123"

等々.....

攻撃者がこのユーザーのパスワードの命名システムを推測するのは簡単であるため、通常、これは非常に悪い習慣です。しかし、ユーザーがこれらのWebサイトにログインする前にハッシュアルゴリズムを使用してパスワードを実行し、ハッシュ自体をパスワードとして使用した場合、非常に覚えやすく（おそらく）より安全なものになります。

これには見られない不利な点はありますか？

passwordscryptographyhashpassword-managementbcrypt
2
user97462

いいえ。それは素晴らしいアイデアです。秘訣は、これらのハッシュをさまざまなサイトの長さと複雑さの要件に取り込むことです。

PwdHash は1つの素晴らしい例です。 HMAC-MD5を使用しますが、出力から非常に多くのビットをドロップします。 （これは技術用語です。その上、MD5のプリイメージ耐性はまだ壊れていません。）さらに重要なことに、彼らは長さと複雑さの要件の問題をうまく解決し、多くの異なるプラットフォーム（Firefox、Chrome、Mac OS、 iOS、Android、ウェブサイト自体）。

マスターパスワード は、HMAC-SHA-256を使用する別のアプリですが、MacおよびiOSでのみ使用できます。また、エンコード手法も少し不安定です。母音の位置を制御して「発音可能」にしようとするため、デフォルトはエントロピーが低すぎます。バグレポートを提出しましたが、エントロピーは無関係で頭を濡らすように言われました。シリアライゼーションに偏執狂的な設定を使用することは問題ありませんが、私にとっては、PwdHashに比べて頭痛の種です。

これがこのカテゴリの最新技術であることは少し悲しいことです。また、PwdHashの人々がscryptを使用していなかったことも悲しいことです。

1
Reid Rankin

hash(site_name + pw)のような構造は、パスワードが高エントロピーであり、ハッシュに十分なビット（たとえば、標準の暗号化ハッシュが持つ128以上のビット）がある限り、安全なパスワードを生成します。非暗号を使用しないでくださいcrc32のようなハッシュ）。簡単に推測できるpw = _password123_のようなものを使用する場合、巧妙な攻撃者は、自分が制御しているサイトでパスワードを見て自分のスキームを見つけ出し、他のすべてのサイト（たとえば、 example.comのパスワードが md5("examplepassword123") である場合、md5(site_name + pw)の形式のパスワードをテストすることでパスワードを元に戻すことが可能かもしれません-何十億ものmd5を生成できますコンピューターごとの1秒あたりのハッシュ数。攻撃者がパスワード生成スキームを知らないことに頼るのは悪い考えです。代わりに、固有のランダム性が高い実際のパスワードに依存する必要があります（ Kerckhoffsの原則 を参照）。

ただし、bcryptのようなものを使用する場合、bcryptはランダムな128ビットのソルトを作成するので弱いパスワードで問題ありません。これは、最も弱いパスワードでさえ合理的でないように十分なエントロピーを提供します（使用するソルトがハッシュ）。このランダムに作成されたソルトを保存して再度ログインできるようにする必要があることに注意してください。この時点では、アクセスするWebサイトごとに完全にランダムに生成されたパスワードを使用する方が簡単なはずです。

pythonを使用して bcrypt を使用した例を（ipythonインタープリター内で）示すには：

_In [1]: import bcrypt

In [2]: bcrypt.hashpw('amazonpassword123', bcrypt.gensalt(10))
Out[2]: '$2b$10$//rLpdWc/0hljdOf90366u1uaRch7q59AxF0qcodHvDckO1nd..ky'

In [3]: bcrypt.hashpw('amazonpassword123', bcrypt.gensalt(10))
Out[3]: '$2b$10$eUsCtvQ9mvYA2qAEShaqjOqgYogRP4mohEag5bm3Hls10JPSQxU4y'

In [4]: bcrypt.hashpw('amazonpassword123', Out[2])
Out[4]: '$2b$10$//rLpdWc/0hljdOf90366u1uaRch7q59AxF0qcodHvDckO1nd..ky'
_

同じものをbcryptで2回ハッシュすると、ランダムに作成された2つの異なるソルト（2 ^ 10ラウンドのハッシュ）を使用したため、完全に異なるハッシュが生成されることに注意してください。これが_Out[2] != Out[3]_の理由です。これは、パスワードにbcryptハッシュを照合する場合（ハッシュにはソルトが含まれているため）には問題ではないため、データベースに格納されているハッシュを提供してソルトとして使用し、格納されているハッシュと一致することを確認するだけです。これが_Out[2] == Out[4]_の理由です。

心配するもう1つの問題は、サイレントにパスワードを切り捨てるサイトです。最初の7文字が$2b$<lg(number of rounds)>$である完全なbcryptハッシュを使用すると、パスワードが大幅に弱くなる可能性があります。たとえば、私が仕事で使用する有名なベンダーが提供するVPNは、ユーザーパスワードを8文字に切り捨てます（ただし、はるかに長いパスワードを入力できます-最初の8つだけをチェックします）。

1
dr jimbob