Какие символы вы бы сделали недействительными для пароля? - PullRequest
5 голосов
/ 06 октября 2009

Гипотетическая ситуация: вы внедрили систему обработки паролей, и она не накладывает никаких ограничений на то, какие символы можно использовать. Вы хотите установить некоторые правила, которые являются разумным компромиссом между двумя вещами -

  1. Предоставьте пользователю как можно больше свободы.
  2. Предоставьте возможность, что вы можете изменить способ обработки паролей в будущем - вы не хотите исключать разумные реализации, поскольку существующие пароли ваших пользователей станут недействительными.

Какие правила вы бы навязали? Есть ли другие факторы, которые могут повлиять на ваш выбор?

Ответы [ 12 ]

13 голосов
/ 06 октября 2009

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

Однако вы можете потребовать от своих пользователей иметь достаточно надежный пароль, наложив ограничение на длину (скажем, не менее 6 символов) и на символы, которые составляют пароль (скажем, он должен содержать строчные и прописные буквы алфавита, одна или две цифры и несколько не алфавитных символов, таких как ^ или #).

8 голосов
/ 06 октября 2009

Лучшее - никаких ограничений, если только вы не можете их оправдать.

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

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

2 голосов
/ 07 октября 2009

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

Относительно вашего второго вопроса. Я бы реализовал это путем создания отдельных полей для повышения надежности пароля. Например, сейчас у вас есть два поля, которые относятся к паролю: salt, password_md5. Позже скажем, что вы хотите использовать sha256. Создайте новое поле с именем password_sha256. Когда пользователь входит в систему, сначала проверьте password_sha256. Если это поле пустое, проверьте password_md5. Если это соответствует, у вас есть пароль в виде простого текста, введенный пользователем. Затем вы можете сгенерировать пароль sha256 (я также сбросил бы соль для хорошей меры) и сохранить новое значение. Затем я бы пропустил значение в password_md5, чтобы никто не мог отменить это, чтобы получить пароль.

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

2 голосов
/ 06 октября 2009

Пробел (в зависимости от логики он может быть случайно обрезан перед хэшированием)

2 голосов
/ 06 октября 2009

Любой неконтролирующий символ должен быть в порядке. Я должен подумать, что в будущем разработчики систем супер-паролей позволят использовать «необычные» символы ASCII, такие как знаки препинания и другие знаки, но управляющие символы имеют привычку громоздко вводить в оболочках текстового режима и даже в диалоговых окнах графического интерфейса, которые ожидают ввода и Enter / Return, чтобы быть свободным для своих собственных целей.

1 голос
/ 22 июля 2016

Лично я всегда стремился не применять слишком много правил.

Это только что изменилось. Я только что обнаружил, что мой сайт уязвим для атак XSS. Решение состоит в том, чтобы очистить каждый фрагмент ввода, который приходит от пользователя, включая пароль.

В течение 10 лет у нас не было ограничений на пароль. Сейчас мы реализуем ограничение на количество символов, которые можно использовать, и это просто для того, чтобы заблокировать хакерам возможность доступа к Javascript или SQL. Итак, мы построили следующий список:

Допустимые символы для пароля: a-z A-Z 0-9. - _ $ * () # @! % / (пусто)

Это обеспечивает большую гибкость, но позволяет избежать символов, которые могут быть использованы при кодировании взлома XSS, например; <> \ {} [] + =? &, '' `

НТН

0 голосов
/ 11 августа 2016

Некоторые правила, которым нужно следовать:

  1. Избегайте управляющих персонажей. Это не так распространено сегодня, но все управляющие символы имеют особое значение, а некоторые аппаратные средства перехватывают управляющие символы для выполнения специальных функций. Некоторые вызовут проблемы с данными. Пример Control 0 (Zero) будет генерировать ноль.
  2. Собираетесь ли вы вводить ограничения безопасности? Это вопрос интерфейса пользователя, а также проблема безопасности. Какова ваша заявка, и это нужно для безопасности. Многие из приведенных ранее примеров устарели. Хеш-таблицы для комбинаций паролей публикуются для паролей длиной до 15 символов, а пароли из 16 символов можно перебирать в течение нескольких минут, если пароль в противном случае слаб или соответствует обычному поведению человека. Начинается с заглавной буквы, заканчивается цифрой или специальным символом.
  3. Я бы избегал общих подстановочных знаков, кавычек, двоеточия, точки с запятой и т. Д., Которые обычно используются в языках ОС или БД.
  4. Многофакторная аутентификация - хороший способ. Не полагайтесь только на пароль или вообще не принимайте его.
0 голосов
/ 28 сентября 2012

Лично я использую Fingerprint Keyboard от DigitalPersona (да, Microsoft [делает или делает] подобное устройство, оба интегрированные с клавиатурой или отдельно от нее).

Это позволяет генерировать чрезвычайно длинные и сложные пароли, которые не нужно записывать (так как нажатие пальцем на считыватель вводит пароль в диалоговое окно входа в систему [система / приложение / веб-сайт]).

Это, на мой взгляд, обеспечивает лучшее из обоих миров: чрезвычайно сложно «угадать» пароли без необходимости их запоминать. Также упрощается дополнительная рекомендация по безопасности использования разных паролей в разных системах.

Ну, это ценность моих двух центов.

0 голосов
/ 07 октября 2009

В нашей организации, если пользователь вводит пароль, мы разрешаем ему использовать все, что он хочет.

Когда пользователи впервые регистрируются в системе, для них генерируется пароль. Поскольку этот пароль обычно отправляется им по почте, мы избегаем использования определенных символов, которые могут быть перепутаны, особенно при использовании определенных шрифтов. Например, буква O и число 0 (ноль) не используются. То же самое для L, I и 1 (один), S и 5, Z и 2 и др.

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

0 голосов
/ 06 октября 2009

Правила, которые я бы предложил применить:

  1. Длина - не менее 8 символов - но не более 20
  2. Простота взлома - пропуск не должен содержать имя пользователя, фамилию или имя пользователя, а также (если возможно, проверять) любое слово, которое появляется в английском словаре.
  3. Содержание - на клавиатуре есть 4 типа символов: прописные, строчные, цифры и знаки препинания. Хороший пароль должен включать представителей не менее 3-х групп и не более 2-3 символов одной группы подряд.
...