Лучшие практики по обработке паролей?

Question

У нас есть несколько сетевых сервисов и веб-приложений, которые по-разному аутентифицируют пользователей, некоторые с разными требованиями к паролям по очень плохим техническим причинам. Например, одна система отклоняла знаки $, пока кто-то не «исправил» обработку строк в некоторых скриптах Perl. Похоже, другая система анализирует пароли @. Другая система выдает им пароли пользователей, и разработчик с гордостью показал мне, что это было обратимое преобразование имени пользователя.

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

Answer 1

Чем меньше ограничений вы можете установить для того, какие символы разрешены в пароле, тем лучше - это увеличивает пространство поиска для кого-то, пытающегося перебором. В идеале, нет никаких причин запрещать какой-либо символ ASCII (кроме управляющих символов и таких вещей, как backspace / newline) в пароле.

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

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

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

Главы 5 и 6 в Pro PHP Security посвящены хранению и шифрованию паролей:

• http://books.google.com/books?id=lVXnmsCCd3wC&lpg=PP1&pg=PA55#v=onepage&q=&f=false

Некоторые соответствующие статьи:

• http://www.codinghorror.com/blog/archives/000953.html
• http://securityratty.com/article/41ae895330526916b45e20f6b71dd8cc
• http://www.ibm.com/developerworks/opensource/library/os-php-encrypt/?S_TACT=105AGX01&S_CMP=LP

Answer 2

Я бы порекомендовал посмотреть на такие сайты, как OWASP . Они касаются более широкой темы безопасности веб-приложений, которая, конечно же, является ключевой функцией защиты паролем. Я уверен, что вы найдете больше информации там.

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

Answer 3

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

Я генерирую свои личные пароли с помощью MD5 (ключ + ключевое слово) - например, мой банковский пароль - MD5 («NotTelling» + «Bank»). Похоже, что многие сайты мешают пользователям с надежными паролями, и для этого нет веских причин.

Очевидно, что хороший соленый хеш - это путь.

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

Answer 4

Если вы разрабатываете систему, которая обрабатывает пароли, и вы можете использовать ее для получения пароля пользователя, то система не защищена.

Это часть более общего необходимого условия безопасности: Разработчик не должен быть в состоянии сломать систему.