Принудительные буквенно-цифровые идентификаторы пользователей - PullRequest
3 голосов
/ 19 сентября 2008

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

Как вы думаете, это хорошее требование?

У вас есть веские причины не делать этого?

Вам известно о каких-либо исследованиях, на которые я мог бы сослаться?

Редактировать: Это не в отношении пароля. У нас уже есть похожие требования к этому, чему я не против.

Ответы [ 9 ]

4 голосов
/ 19 сентября 2008

Я бы начал с того, что спросил их об их конкретных причинах. Если у вас есть список пунктов и причины, по которым его легче опровергнуть или предоставить альтернативы.

Что касается общих идей:

  • Это мнение, но добавление цифры к имени пользователя не обязательно повысит безопасность. Люди записывают имена пользователей в заметках, большинство пользователей просто добавляют «1» в начале или конце своего имени пользователя, что позволяет легко угадать.
  • С точки зрения юзабилити, это плохо, так как нарушает норму. Принудительное добавление цифры к имени пользователя приведет к приведенному выше пункту. Они просто добавят «1» в конец или начало своего имени пользователя.

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

4 голосов
/ 19 сентября 2008

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

Кроме того, в зависимости от системы идентификаторы пользователя могут работать как значения по умолчанию при подключении к внешним системам (ssh ведет себя таким образом в unix-подобных системах). В этом случае, безусловно, выгодно иметь один ID, который будет использоваться несколькими системами.

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

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

1 голос
/ 19 сентября 2008

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

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

Для обоих банковских счетов, которые у меня есть, требуется буквенно-цифровое имя пользователя и два пароля для входа в систему через Интернет. У одного из них также есть изображение, которое я должен запомнить. Два пароля нужно менять раз в месяц или около того. Поэтому у меня есть вся информация для входа прямо здесь, в текстовом файле. (Даже смотреть на это не имеет никакого смысла; мне придется пойти в банк и сбросить мои пароли снова. Это всего 7 сбросов паролей для 6 входов в систему. Поговорим о безопасности, даже не I может получить доступ к моей учетной записи.)

1 голос
/ 19 сентября 2008

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

1 голос
/ 19 сентября 2008

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

0 голосов
/ 19 сентября 2008

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

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

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

Наличие несовместимых имен пользователей добавляет ряд специфических рисков:

  1. Это усложнит отслеживание контрольного журнала (серьезная угроза безопасности).
  2. Это может добавить стоимость, если позже вы начнете использовать единый знак .
  3. Это приведет к ухудшению работы пользователя, так как пользователи должны помнить, что это приложение использует странное имя пользователя.
0 голосов
/ 19 сентября 2008

Я также работаю в финансовом учреждении, и наши имена пользователей (как реальных людей, так и производственные идентификаторы) все строчные, алфавитные, до 8 символов, и я никогда не считал это проблемой ... избегает путаницы 0 против O , 1 против I и 8 против B - если вы не работаете в той же компании, что и я, и собираетесь внедрить новую политику ...

0 голосов
/ 19 сентября 2008

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

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

0 голосов
/ 19 сентября 2008

хорошо, если это в их пароле (увы, финансовые компании любят отказывать вам в этом обеспечительном праве [я говорю с вами по-американски)]

имя пользователя, я говорю нет, если они не хотят.

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