Исходное положение: Пароли, хранящиеся в базах данных, представляют собой такую же опасность для вашего приложения, как и остальные.
Угроза: Взлом аккаунта, возможные последствия.
В феврале 2001 года RealNames, компания, заменившая сложные web-адреса простыми ключевыми словами, сообщила, что хакеры получили доступ к базе данных, заполучив информацию по кредитным карточкам и пароли всех их клиентов. Месяц спустя ADDR.com, компания по размещению на сервере web-узлов клиентов, сделала заявление о том, что хакеры похитили личную информацию и пароли 46,000 пользователей. Спустя ещё месяц после этого общественность узнала о еще нескольких подобных историях, когда сервер взламывался, а пароли похищались.
Риск подобного взлома можно существенно сократить, применяя один очень простой способ: не хранить пароли в базе данных.
Существует три способа хранения паролей, используемых в дальнейшем для аутентификации пользователей:
- Текстовый формат.
- Зашифрованный формат, хранение как гипертекст.
- Создание одностороннего символа пароля и хранение этого символа в базе данных.
Совершенно очевидно, что первое решение неэффективно, да и второе ненамного лучше: хотя пароль и зашифрован, кодировка основана на секретном слове. Если предполагается, что web-приложение выполняет шифрование и дешифрование, следовательно, оно должно каким-то образом хранить и ключевое слово. Если хакер контролирует приложение, которое может расшифровать пароль, то он получает доступ к паролю.
Внимание: Хэш называется односторонней функцией, потому что можно получить символ из пароля, но нельзя получить исходный пароль из хэш-символа. Тем не менее хэши не обладают абсолютной устойчивостью к взлому и должны быть тщательно защищены. Если хакер сможет получить символ, он сможет получить список слов, прогнать каждое из них через один и тот же хэшируемый алгоритм и сравнивать два символа до тех пор, пока не обнаружит совпадение. Этот метод взлома паролей стал также популярен, как John the Ripper.
Важная причина для того, чтобы не сохранять действительные пароли, - это то, что в этом случае никто из вашей организации не сможет получить доступ к именам пользователей. Это действительно важно, поскольку нередко люди используют одни и те же пароли для разных систем. Если кто-то из вашей организации обладает правом доступа к паролям вашего приложения, это может означать, что у них также есть доступ к пользовательским аккаунтам других web-систем.
Если пароли хранятся в базе данных, взломщик может получить доступ ко всем аккаунтам пользователя, даже если пароли зашифрованы. Это ставит под угрозу всех тех, кто пользуется одним и тем же паролем для разных систем. Некоторые хакеры составляют списки комбинаций логина и соответствующего ему пароля для использования при вмешательстве в другие системы.
Установите наиболее подходящий для вашей организации алгоритм аутентификации и проверки целостности информации. Поскольку хэши всё ещё очень уязвимы против подбора пароля методом лобовой атаки, лучшее решение - не самый быстродействующий алгоритм. Использование более медленного алгоритма означает, что и процесс подбора пароля будет проходить дольше. Система должна быть разработана так, чтобы вам никогда не приходилось восстанавливать пароль. 1 [ароли должны быть только установлены или переустановлены.
Однако иногда программа должна сохранять пароль для дальнейшего использования. Например, однажды я проверял приложение, которое должно было проводить аутентификацию провайдера данных третьей, независимой стороны. Поскольку этот провайдер требовал проведения опознавания, приложение вынуждено было сохранять пароль, используя обратимое шифрование. Так как приложение требовало восстанавливаемый пароль, компании приходилось принимать дополнительные меры по защите ключа шифрования, что они и делали, поместив код шифровки и расшифровки в компонент СОМ.
Недостатком использования обратимого шифрования является то, что ключ шифрования очень редко меняется. Замена ключа шифрования очень проблематична, поскольку в этом случае вам придется расшифровать и заново зашифровать весь гипертекст базы данных, используя новый ключ.
Если вы планируете использовать обратимое шифрование, в ваши планы должна входить и разработка механизма, который регулярно измененяет ключ кодирования и обновления всех зашифрованных данных.
Внимание: При обратимом шифровании всегда используйте надежный алгоритм, например DES, BlowFish. Никогда не используйте XOR (исключающее ИЛИ), ROT-13 или любительские коды шифрования; они не обеспечивают должного уровня защиты и подвержены взлому в гораздо большей степени, чем вы думаете. Грубо говоря, слабые алгоритмы шифрования можно сравнить с крошечным замком на большой сумке.
Используйте одностороннюю функцию и храните хэш в базе данных. После того как пользователь войдет в систему, запустите хэш-функцию на пароль, введенный пользователем, и сравните этот хэш с тем, который хранится в вашей базе данных. Преимуществом хэш-функции является то, что ключ состоит только из букв, что позволяет пользователю вводить любые символы клавиатуры в своем пароле, и вам не придется принимать дополнительных мер по управлению специальными символами.
Подсказка: Если ваша система хранит пароли в формате обычного текста, процесс перехода к хэшам пройдет относительно безболезненно. Для этого создайте новое поле хэша сразу же за уже существующим полем пароля. Затем захэшируйте все существующие пароли и сохраните их в новом поле. После этого добавьте хэш-функцию к вашему опознавательному коду и коду установки пароля. В заключение, вместо сохранения и проверки поля пароля, обновите ваш код на первый хэш пароля, затем сохраните и проверьте, используя поле хэш.
Способы защиты
- Никогда не храните пароль в формате обычного текста или используйте обратимое шифрование.
- Используйте надёжные алгоритмы - MD5, SHA-1 (алгоритм аутентификации и проверки целостности информации), SHA256 или SHA512.
Хотел бы порекомендовать онлайн менеджер паролей FortNotes.