Хранение манипулируемых хэшей вместо правильных - PullRequest
3 голосов
/ 08 августа 2011

У меня была идея о хранении паролей в базах данных: поскольку пароли можно взломать, просто просмотрев хэш в радужных таблицах (и т. Д. И т. П.), Было бы намного (или даже немного) безопаснее хранить манипулируемый хешвместо настоящего?В моем случае, это не строка, хэшированная дважды или что-то в этом роде - у меня есть собственный шаблон «скремблирования» хэша (я бы предпочел не упоминать мой подход к этому), поэтому я решил спросить, стоит ли эта проблемапрежде чем я сделаю что-то бесполезное.

Пароли в базе данных в настоящее время зашифрованы с помощью Blowfish (соли абсолютно случайны) и SHA-1, достаточно ли это безопасно в других случаях (да, вы никогда не сможете быть слишком безопасными - но следуетэтого достаточно)?У нас на самом деле тоже мало пользователей, так как сайт не привлекает большого внимания.

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

1 Ответ

2 голосов
/ 08 августа 2011

Я бы предпочел не упоминать мой подход к этому

Безопасность через неизвестность - это не безопасность.

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

Взгляните, например, на: http://freerainbowtables.com, которые являются распределенными радужными таблицами, и посмотрите, где они находятся.

Однако вместо шифрования пароля самостоятельно (или с помощью некоторой самодельной функции) можно использовать больше итераций при шифровании.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...