6

ここで提供されるガイドラインに従って、 「 remember me 」機能を実装しようとしています：フォームベースのWebサイト認証の決定的なガイド、およびここ： http: //fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/

「Cookieトークン」はDBに保存するときにハッシュ化する必要があるようです（攻撃者がDBにアクセスできる場合、ハッシュ化されていないトークンはプレーンなログイン/パスワードのように見え、Webサイトにログインできます）。

良いハッシュアルゴリズムを探して、bcryptを使用してこの推奨されるテクニックを見つけました：https ：//stackoverflow.com/a/6337021/488666

私はそれを試してみましたが、提案されたラウンド数（15）では、処理時間が非常に遅くなることがわかりました（Intel Core 2 Duo E8500 + 4 GB RAMで2,3秒をハッシュ+検証2,3秒）

ハッシュアルゴリズムは攻撃者を妨げるために比較的遅いはずですが、そのレベルでは、ユーザーがWebサイトを使用するのを妨げます:)

より少ないラウンド（たとえば、処理時間を10ms + 10msに短縮する7）で十分だと思いますか？

4

1 に答える 1

14

フォームベースのWebサイト認証の最も信頼のおけるガイドを引用します。

永続的なログインCookie（トークン）をデータベースに保存しないでください。ハッシュのみを保存してください。ログイントークンはパスワードと同等であるため、攻撃者がデータベースを入手した場合、攻撃者は、クリアテキストのログインとパスワードの組み合わせであるかのように、トークンを使用して任意のアカウントにログインできます。したがって、永続的なログイントークンを保存するときは、強力なソルトハッシュ（bcrypt / phpass）を使用してください。

私は最初の太字の文に同意しますが、最後の文には同意しません。

私が間違っていなければ、「強力なソルトハッシュ」アルゴリズムの目的は、レインボーテーブルが与えられた場合に誰かがパスワードを取得できないようにすることです。

ただし、ここでは、ハッシュされた文字列はパスワードではなく、ランダムな文字列です。したがって、レインボーテーブルが元々ハッシュされた文字列を取得できる可能性はほとんどありません。これには基本的な呼び出しを使用できると思いますhash('sha256', $randomString)。目標は、DBとCookieのトークンに異なる値を設定することです。

于 2011-12-14T16:42:58.943 に答える