Обеспокоенность по поводу bcrypt и других алгоритмов на основе хеша - PullRequest
Новая
       15

Обеспокоенность по поводу bcrypt и других алгоритмов на основе хеша

0 голосов
/ 02 мая 2018

Я должен хранить пароль в зашифрованном виде в моей базе данных на основе текстовых файлов, чтобы обеспечить безопасность системы.

Я ищу возможные решения. Я исследовал алгоритмы, основанные на хэше, такие как MD5 и bcrypt. Обнаружено, что bcrypt рекомендуется более MD5. У меня есть озабоченность по поводу подхода в этих алгоритмах:

Я все еще вижу, что присутствие соли с хешем вызывает беспокойство. Более того, алгоритмы делают положение соли в хешированной строке общедоступным. Таким образом, в соответствии с этим форматом мы имеем:

$ bcryptid $ log_rounds $ 128-разрядным Salt184-разрядным Hash

Что делать, если хакер хочет взломать один из аккаунтов. Он / она может прочитать SALT для этой учетной записи, запустить для нее функцию шифрования bcrypt с попытками ввода пароля и сравнить со строкой HASHED в базе данных.

пожалуйста, используйте следующий псевдокод: 

for password_attempt in LIST_OF_POSSIBLE_PASSWORDS
 if (hashpw(password_attempt, SALT ) == HASHED)
  print "Hacker wins! I guessed a password!", password_attempt

Я вижу, что bcrypt просто сделает медленное hashpw, но я не вижу использования соли, когда ее наверняка называют открытым текстом в хешированной строке в базе данных. API должен искажать СОЛЬ в HASHED, чтобы его не читал хакер. Я думаю, что это не так, или я что-то здесь упускаю?

1 Ответ

0 голосов
/ 02 мая 2018

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

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

...