Какие символы Вы сделали бы недопустимым для пароля?

rsync://[USER@] ХОСТ [: ПОРТ]/SRC... [DEST] | хвост [DEST]?

6
задан skaffman 6 October 2009 в 08:43
поделиться

9 ответов

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

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

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

9
ответ дан 8 December 2019 в 04:30
поделиться

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

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

13
ответ дан 8 December 2019 в 04:30
поделиться

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

2
ответ дан 8 December 2019 в 04:30
поделиться

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

2
ответ дан 8 December 2019 в 04:30
поделиться

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

0
ответ дан 8 December 2019 в 04:30
поделиться

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

0
ответ дан 8 December 2019 в 04:30
поделиться

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

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

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

0
ответ дан 8 December 2019 в 04:30
поделиться

Правила, которые я предлагаю соблюдать:

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

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

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

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

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

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

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

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

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

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

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

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

d также сбросьте соль для хорошей меры) и сохраните новое значение. Затем я бы вычеркнул значение в password_md5, чтобы никто не мог отменить его, чтобы получить пароль.

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

d также сбросьте соль для хорошей меры) и сохраните новое значение. Затем я бы вычеркнул значение в password_md5, чтобы никто не мог отменить его, чтобы получить пароль.

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

2
ответ дан 8 December 2019 в 04:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: