Я слышал обо всех этих сайтах, которые были взломаны с помощью инъекций и т. Д. Что мешает им шифровать хэши с 32-символьной строкой? Если бы я был хакером, и мне удалось получить базу данных, и я столкнулся с зашифрованными хэшами, я бы не смог ничего сделать с базой данных, поскольку я не знаю алгоритма шифрования и ключа.Почему веб-разработчики не делают этого с базами данных?
До тех пор, пока ключ, хранящийся на секретной основе, будет безопасным.
Ваша идея шифрования хэшей действительно улучшит безопасность пароля пользователей, но вы должны понимать, что именно вы решаете с помощью этой меры, а что нет.
Прежде всего, шифрование паролей, как правило, неодобрительно, поскольку это слабая защита. Если у злоумышленника есть ключ, он может мгновенно обнаружить все пароли. Таким образом, шифрование не освобождает вас от правильных хеш-паролей с медленным алгоритмом, таким как BCrypt, SCrypt, PBKDF2 или Argon2.
Но ваш вопрос был о шифрования хэшей. Существует случай, когда даже правильно хэшированные и соленые пароли можно легко восстановить. Если пользователь выбрал очень слабый пароль, атака словаря покажет их очень быстро. Однако, если хэши шифруются, злоумышленнику нужен ключ, прежде чем он начнет со словаря. Это приводит нас к следующей ситуации:
Шифрование хэшей защитит слабые пароли, если ключ остается в секрете. Это всегда происходит, когда злоумышленник не имеет привилегий на сервере, примеры SQL-инъекций, игнорируются серверы, резервные копии, ... Я попытался описать это в конце моего учебного пособия около safely storing passwords.
Если вы можете безопасно хранить ключ, просто надежно храните данные. – Blorgbeard
Было бы полезно не читать, как выполняется безопасное хеширование паролей. С помощью (обратимого) шифрования вся система защищена как ключ; соответствующее использование соответствующего хэша паролей делает его «неосуществимым» для (сильных) паролей, которые будут восстановлены в разумные сроки, независимо от секретного ключа. Это, как говорится, ничего не мешает дополнительным слоям защиты. И: если злоумышленник нашел некоторый доступ на запись - вы уже проиграли. – user2864740
См. [Как безопасно использовать хэш-пароли, Теория] (http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846) о безопасности Stackexchange. См. OWASP (Проект обеспечения безопасности веб-приложений) [Шифрование для хранения паролей] (https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Leverage_an_adaptive_one-way_function). См. [Современный, безопасный, соленый пароль, сделанный простым способом) (https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#legacy-hashes) – zaph