Пароль, обрабатывающий лучшие практики?
Вместо Шаблона Несуществующего объекта - который имеет его использование - Вы могли бы рассмотреть ситуации, где несуществующий объект является ошибкой.
, Когда исключение будет выдано, исследуйте отслеживание стека и работу через ошибку.
4 ответа
Я бы порекомендовал поискать такие сайты, как OWASP . Они имеют дело с более широкой темой безопасности веб-приложений, которая, конечно же, является ключевой функцией. Я уверен, что вы найдете там больше информации.
Есть также такие компании, как Foundstone , которые могут обучить вашу команду разработчиков передовому опыту и провести аудит ваших существующих приложений.
Чем меньше ограничений вы можете наложить на то, какие символы разрешены в пароле, тем лучше - это увеличивает пространство поиска для тех, кто пытается подобрать пароль. В идеале нет причин запрещать любой символ ASCII (кроме управляющих символов и таких вещей, как возврат / новая строка) в пароле.
Что касается ограничений на длину, то минимальные ограничения хороши (до определенной степени - не злясь ваших пользователей, установив минимальную длину 10, например), максимальные ограничения плохие. Если кто-то хочет иметь пароль из 50 символов, позвольте им - хранение не должно быть проблемой, пока вы выполняете хеширование, поскольку хеши имеют постоянную длину.
Всегда храните пароли в не- обратимая форма хеширования - в идеале криптографически безопасная. Там' s нет причин хранить их в обратимой форме (если кто-то забудет свой пароль, просто установите для них новый пароль, не пытайтесь его «восстановить»). Не пишите свои собственные алгоритмы хеширования - скорее всего, вы не специалист по криптографии, и существует множество хороших проверенных алгоритмов хеширования с реализациями (в виде кода или библиотеки) примерно для любой основной язык.
Добавьте в свои хэши достаточную длину для каждого пользователя, чтобы предотвратить взлом радужную таблицу .
В главах 5 и 6 Pro PHP Security речь идет о хранении и шифровании паролей:
Некоторые статьи по теме:
Установка пределов короткой длины и фильтрация символов - две часто встречающиеся ошибки, которые сводят меня с ума. Правильное хеширование паролей должно полностью исключить необходимость в этом, и это может стать настоящей проблемой для конечных пользователей.
Я генерирую свои личные пароли с помощью MD5 (ключ + ключевое слово) - например, мой банковский пароль - MD5 («NotTelling» + "Банка"). Кажется, что многие сайты мешают пользователям использовать надежные пароли, и для этого никогда нет веских причин.
Очевидно, хороший соленый хеш - это путь.
Какой алгоритм мне следует использовать для хеширования паролей в мою базу данных? В есть хорошая статья о лучших алгоритмах, которые следует использовать.
Если вы разрабатываете систему, которая обрабатывает пароли, и можете использовать ее для получения пароля пользователя, тогда система не будет безопасной.
Это часть более общего необходимого условия для безопасность: Разработчик не должен нарушать работу системы.