Безопасность паролей

Question

В настоящее время я использую определенную схему для защиты паролей, и я думаю, что у меня есть некоторые моменты для улучшения. Реализация выполняется на Java, поэтому я предпочитаю использовать SHA-2 512 в качестве формы шифрования.

В настоящее время у меня есть модели клиент-сервер, так что эти вещи могут случиться:

• клиент хочет войти, он посылает свой пароль с один раз нормальный SHA-2 512 шифрования по сети.
• Сервер имеет пароли, хранящиеся в базе данных, например, SHA-2_512 (SHA-2_512 (пароль) + соль), причем внутренний SHA-2_512 (пароль) является «зашифрованным» паролем, который он получает по сети.
• Проверка пароля выполняется на стороне сервера, и нет никакого способа просачиваться с сервера, единственной возможной уязвимостью было бы, если бы кто-то мог прочитать RAM, я думаю.

У меня есть следующие вопросы:

• Злоумышленник обычно создает атаки коллизий при желании взломать пароль. Однако насколько достаточны атаки на столкновение? Если пароль нужно использовать для других приложений, таких как Outlook.com, Facebook или что-то еще (что, вероятно, использует другую соль, так как они не имеют ничего общего с моими приложениями), как это такое? Вам не нужен настоящий пароль?

• Имеет ли SHA-2 512 уже итерацию? И даже если это так, следует ли мне изменить методы шифрования для автоматического использования нескольких итераций, а также сколько итераций предпочтительнее? Я также читал об использовании случайного числа итераций (в диапазоне), как я могу хранить случайный фактор детерминированно?

• Должен ли я хранить системные секреты для каждой итерации кода сервера? См. http://blog.mozilla.org/webappsec/2011/05/10/sha-512-w-per-user-salts-is-not-enough/. Я мог бы хранить массив, который будет хранить статический секрет для каждой итерации, причем n-й секрет для n-й итерации. Никто не может знать секреты, они вычисляются один раз (я думаю, как шифрование некоторой случайной строки), а затем в основном хранятся в ОЗУ сервера.

• В настоящее время я отправляю введенный пароль от клиента на сервер как только SHA-2_512 (пароль), если этот процесс будет улучшен, и если да, то как? Я не могу использовать соли, потому что у клиента нет соли.

С уважением.

Answer 1

TLDR: вам необходимо отправить пароль с использованием зашифрованного канала, такого как TLS. Рассмотрите возможность использования bcrypt для хеширования паролей.

SHA-2 512 не является алгоритмом шифрования, это алгоритм дайджеста сообщений. Для шифрования требуется шифрование ключа и сообщения. Он создает зашифрованный текст. Важно то, что алгоритм шифрования имеет алгоритм дешифрования.

ciphertext = E(key, plaintext); 
plaintext = D(key, ciphertext); 

Сборник сообщений принимает фрагмент открытого текста и создает дайджест сообщения. Не существует соответствующего механизма обратного преобразования для получения дайджеста сообщения и получения исходного сообщения. Также нет секретного ключа.

digest = hash(plaintext); 

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

digest1 = hash(guess1); 
digest2 = hash(guess2); //repeat with lots of guesses 

Во-первых, посылая хэш по сети не безопасным. Он должен быть отправлен через какой-либо защищенный механизм связи, такой как SSL. Если злоумышленник может перехватить хэш по сообщениям, они смогут обработать пароль orignal.

A hash collision - это не то же самое, что грубо заставлять пароль. Столкновение хэшей возникает, когда два сообщения разных сообщений создают один и тот же дайджест сообщений.

digest1 = hash(plaintext1); 
digest2 = hash(plaintext2); 
if ((plaintext1 != plaintext2) && (digest1 == digest2)) 
    // hash collision 

SHA-512 не имеет итераций, предназначенных для предотвращения грубой силы. Набор алгоритмов SHA призван быть эффективным. Причина добавления итераций при хешировании паролей заключается в увеличении времени, необходимого для перебора пароля. Идея, заключающаяся в стоимости выполнения законной попытки входа в систему и выполнения 100 итераций, крошечная по сравнению с атакующей, у которой есть миллионы паролей, каждая из которых требует 100 итераций. Добавление большего количества итераций помогает снизить влияние улучшенных скоростей процессора (что поможет злоумышленнику быстрее выполнить больше итераций).

Вы должны сделать число итераций настраиваемым пределом, который сохраняется для каждого пользователя. Таким образом, вы сохраняете хеш пароля, количество солей и итераций для каждого пользователя. Это означает, что в будущем вы можете увеличить количество итераций, чтобы учесть повышенную аппаратную мощность.

Отправка SHA-2 512 в незашифрованном виде небезопасна. Вы должны отправить его в зашифрованном канале, таком как SSL.

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