私は「ゼロからの認証」（Railscastで実装されている）とDeviseの使用の長所と短所を比較しています。RailScastsからの「スクラッチからの認証」はどれくらい安全ですか？
私はカスタムデータストアを使用していますので、Deviseを使用するのはREADMEのように単純ではありません。 custom ORM adapto rと書くのは些細なものではありません。
これを考えると、Railscast Authは最初から実装する方がはるかに簡単です。
どのように安全ですか？
更新：私はデータストアとしてParse.comを使用していると指摘しておきました。つまり、パスワードをハッシュし、ユーザー名の一意性を制約します。
両方ともbcryptを使用してパスワードのハッシュ化されたハッシュを生成することで動作しますが、唯一の違いはdevise（デフォルトでは）がハッシュに対してより高いコストを使用することです。もちろん、それをrailscastコードに簡単に追加することができます。その点ではほぼ同等です。
railscastバージョンは、タイミング攻撃に対して脆弱であるように見えます。==を実行するだけで、一定の時間比較操作は実行されません。要するに、ハッシュが完全に間違っているパスワードは、バイトの最初の半分が正しいパスワードよりも拒否する時間が少なくて済みます（したがって、==は救済する前にもっと多くのバイトを考慮する必要があります）。このような違いは、ネットワーク遅延の変動などのノイズによって消されるように見えるかもしれませんが、人々はこれらのアプローチを使用してキーを回復するための実際の攻撃を実装しています。
明らかにセキュアな比較ビットを借りることはできますが、明白ではない問題があることがわかります。
明らかに、あなたは認証だけでなく、さらに多くのことができます！
ここで説明したタイミング攻撃についてのクイックq ...私が理解しているように、タイミング攻撃では比較入力を繰り返す必要があります。最初のn個の文字を正しく取得するには、次の推測を行うためにn + 1番目の文字を変更します。 多分私は何かが欠落していますが、どうしたらうまくいくのでしょうか？パスワードがハッシュされている場合（* any * hashing algoを使用）、単純にn + 1番目の文字を変更して攻撃を反復することはできません。そうすることで全く新しいハッシュが得られます。攻撃者が制御する入力を比較していないので、タイミング攻撃がどのように機能するかはわかりません。 – Ali
おそらく、正直ではないでしょうか。 –
しかし、あなたは正しいかもしれません - 私のところでは過度の反応かもしれません –
このスクリーンキャストでは、Blowfish cipherに基づいて、bcryptのRubyの実装であるbcrypt-rubyライブラリを使用しています。 bcryptの利点は、このシステムによって生成されたパスワードを計算するのに計算コストがかかり、これらのパスワードを生成するコストを必要に応じて増やして、より安全にすることができます。時間を生成する。
詳細については、BCrypt::Password RDocを参照してください。
Rails 3.1を使用していますか？もしそうなら、それはもっと簡単です：http://railscasts.com/episodes/270-authentication-in-rails-3-1。私はそれがいかに安全であるかについてあなたの質問に答えるのは難しいと感じています。あなたはどんな答えを期待していますか？ – Mischa
私はどのような答えを期待するのかよく分かりません。これは、「未知の未知数」の質問の1つです。 – user94154