Правильный способ использовать соль вместе с хэширования

Question

В ходе обсуждения с несколькими другими людьми, я прочитал аргумент, что

• sha512 (соль + имя пользователя + пароль) плоха,
• SHA512 (имя пользователя + пароль), и
• sha512 (пароль) является простым идиотским.

Хотя я частично согласен с тем, что на самом деле является лучшей защитой? Есть ли что-нибудь более безопасное, чем использование уникальной соли пользователя вместе с медленным методом хэширования, таким как SHA512? Каков реальный путь? Спорить!

Пожалуйста, отредактируйте название, если вы считаете это плохим.

Answer 1

1. Создайте случайную соль для каждого пароля.
2. Избегайте MD5 и даже SHA-1.
3. Используйте медленный алгоритм хэширования; Кажется, сейчас SHA-256 является хорошим выбором.
4. Хранилище паролей является одним из тех редких случаев, когда есть какая-то польза от наличия собственного (общего) алгоритма. Рассмотрим атакующего с радужным столом; если ваш алгоритм хранения паролей отличается от того, который используется для генерации своей таблицы радуги, чтобы изменить сгенерированные значения, этот радужный стол бесполезен. Злоумышленник должен знать ваш алгоритм, а затем создать новую таблицу. Если вы выберете медленный алгоритм хеширования, создание новой таблицы очень дорого.

Под «общим» алгоритмом я имею в виду полное определение того, как вы преобразовываете пароль открытого текста в сохраненное значение. Например. SHA-256("mypassword" + "[[" + 40-char-random-alphanum-salt + "]]"). Если вы измените это на использование угловых скобок вместо квадратных скобок, вы изменили таблицу радуги, необходимую для использования ваших сохраненных паролей. Обратите внимание, что я не сторонник написания собственного алгоритма хеширования; вы все равно должны выбрать криптографически безопасный алгоритм хеширования.

См. this article автор MD5. Он делает два основных момента, которые я повторил выше: 1) если вы используете быстрый алгоритм хэширования, вам не хватает точки, и 2) повторное использование общих алгоритмов позволяет повторно использовать таблицы радуги.

Answer 2

Обсуждая недавнюю утечку LinkedIn, кто-то поднял этот номер link about bcrypt. Я думаю, я согласен ... мы должны использовать функции, которые увеличивают время вычисления экспоненциально в соответствии с коэффициентом. Это единственный способ, которым мы можем победить людей, пытающихся использовать кластеры или графические процессоры для выполнения своих расчетов хэширования.

Answer 3

Я понимаю, что повторное хеширование (для вычислительной стоимости) & хорошая случайная соль, должно победить всех, но серьезно определенных криптографических атакующих.

хэширование паролей в базе данных, и по сети, избегает открытого текста быть возмещена (и используемым в других местах) по Snooper или злоумышленнику, который делает получить в.

В основном это более или менее схема, используемой Wordpress аутентификация:

var SALT = 64 random characters; 
var NUM_HASHES = about 1000; // can be randomized 
var hashedResult = inputPassword; 
for (int i = 0; i < NUM_HASHES; i++) { 
    var dataToHash = SALT + hashedResult; 
    hashedResult = secureHash(dataToHash); 
} 
//... can now store or send. 

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