免責事項:この回答は2008年に書かれました。
それ以来、PHPは私たちpassword_hash
にpassword_verify
し、その紹介以来、それらは推奨されるパスワードのハッシュとチェックの方法です。
答えの理論はまだ良い読みです。
TL; DR
しない
- ユーザーがパスワードに入力できる文字を制限しないでください。馬鹿だけがこれを行います。
- パスワードの長さを制限しないでください。ユーザーがsupercalifragilisticexpialidociousを含む文を必要とする場合は、使用を妨げないでください。
- パスワードのHTMLや特殊文字を取り除いたりエスケープしたりしないでください。
- ユーザーのパスワードをプレーンテキストで保存しないでください。
- ユーザーがパスワードを紛失して、一時的なパスワードを送信した場合を除いて、ユーザーにパスワードを電子メールで送信しないでください。
- 決して、決してパスワードをログに記録しないでください。
- SHA1またはMD5、さらにはSHA256でパスワードをハッシュしないでください!現代のクラッカーは、(それぞれ)60および1,800億ハッシュ/秒を超える可能性があります。
- bcryptとhash()の生の出力を混在させないでください。16進出力を使用するか、base64_encodeを使用してください。(これは、
\0
セキュリティが大幅に低下する可能性のある不正が含まれている可能性があるすべての入力に適用されます。)
ドス
- 可能な場合はscryptを使用してください。できない場合はbcrypt。
- SHA2ハッシュでbcryptまたはscryptを使用できない場合は、PBKDF2を使用します。
- データベースが危険にさらされたときに全員のパスワードをリセットします。
- 妥当な8-10文字の最小長を実装し、さらに、少なくとも1つの大文字、1つの小文字、数字、および記号を必要とします。これにより、パスワードのエントロピーが向上し、クラックが困難になります。(いくつかの議論については、「何が良いパスワードを作るのか?」セクションを参照してください。)
とにかくパスワードをハッシュするのはなぜですか?
パスワードのハッシュの目的は単純です。データベースを危険にさらすことにより、ユーザーアカウントへの悪意のあるアクセスを防止します。したがって、パスワードハッシュの目標は、プレーンテキストのパスワードを計算するのに時間やお金がかかりすぎることで、ハッカーやクラッカーを阻止することです。そして、時間/コストはあなたの武器の最高の抑止力です。
ユーザーアカウントに適切で堅牢なハッシュが必要なもう1つの理由は、システム内のすべてのパスワードを変更するのに十分な時間を与えるためです。データベースが危険にさらされている場合、データベースのすべてのパスワードを変更しない場合でも、少なくともシステムをロックダウンするのに十分な時間が必要です。
Whitehat SecurityのCTOであるJeremiah Grossman がWhite Hat Securityのブログで、パスワード保護のブルートフォースでの破壊を必要とした最近のパスワード回復について述べています。
興味深いことに、この悪夢を生き抜くことで、パスワードの解読、保存、複雑さについては知らなかったたくさんのことを学びました。パスワードの保存が、パスワードの複雑さよりもはるかに重要である理由を理解するようになりました。パスワードの保存方法がわからない場合、本当に頼りになるのは複雑さだけです。これは、パスワードと暗号の専門家には一般的な知識かもしれませんが、平均的なInfoSecまたはWebセキュリティの専門家にとっては、私はそれを非常に疑っています。
(エンファシス鉱山。)
とにかく良いパスワードを作るものは何ですか?
エントロピー。(私がRandallの見解に完全に同意しているわけではありません。)
つまり、エントロピーとは、パスワード内の変動量です。パスワードが小文字のローマ字のみの場合、それは26文字だけです。それはあまり変化ではありません。英数字パスワードの方がよく、36文字です。ただし、記号を使用して大文字と小文字を区別できるのは、およそ96文字です。それは単なる文字よりもはるかに優れています。1つの問題は、パスワードを覚えやすくするために、パターンを挿入することです。これにより、エントロピーが減少します。おっとっと!
パスワードエントロピーは概算です簡単にできます。ascii文字の全範囲(約96の入力可能な文字)を使用すると、1文字あたり6.6のエントロピーが得られます。これは、パスワードの8文字では、将来のセキュリティにはまだ低すぎる(52.679ビットのエントロピー)です。しかし、朗報です。長いパスワード、およびUnicode文字を含むパスワードは、パスワードのエントロピーを実際に増加させ、解読を困難にします。
Crypto StackExchangeサイトには、パスワードエントロピーに関するより長い議論があります。優れたGoogle検索でも多くの結果が表示されます。
私が@popnoodlesと話したコメントで、Xの長さのパスワードポリシーをX個の文字、数字、記号などで強制すると、パスワードスキームをより予測可能にして実際にエントロピーを減らすことができると指摘しました。私は同意しますよ。Randomessは、可能な限り真にランダムであり、常に最も安全ですが最も記憶に残る解決策です。
私が知る限り、世界最高のパスワードを作成するのはCatch-22です。覚えにくい、予測し難い、短すぎる、Unicode文字が多すぎる(Windows /モバイルデバイスでは入力が難しい)、長すぎるなどのいずれかです。私たちの目的には本当に十分なパスワードがないため、パスワードを保護する必要があります。フォートノックスにいた。
ベストプラクティス
Bcryptとscryptは現在のベストプラクティスです。Scryptは時間の経過とともにbcryptよりも優れていますが、Linux / UnixやWebサーバーによる標準としての採用は見られておらず、そのアルゴリズムの詳細なレビューはまだ投稿されていません。しかし、それでも、アルゴリズムの将来は有望に見えます。Rubyを使用している場合は、scrypt gemが役立ちます。Node.jsには、独自のscryptパッケージがあります。PHPでScryptを使用するには、Scrypt拡張機能またはLibsodium拡張機能を使用します(どちらもPECLで使用できます)。
bcryptの使用方法を理解したい場合、またはより良いラッパーを見つけたり、よりレガシーな実装にPHPASSのようなものを使用したりする場合は、crypt関数のドキュメントを読むことを強くお勧めします。15から18ではないにしても、最低12ラウンドのbcryptをお勧めします。
bcryptは、コストメカニズムが可変で、blowfishのキースケジュールのみを使用することを知ったとき、bcryptの使用に関する考え方を変更しました。後者では、blowfishのすでに高価なキースケジュールを増やすことにより、パスワードを総当たりにするコストを増やすことができます。
平均的な慣行
このような状況はもうほとんど想像できません。PHPASSはPHP 3.0.18から5.3をサポートしているため、考えられるほとんどすべてのインストールで使用できます。また、環境がbcryptをサポートしているかどうか不明な場合は、使用する必要があります。
ただし、bcryptやPHPASSをまったく使用できないとします。それで?
実装試しPDKBF2をしてラウンドの最大数は、ご使用の環境/アプリケーション/ユーザーの認識が許容できます。私がお勧めする最低数は2500ラウンドです。また、操作の再現を困難にすることが可能な場合は、hash_hmac()を使用してください。
今後の実践
PHP 5.5で登場するのは、bcryptでの作業の苦痛を取り除く完全なパスワード保護ライブラリです。私たちのほとんどは、ほとんどの一般的な環境、特に共有ホストでPHP 5.2と5.3を使い続けていますが、@ ircmaxellは、PHP 5.3.7と下位互換性のあるAPIの互換性レイヤーを構築しています。
暗号の要約と免責事項
ハッシュされたパスワードを実際に解読するために必要な計算能力は存在しません。コンピュータがパスワードを「解読」する唯一の方法は、パスワードを再作成して、パスワードを保護するために使用されるハッシュアルゴリズムをシミュレートすることです。ハッシュの速度は、ブルートフォースされる能力と線形的に関連しています。さらに悪いことに、ほとんどのハッシュアルゴリズムは簡単に並列化してさらに高速に実行できます。これが、bcryptやscryptなどのコストのかかるスキームが非常に重要である理由です。
あなたはおそらく攻撃のすべての脅威や道を予見することはできません、ので、あなたのユーザーを保護するためにあなたの最善の努力しなければなりませんフロントアップ。そうしないと、手遅れになるまで攻撃されたという事実を見逃す可能性があります ... そしてあなたは責任を負います。そのような状況を回避するには、まずは偏執的な行動をとります。自分のソフトウェアを(内部で)攻撃し、ユーザーの資格情報を盗んだり、他のユーザーのアカウントを変更したり、データにアクセスしたりしようとします。システムのセキュリティをテストしないと、自分以外の誰かを責めることはできません。
最後に、私は暗号学者ではありません。私が言ったことは私の意見ですが、私はたまたまそれが良識の常識に基づいていると思います...そしてたくさんの読書。できるだけ偏執狂的で、侵入をできるだけ難しくすることを忘れないでください。それでも心配な場合は、ハットハッカーまたは暗号技術者に連絡して、コード/システムについて彼らが何を言っているかを確認してください。