5

Railsに移植している数千人のユーザーを持つ既存のWebアプリケーションがあります。このアプリを書き直してリファクタリングするとき、開発、テスト、および運用の目的で、任意の数の異なるサーバーで実行する必要がある場合があります。

ユーザー モデルで Rails の組み込み has_secure_password メソッドを使用していますが、パスワード データの移植性が心配です。データベースのコンテンツをマシンからマシンに移動して、さまざまな環境でテストする必要があります。各環境で同じユーザーとパスワードのセットを使用してユーザー認証機能をテストできることが非常に重要です。

これまでのところ、bcrypt-ruby が Rails とどのように連携するかについての答えを見つけるのは簡単has_secure_passwordですが、何週間も検索しても明確な答えは見つかりませんでした。

WorkFactor has_secure_password+ Salt + HashedPassword が連結されてpassword_digestデータベース列に保存される場合、他のマシンに移動した場合 (他のマシンが Unix ライクな OS で Rails を実行していると仮定して)、そのハッシュを再生成して確実に比較できますか?

または別の言い方をすれば、bcrypt-ruby パスワードは Rails のhas_secure_passwordポータブルで生成されますか?

フォローアップの質問: ソルトが常にランダムに生成される場合 (同じパスワードが異なるハッシュを使用するのを見たことがあるので、パスワード自体のテキストからソルトが作成されたとは思わない)、Rails アプリはどのようにして確実にログインフォームの送信時にパスワードを再ハッシュし、データベースにあるものと比較します。明らかに、それを比較するには、最初に塩が何であるかを知る必要があります。それはどのように行うのですか？

4

1 に答える 1

5

はい、パスワードは移植可能です。使用される形式は、RFC 2307 の一部としても使用される標準の「crypt エンコーディング」形式です (RFC 2307 では、文字列の前に「{CRYPT}」が付きます)。Authen::Passphrase私は、RoR データベースから bcrypt でハッシュされたバージョンに対してパスワードを喜んで認証するPerl ライブラリを使用しました。

フォローアップの質問:ソルトは保存された値に埋め込まれており (ハッシュの種類、使用する bcrypt サイクルの数、そしてもちろんハッシュ自体も)、サーバーを認証するには、保存された値を読み取る必要があります。次に、同じソルトを再利用してハッシュ部分を生成するだけです。入力パスワードが正しい場合、ハッシュは同一になります。認証プロセスでは、新しいランダム ソルトは作成されません。ランダム ソルトは、保存用の新しいハッシュを生成するときにのみ作成されます。

bcrypt パスワードは、サーバーが読み取れるコンポーネントに簡単に分割されます (境界が見やすくなるように非現実的な文字を選択しました。実際、salt と hash は base 64 でエンコードされたバイナリ データです)。

 $2a$10$AaBbCcDdEeFfGgHhIiJjKk0987654321098765432109876543210

  • この部分は、「bcrypt を使用し、2**10 == 1024 回反復する」ことを意味します。$2a$10$

  • この部分はソルトです: AaBbCcDdEeFfGgHhIiJjKk、常に 22 文字

  • この部分はハッシュです: 0987654321098765432109876543210、常に 31 文字

于 2013-09-29T15:39:06.710 に答える