アカウント名:
パスワード:
全ユーザ強制パスワード変更にするしかないの?自ら「SHA-1使ってま〜す!」って言ってるようなものだけどね
PHP Manual: パスワードのハッシュ [php.net] より引用(太字強調は引用者)
MD5 や SHA1 そして SHA256 といったハッシュアルゴリズムは、 高速かつ効率的なハッシュ処理のために設計されたものです。 最近のテクノロジーやハードウェア性能をもってすれば、 これらのアルゴリズムの出力をブルートフォースで(力ずくで)調べて元の入力を得るのはたやすいことです。最近のコンピュータではハッシュアルゴリズムを高速に「逆算」できるので、 セキュリティ技術者の多くはこれらの関数をパスワードのハッシュに使わないよう強く推奨しています。
MD5 や SHA1 そして SHA256 といったハッシュアルゴリズムは、 高速かつ効率的なハッシュ処理のために設計されたものです。 最近のテクノロジーやハードウェア性能をもってすれば、 これらのアルゴリズムの出力をブルートフォースで(力ずくで)調べて元の入力を得るのはたやすいことです。
最近のコンピュータではハッシュアルゴリズムを高速に「逆算」できるので、 セキュリティ技術者の多くはこれらの関数をパスワードのハッシュに使わないよう強く推奨しています。
SHA のような fast hash は、大きなファイルから固定長のダイジェストを得るのには便利に設計されており、例えば 1GB = 1,073,741,824 bytes のファイルの SHA-256 ハッシュ値をスマホで短時間で算出することも容易にできます。
一方、bcrypt のような slow hash はパスワードの保護などを目的としており、大きなファイルのダイジェストを現実的な時間で求めることは普通のコンピュータの演算能力では難しいほど計算に時間がかかる設計になってます。というか、Blowfish アルゴリズムは、そもそも 72 bytes までしか対応していません(つまりパスワードの文字数制限を72文字にする必要があります)。パスワードは、こういったパスワードの保護に相応しいハッシュ関数を通してから保存すべきです。
TLS (https など) の証明書のハッシュが SHA-2 で今のところ十分なのは、ハッシュ関数にかけるデータのデータ長がそれなりにあるからであって、fast hash 関数は、総当たりが容易な短いパスワードには使うべきではありません。全ユーザ強制パスワード変更で、ハッシュ関数を SHA-1 から SHA-2 に移行するというのは論外な愚策です。
php の password_hash 関数 [php.net] は大変素晴らしく、現在 bcrypt アルゴリズムが使われていますが、もし将来的に新しくてより強力なアルゴリズムが登場したときには、新たに作成するパスワードハッシュがそれに切り替わるようになっているので、昔作ったプログラムが放置されても安全なアルゴリズムに自動的に移行することができるという優れものです。コストパラメータの適切な設定値を調整し、ストレッチング負荷を適切に設定することも容易です。こういった最先端の方法でパスワードハッシュを保存すべきです。
PHPのpassword_hashってインターフェイスを統一するための単なるラッパーじゃない? と思って少し調べてみました。
一番気になるのは、異なるアルゴリズムでハッシュ化されたパスワードが混在してもうまく扱えるのか、でしたが、ハッシュにはどのアルゴリズムか等の情報も含まれているとのこと。password_verifyの説明を見て理解しました。
「password_」で始まる命令 [php.net]をひととおり見ておくとよいと思います。
> (PHP 5 >= 5.5.0, PHP 7)
PHPの関数は導入バージョンを見れば使っていいかどうかだいたいわかるのがすぐれものですね(褒め殺し)
つまり、パスワードを定期的に強制変更するポリシーは、内部のハッシュ化方式を変更するのに向いているし、変更したタイミングを悟らせない効果もあるってことだな。
「変更」は条件ではないから、定期変更時でなくても、password verify時にこっそり更新すればいいよ。
そういやそうだった。忘れてた…恥ずかしい
今回破られたのは強衝突耐性で、弱衝突耐性が破られたわけではないから、まだ一応猶予はある。移行期間を用意して、順次変えてもらえば良かろ
ログインしたときにパスワードを入力してもらえるのだから古いアルゴリズムで認証した後に、新しいアルゴリズムで再ハッシュすれば良いかと
それとは別にハッシュ単体でのパスワード認証は危険なのでパスワードを考慮した鍵導出アルゴリズムに変更した方が良いでしょう。去年RFC 7914となったばかりのscryptなどがおすすめです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
ハッシュでパスワード保存しているデータベース (スコア:0)
全ユーザ強制パスワード変更にするしかないの?
自ら「SHA-1使ってま〜す!」って言ってるようなものだけどね
パスワードハッシュは SHA-2 (SHA-256 等) も駄目 (スコア:5, 興味深い)
PHP Manual: パスワードのハッシュ [php.net] より引用(太字強調は引用者)
SHA のような fast hash は、大きなファイルから固定長のダイジェストを得るのには便利に設計されており、例えば 1GB = 1,073,741,824 bytes のファイルの SHA-256 ハッシュ値をスマホで短時間で算出することも容易にできます。
一方、bcrypt のような slow hash はパスワードの保護などを目的としており、大きなファイルのダイジェストを現実的な時間で求めることは普通のコンピュータの演算能力では難しいほど計算に時間がかかる設計になってます。というか、Blowfish アルゴリズムは、そもそも 72 bytes までしか対応していません(つまりパスワードの文字数制限を72文字にする必要があります)。パスワードは、こういったパスワードの保護に相応しいハッシュ関数を通してから保存すべきです。
TLS (https など) の証明書のハッシュが SHA-2 で今のところ十分なのは、ハッシュ関数にかけるデータのデータ長がそれなりにあるからであって、fast hash 関数は、総当たりが容易な短いパスワードには使うべきではありません。全ユーザ強制パスワード変更で、ハッシュ関数を SHA-1 から SHA-2 に移行するというのは論外な愚策です。
php の password_hash 関数 [php.net] は大変素晴らしく、現在 bcrypt アルゴリズムが使われていますが、もし将来的に新しくてより強力なアルゴリズムが登場したときには、新たに作成するパスワードハッシュがそれに切り替わるようになっているので、昔作ったプログラムが放置されても安全なアルゴリズムに自動的に移行することができるという優れものです。コストパラメータの適切な設定値を調整し、ストレッチング負荷を適切に設定することも容易です。こういった最先端の方法でパスワードハッシュを保存すべきです。
Re: (スコア:0)
PHPのpassword_hashってインターフェイスを統一するための単なるラッパーじゃない? と思って
少し調べてみました。
一番気になるのは、異なるアルゴリズムでハッシュ化されたパスワードが混在してもうまく扱えるのか、
でしたが、ハッシュにはどのアルゴリズムか等の情報も含まれているとのこと。password_verifyの説明を
見て理解しました。
「password_」で始まる命令 [php.net]をひととおり見ておくとよいと思います。
Re: (スコア:0)
> (PHP 5 >= 5.5.0, PHP 7)
PHPの関数は導入バージョンを見れば使っていいかどうかだいたいわかるのがすぐれものですね(褒め殺し)
Re:ハッシュでパスワード保存しているデータベース (スコア:1)
つまり、
パスワードを定期的に強制変更するポリシーは、内部のハッシュ化方式を変更するのに向いているし、
変更したタイミングを悟らせない効果もあるってことだな。
Re: (スコア:0)
「変更」は条件ではないから、定期変更時でなくても、password verify時にこっそり更新すればいいよ。
Re:ハッシュでパスワード保存しているデータベース (スコア:1)
そういやそうだった。忘れてた…恥ずかしい
Re: (スコア:0)
ハッシュ値からパスワードを算出できるわけではない。
Re: (スコア:0)
今回破られたのは強衝突耐性で、弱衝突耐性が破られたわけではないから、
まだ一応猶予はある。
移行期間を用意して、順次変えてもらえば良かろ
Re: (スコア:0)
ログインしたときにパスワードを入力してもらえるのだから
古いアルゴリズムで認証した後に、新しいアルゴリズムで再ハッシュすれば良いかと
それとは別にハッシュ単体でのパスワード認証は危険なので
パスワードを考慮した鍵導出アルゴリズムに変更した方が良いでしょう。
去年RFC 7914となったばかりのscryptなどがおすすめです。