Откуда берутся значения хеш-соли?

При добавлении солт-значений к хеш-значению для чего-то вроде пароля, который не может быть сохранен в виде простого текста, из чего лучше всего получать солт-значения? Для контекста, давайте предположим, что это для паролей на странице входа в систему.

У меня обычно есть столбец created TIMESTAMPв пользовательской таблице, чтобы я мог видеть, когда пользователь зарегистрировался. Мне не нравится добавлять дополнительный столбец для Salt, поэтому я использую столбец timestamp в качестве соли:

SHA1(password + created)

Это имеет значение?

Соль служит двум целям. Это делает нецелесообразным использование больших таблиц предварительно хешированных паролей («радужных таблиц»), а также делает идентичные пароли выглядеть по-разному в списке хэшей. Если идентичные пароли выглядят по-разному, это помогает избежать проблемы, когда несколько человек используют один конкретный пароль, который, вероятно, является распространенным слабым паролем.

Следовательно, каждая учетная запись должна иметь свою собственную уникальную соль, и соли не должны быть слишком предсказуемыми, в том смысле, что не будет группы солей, которые могут возникнуть. (Если бы многие сайты начинали с 1 и считали, плохие парни могли бы строить радужные таблицы, например, с низким содержанием солей.) Они не должны быть случайными в каком-либо смысле, кроме как обычно непредсказуемыми. Они не более секретны, чем сам хеш, поэтому они не должны быть конкретно неосмысленными.

Используйте любой удобный метод для получения соли. Если существует много потенциальных значений соли (ранние системы Unix часто использовали два байта для возможного числа 65536) по сравнению с количеством учетных записей, полуслучайное назначение почти никогда не выдаст дублирующую соль.

Каждый раз, когда вы хотите сохранить новый пароль (регистрация, сброс пароля, обновление пароля), один хороший метод:

• генерировать новую соль
  • использовать криптографически безопасный генератор псевдослучайных чисел
  • использовать соль приличного размера - хорошее значение - размер блока базового алгоритма хеширования (может быть SHA-256)
• создать новый пароль токен
  • создать функцию hmac из основного алгоритма хеширования (может быть, SHA-256), используя соль в качестве ключа hmac
  • for i in (0...65536) { password = hmac(password) }
  • Результатом повторного применения функции hmac является токен пароля
• хранить соль и токен пароля
  • не храните оригинальный пароль
  • При желании хранить основной алгоритм хеширования и растяжки для обнаружения

Используйте рамки. В .NET вы можете использовать RNGCryptoServoiceProvider ...

        // If salt is not specified, generate it on the fly.
        if (saltBytes == null)
        {
            // Define min and max salt sizes.
            int minSaltSize = 4;
            int maxSaltSize = 8;

            // Generate a random number for the size of the salt.
            Random  random = new Random();
            int saltSize = random.Next(minSaltSize, maxSaltSize);

            // Allocate a byte array, which will hold the salt.
            saltBytes = new byte[saltSize];

            // Initialize a random number generator.
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

            // Fill the salt with cryptographically strong byte values.
            rng.GetNonZeroBytes(saltBytes); 
        }

Другие структуры должны иметь аналогичные классы, которые вы можете использовать. Для достижения случайности программное обеспечение часто использует пользователя по сравнению Randomс указанным выше. Случайное перемещение мыши в определенной области для получения соли - опция, используемая TrueCrypt. Это сводится к вашим конкретным потребностям и уровню безопасности; так как ваша соль может быть просто !@#$%.

Вы создаете соленый сервер и назначаете его учетной записи пользователя при его создании. Лучше использовать некоторый API-интерфейс для криптографии, доступный в вашей среде, но в принципе подойдет любая последовательность.

Обычно вещи хранятся так:

User
-------------------
ID
Username
PasswordHashWithSalt

Пример:

PasswordHashWithSalt =

A15CD9652D4F4A3FB61A2A422AEAFDF0DEA4E703 j5d58k4b56s8744q

Используйте bcrypt и прочитайте эту статью, поскольку обычные хэши не являются серьезной защитой в наше время.

Рассмотрите возможность использования протокола паролей с нулевым знанием SDR, который имеет множество библиотек с открытым исходным кодом и не имеет патентов.

SDR требует соли и лучшее место, чтобы получить это клиент; время их нажатий клавиш, движений мыши, хэширования переменных среды, случайных чисел, времени создания файлов в их временной папке, чтобы получить соль в их конце непредсказуемым образом от вашего сервера. SDR берет соль, большое простое число, пароль пользователя и генерирует ключ верификатора. Вы не храните пароль, он никогда не покидает их машину, но вы можете проверить, что у них есть пароль, который идет с ключом верификатора и солью. Он невосприимчив к атакам человека посредине и словарю. Для уверенности зашифруйте ключи и соль в столбце базы данных.