Какие меры безопасности следует предпринять при создании функции "изменить свой пароль"?

Я добавляю функциональность "изменить пароль" на свою веб-страницу http://ninjawars.net, которая в настоящее время исправлена ​​(и практически никогда не меняется) пароли.

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

Принимая то, что я могу извлечь из способа делать вещи в Facebook, несколько моментов, которые следует помнить, следующие:

  • Требовать старый пароль (конечно).
  • Дважды подтвердите ввод нового пароля.
  • выйти из учетной записи (только на всех других страницах, так или иначе)?
  • Требовать защищенную длину пароля и что пароль подходит для всех [вставлять различные критерии здесь], необходимых для паролей в каждой конкретной системе.
  • Требовать, чтобы новый пароль отличался от старого пароля.
  • Предотвращение попыток смены нескольких паролей.

Facebook также:
 - Требуется, чтобы новый пароль отличался от прошлых паролей. (похоже, используется для использования кромки)

Это только те политики, которые я могу почерпнуть из внешнего интерфейса пользовательской системы facebook. Какие другие точки безопасности следует использовать при предоставлении системы "смены пароля"?

Edit: В моем конкретном случае я намерен быть относительно разрешительным с [вставлять различные критерии], какие персонажи должны будут входить в сам пароль. Мой сайт не является банком, если игрок хочет использовать пароль "password1", тогда они должны ожидать, что их учетная запись будет передана их друзьями. МОЙ ФОКУС, с другой стороны, делается вывод о том, что мой сайт предотвращает любые возможности для "враждебного поглощения" через любую незащищенность в самой системе смены пароля.

Более хорошие вопросы из ответов ниже:

  • Отправлять уведомление об изменениях пароля в адрес электронной почты пользователя.
  • Сохраняйте изменения электронной почты и смены пароля, каждый из которых зависит друг от друга.
  • Для таких изменений используйте безопасное зашифрованное (https) соединение.

ОТВЕТЫ

Ответ 1

Сохраняйте изменение пароля и любых изменений на адрес электронной почты отдельно. Таким образом, любой, кто хочет изменить, должен знать оба.

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

Ответ 2

Это, вероятно, очевидно, но не забудьте выполнить весь процесс изменения пароля по зашифрованному соединению (HTTPS).

Ответ 3

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

Ответ 4

Я заметил, что никто этого не предложил, или я пропустил некоторые из тонкостей в другом ответе.

Разрешить изменение пароля можно только в том случае, если пользователь знает "секретную строку" , которая будет отправлена ​​на адрес электронной почты при запросе изменения пароля. Для удобства вы можете сделать эту "секретную строку" в качестве URL-адреса, чтобы они могли просто быстро щелкнуть по электронной почте. Это гарантирует, что человек, запрашивающий смену пароля, также может войти в зарегистрированный адрес электронной почты (люди, как правило, более расслаблены с учетной записью игры, чем их частный адрес электронной почты).

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

Ответ 5

Интересный поворот, который я бы хотел, - если я введу очень длинный пароль, не заставляйте меня включать некоторые конкретные типы символов. Многие системы требуют действительно сложных комбинаций букв, кепок, чисел и специальных символов, которые я неизбежно заканчиваю тем, что создаю "одобренный" пароль на 6 символов, когда все, что я хотел, было 35 символов только в маленьких шапках, но это было отклонено за то, что он "небезопасен". Hah ^^

Кроме того, если вы используете какую-либо библиотеку классов, фреймворк или шаблон, который имеет встроенную функциональность кода, используйте его вместо того, чтобы сворачивать свои собственные. На самом деле, даже если нет - посмотрите на проверенные дополнения или внешние решения (OpenId?) - безопасность жесткая и одно из худших мест для повторного использования колес в imo.

Ответ 6

Я думаю, вы также должны проверить, не совпадает ли пароль с именем входа. Некоторые пользователи делают это, поверьте мне.

Ответ 7

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

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

Ответ 8

Я просто думал об этой проблеме сегодня.

Вместо обычных требований к сложности, я думаю, было бы интересно загрузить одну из свободно доступных таблиц радуги MD5 и перебросить эти пароли в базу данных NoSQL. Затем, когда пользователь установит свой пароль, попробуйте найти пароль, который они выбирают. Если вы его найдете, отклоните этот пароль.

В масштабе это можно сделать только с одним или двумя выделенными ящиками, на которых размещена служба поиска, поскольку установка/изменение пароля является такой редкой деятельностью.