32

社内で機密情報を扱う従業員専用の Rails アプリケーションのセットアップを開始しようとしています。ファイアウォール、物理的なセキュリティ対策などがあります。現在の私の懸念は、アプリケーションのログイン プロセスです。

認証にDeviseを使いたいです。Deviseの最も安全な構成は何ですか?

私は次のことをしようと考えています：

  • 少数のログイン試行の失敗後にアカウントをロックする
  • config.paranoid有効な電子メール アドレスを推測したかどうかを攻撃者が判断できないようにするために使用します
  • メールによるパスワードのリセットを無効にすることはできますか?

私が確信していない特定の事柄のいくつかdevise.rb。

  • コショウ。Devise には、 「暗号化されたパスワードを生成するためにペッパーをセットアップする」オプションがあります。私の理解では、これは "password123" のようなばかげたパスワードを "password123K#(!@akdlwekdf" または "*%!kd39gpassword123" などのハッシュ化する前の何かに変換する単一のアプリ固有の値であるということです。これは阻止するためのものです。しかし、この記事から理解したところでは、パスワードごとに一意のソルトほど良くないということです. また、この記事とこの論文では、bcrypt にはソルトが組み込まれていると述べています. bcrypt でペッパーを使用すると、本当に何かが追加されますか?ソルト カラムも使用できますか、またその必要はありますか?
  • 伸びます。「bcrypt の場合、これはパスワードをハッシュするためのコストであり、デフォルトは 10 です。」この質問に 基づいて、作業係数 12 を使用することを考えています。それは合理的ですか?
  • パスワードの長さ。一般的には、長いパスワードの方が安全に思えますが、ユーザーがどこかに紙に書き留めるほどパスワードを難しくしたくはありません。bcrypt を使用している場合、パスワードの長さは重要ですか?
  • SSL クッキー。SSL が有効になっているパブリック アプリの場合、Cookie を「これは HTTPS 経由でのみ送信できます」とマークすると、Firesheepスタイルの攻撃から保護されます。しかし、内部アプリ用のセキュリティ証明書を持っていることがどれほど理にかなっているのか、私にはわかりません。それはばかげていますか？

他に何が欠けていますか？

4

2 に答える 2

21

Peppers : はい、その通りです。塩を使用している場合、コショウで達成される追加のセキュリティはあまりありません.

Stretches : 12 は妥当ですが、bcrypt は一定の時間を保証するだけです。一定の時間と使用するメモリ量の両方を指定できるため、新しい scrypt の使用を検討する必要があります。暗号学的には、bcrypt と scrypt はほぼ同じですが、scrypt はブルート フォーシングをより困難にします。

パスワードの長さ: あらゆる種類のパスワード規則を強制すると、パスワードのエントロピーが減少します。唯一の制限は最小の長さであるべきであり、多くの調査では少なくとも 8 文字が推奨されています。

SSL Cookies : 可能であれば使用してください。セキュリティは常に最初から構築する必要があり、後で追加することはありません。誰があなたの内部ネットワークをスニッフィングしているかもわからない. 部外者がデータを盗聴できないと想定しているからといって、内部の従業員がなんらかの理由で盗聴できないわけではありません。あなたには、従業員同士や外部の脅威から従業員を保護する責任があります。

于 2012-07-24T03:03:56.650 に答える
4

パスワードについては、https://github.com/bitzesty/devise_zxcvbnをチェックアウトできます。これは、エントロピーが弱いパスワードを拒否し、既知のクラックされたパスワードと照合します。

于 2014-01-20T14:46:21.787 に答える