3

私は現在、ユーザー アカウントを必要とする Web プロジェクトに取り組んでいます。アプリケーションはサーバー側のCodeIgniterなので、認証ライブラリとしてIon Authを使用しています。

パスワードを保護するために2つのソルトを使用した認証システムを以前に作成しました。1 つはサーバー全体のソルトで、.htaccess ファイルに環境変数として設定されていました。もう 1 つは、ユーザーのサインアップ時にランダムに生成されたソルトでした。

これは、パスワードをハッシュするためにその認証システムで使用した方法です。

    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
    //create a random string to be used as the random salt for the password hash
    $size = strlen($chars);
    for($i = 0; $i < 22; $i++) {
        $str .= $chars[rand(0, $size - 1)];
    }

    //create the random salt to be used for the crypt
    $r_blowfish_salt = "$2a$12$" . $str . "$";

    //grab the website salt
    $salt = getenv('WEBSITE_SALT');

    //combine the website salt, and the password
    $password_to_hash = $pwd . $salt;

    //crypt the password string using blowfish
    $password = crypt($password_to_hash, $r_blowfish_salt);

これに穴があるかどうかはわかりませんが、とにかく、CI で使用するより完全な機能セットを求めて Ion Auth に移行しました。

Ion は、ハッシュ メカニズムの一部として 1 つのソルトしか使用していないことに気付きました (ただし、データベース セッションを保護するために、encryption_key を設定することをお勧めします)。

私のデータベースに保存される情報は、名前、電子メール アドレス、国ごとの場所、いくつかのメモ (機密情報が含まれていないことをお勧めします)、Facebook、Twitter、または Flickr アカウントへのリンクなどです。これに基づいて、自分のサイトの安全なページで SSL 接続を行う必要があるとは確信していません。

私の質問は、Ion Auth ライブラリの一部として 1 つのソルトしか使用されていない特定の理由があるのでしょうか? それが提供する機能の前に独自の追加のソルティングを書くことを暗示していますか、それとも何か不足していますか?

さらに、2 つのソルトを使用する価値さえありますか、それとも、攻撃者がランダムなソルトとハッシュ化されたパスワードを取得した場合、とにかくすべての賭けが無効になりますか? （そうではないと思いますが、何も心配していないかどうかを確認する価値があります...）

4

2 に答える 2

1

これは、Ion_Auth が bcrypt を使用しているためです。そのため、通常、それ以上のことを行う必要はありません。

さらに、「random_rounds」を設定できます。これは、設定で (ある程度) ランダムなソルティングのようなものです。

編集: bcrypt およびその他の種類の暗号化の詳細については、この SO スレッドを表示できます

于 2012-10-01T14:17:25.340 に答える
1

誰かが何らかの方法でコードを挿入する方法を見つけた、または誤ってディレクトリを開いたままにしていた、または誰かがインジェクション ハックを見つけてシステムのソルト ファイルまたはユーザー データを表示できるという議論は、使用する説得力のある理由にはなりません。デュアルソルト。これがあれば、実際には、ユーザーのソルト化および暗号化されたパスワードのリストよりも心配する必要があります!

以上のことから、デュアル ソルト ソリューションは確かにはるかに安全です。特に、コードにシステム ソルトが表示される可能性がある場合はなおさらです。請負業者や同僚が退職する状況を考えてみてください。使用されているソルトとソルティング パターン/アルゴリズムを知っている場合は、レインボー テーブルを作成し、それをサイトに対して使用できます。ユーザー レコードに 2 番目のランダム ソルトを追加すると、これを防ぐことができます。

それはすべて、あなたが確保したものの価値と、あなたが確保したものを手に入れるために誰かが経験する必要のある合理的な努力の量を比較検討することです. また、ソルトをまったく使用しない、または暗号化をまったく行わないという完全な過失がないことは、残念ながら、基本データが保存されている他の多くの安全性の低い場所よりも優れています. 信用情報、医療記録、社会保障情報がない場合。番号、および単なる一般的なユーザー情報 (電子メール、住所など) であり、このデータを持ち込む予定がない場合は、単一のソルトでおそらく十分です。現時点で 100% 確実にこの判断を下すことができない場合は、より安全なオプションを選択してください。

于 2012-10-01T14:16:48.980 に答える