Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。1,536件103アプリケーションでログイン機構を作るために、パスワードハッシュをDBに保存します。使おうかと考えています。Manualいまさら聞けないパスワードの取り扱い方ところが、この関数のマニュアルにはこう書かれていました。文字までに切り詰められます。調べてみると、この制約を回避するためにパスワードをあらかじめ別のハッシュ関数にかけておくとよい、という話が見つかりました。限定しているからこういう方法をとっているのではないかと思いました。72文字を超えるパスワードを許容し、尚かつほかの実装方法もいとわないのであれば、これは使わない方がいいのでしょうか。推奨されるのでしょうか。関数を使っているようなので、同じ問題があると思っています。票8「何を使うべきか」という質問であれば要件次第と言う答えにしかならないと思います73文字目以降が無視されるのは不可、複数のハッシュ関数を使うのは気持ち悪い→crypt()を使ってBROWFISH以外で自前実装。低レイヤのハッシュ関数で自前実装(この項について追記を読んでください)73文字目以降が無視されるのは不可だが複数のハッシュ関数という点は気にしない→ハッシュ関数を通してからpassword_hash()73文字目以降が無視されてもかまわない→そのままpassword_hash()ほとんどのアプリケーションでは72文字もあればパスワード強度としては十分でしょうから73文字以降が無視されたとしても現実的には問題ないと思います。更新された質問に合わせて追記。password_hash()が依然としてベストプラクティスなのか、もしくはよりよい代替手段があるのか、ということですね。password_hash()を直接置き換える代替手段は提供されていない一方、password_hash()の文字数問題は前記の通り現実のアプリケーションに深刻な影響を与えるものとは言えずpassword_hash()を忌避する積極的な理由はないないので、結局は上に書いたとおりになると思います。いかなる場合もベストプラクティス、から、条件付きではあるがベストプラクティス、にニュアンスは変わっていますが、現実には深刻に捉えなければならない条件とは言えないので依然としてベストプラクティスには違いない、と言うことでいいのではないでしょうか。ASCIIの印字可能文字95種を72文字使うと約2.5e+142でbit数でいうと473bitになるので、SHA384とSHA512の間ぐらいになります。逆に、512bitを文字数に直すと78文字です。(追記)PHPのbcrypt実装はバイナリセーフではないため、生のハッシュ値をpassword_hashに渡すと意図しない切り詰めが生じる場合があります。https://blog.tokumaru.org/2019/02/caution-bcrypt-with-sha512.htmlハッシュ値をpassword_hashに渡すのは避けてください。個の銅バッジ複数のハッシュ関数を使うのは漠然と不安というだけなので、そこに拘っているわけではないのです。その辺りがもう少し伝わるよう質問文を修正してみました。真面目に実装してそうなものがあったりしました。最新のものにマージしても動きそうなので、独自実装をメンテする覚悟があるなら工夫してみるのも一つの手かもしれません。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。