Цитаты о невидимости глобально уникального пароля

20

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

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

[ПРАВИТЬ]
Спасибо за все ваши ответы, но я уже понимаю проблемы с этим предложенным подходом / требованием и даже могу объяснить их клиенту, но клиент не примет их, поэтому мой запрос на независимые и / или авторитетные источники ,

Я также нашел статью Daily WTF, но она страдает от проблемы, на которую указал Джон Хопкинс - что это такой самоочевидный WTF, что, похоже, не стоит объяснять почему .

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

Любые ссылки на независимые и / или авторитетные источники о том, почему это плохая идея, до сих пор с благодарностью принимаются ...
[/ EDIT]

gkrogers
источник
2
Это достаточно странная идея, и я думаю, что вам повезет, что об этом вообще много написано. На мой взгляд, это настолько очевидно, что эксперты по безопасности не считают это настолько серьезным, чтобы о нем писать.
Джон Хопкинс
3
Я действительно очень надеюсь, что вы не храните незашифрованные пароли, а скорее соленые и хэшированные. Если они соленые и хэшированные, будет трудно обеспечить глобальную уникальность. Если нет, то мне нет дела до вашей безопасности, так как я уже знаю, что это плохо.
Дэвид Торнли
1
Несмотря на уязвимости безопасности, не могли бы вы просто отклонить пароль, если он не может однозначно хешировать?
Роберт Харви
После редактирования я повторяю свой ответ - это не «не будет», а «нельзя» (из-за способа хранения паролей), поэтому вместо того, чтобы объяснять, почему это плохо для того, кто не Вы заинтересованы в том, чтобы вернуться к процессу и понять, почему клиент считает, что это необходимо в первую очередь.
Murph
2
Интересно, что они доверяют вам достаточно, чтобы спроектировать свою систему, но не настолько, чтобы консультировать их по проектированию их системы.
Гари Роу

Ответы:

24

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

Кроме того, имена пользователей гораздо проще угадать (и если есть форум, вы можете просто найти там много имен пользователей), и вы намекаете пользователю, как взломать сайт.

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

РЕДАКТИРОВАТЬ: Не близко к автору, но, возможно, полезно после того, как вы объясните им, что означает WTF: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx

deltreme
источник
+1 Кроме того, большинство схем аутентификации позволяют вам использовать столько имен пользователей, сколько вам нужно, но при этом вы можете ввести только три попытки ввода пароля.
Майкл К
1
Этот WTF предназначен для использования пароля в качестве первичного / внешнего ключа больше всего на свете. Ну, может быть, для простых текстовых паролей.
Murph
2
+1: Вы никогда не должны допускать, чтобы любой другой пользователь имел такой же пароль. Поговорим о серьезном недостатке безопасности ... Вы можете проводить атаки с использованием перебора паролей путем многократного изменения пароля. Это пролетело бы под радаром множества систем мониторинга.
Satanicpuppy
На самом деле, в некоторых контекстах наличие единого поля для учетных данных было бы разумным, если бы пароли требовалось выбирать так, чтобы какая-то конкретная часть (например, первая буква) была уникальной. Например, если у пользователя 26 пользователей или меньше, можно сказать, что каждый пользователь должен выбрать пароль, который начинается с другой буквы. Такая система будет эквивалентна наличию 26 отдельных односимвольных имен пользователей, но позволит избежать необходимости нажимать «табуляцию» или «ввод» между именем и паролем.
суперкат
10

Лучшая практика мешает выполнению требования:

Вы не можете сделать это, потому что вы не знаете, что такое пароли, поэтому вы не можете сравнить их, потому что все, что вы храните, это хэш пароля и соль (которую вы можете хранить рядом с хешированным паролем). Это лучшая практика, вот что вы делаете. Выполнено.

Другое редактирование: Doh! Оглядываясь назад легко - вы все равно можете проверить уникальность, потому что (конечно) у вас есть соль ... просто застрелите меня сейчас ... конечно, вам не нужно упоминать эту деталь клиенту.


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

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


Хорошо, мой ответ изначально начинался с:

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

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

Murph
источник
4
+1 за понимание того, почему кто-то может запрашивать уникальные пароли
Майкл Харен
3
Но это уязвимость безопасности - если вы пользователь, введите новый пароль и вам скажут, что он недействителен, теперь вы знаете, что по крайней мере один пользователь имеет этот пароль. Объедините это с другими факторами (скажем, языком, на котором написано слово, или некоторым контекстом / значением, которое оно может иметь для кого-то), и вы обнаружили очень ограниченное количество вариантов, которые могут легко попасть в атаку грубой силой - даже потенциально вручную. один.
Джон Хопкинс
Хм, я не сказал, что это не было потенциальной проблемой, я сказал, что это не совсем глупо, как было предложено в вопросе, потому что это предотвращает использование одного и того же пароля у нескольких пользователей (что происходит), и что хуже, если эти пароли слабые в первую очередь. Предоставление пользователям доступа к системе вообще является уязвимостью безопасности ... но мы должны с этим мириться и, следовательно, все, что после этого является компромиссом.
Murph
+1 за указание, что вы не можете сделать это, если вы правильно обрабатываете пароли.
Дэвид Торнли
Можем ли мы также заметить, что мой ответ заключается в том, что вы не можете проверить уникальность, потому что вы все равно должны хешировать пароль? Так что, если у меня есть отрицательное мнение, что я хотел бы знать, почему?
Murph
10

Применение неповторимых паролей приводит к утечке информации

Как? Поскольку каждый раз, когда взломщик пытается создать нового пользователя с простым паролем, ваша система отвечает «Нет, пароль не может быть», взломщик говорит: «Хорошо, это один из списка».

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

Ресурсы, описывающие хорошие и плохие политики управления паролями

Прочитайте эту статью эксперта по безопасности Брюса Шнайера для подробного обсуждения надежности пароля.

Прочитайте этот PDF от исследователей безопасности Филиппа Инглесанта и М. Анжелы Сасс для углубленного обсуждения «Истинной стоимости неиспользуемых политик паролей». Цитировать из заключения:

Вопреки мировоззрению, что «если бы [пользователи] понимали опасность, они бы вели себя по-другому» [12], мы утверждаем, что «если бы только менеджеры по безопасности понимали истинные затраты для пользователей и организации, они бы устанавливали политики по-разному».

Ложное чувство безопасности

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

Для онлайнового доступа достаточно 6 символов

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

Если у вас есть система паролей, которая работает в режиме онлайн, вам не нужны пароли с высоким уровнем безопасности. Пароли должны быть достаточно сложными, чтобы предотвратить угадывание в течение 20 попыток (поэтому простая атака «имя супруга / ребенка / питомца» не удастся). Рассмотрим следующий алгоритм:

  1. Взломщик угадывает пароль, используя подход «root плюс суффикс», чтобы минимизировать угадывание
  2. Учетные данные отклонены и дальнейшие попытки входа в систему запрещены на N * 10 секунд
  3. Если N> 20 заблокировать учетную запись и сообщить администратору
  4. N = N +1
  5. Сообщите пользователю, что следующий вход может произойти в момент времени T (рассчитано выше)
  6. Перейти к шагу 1

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

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

Гэри Роу
источник
1
Что вы подразумеваете под «он-лайн» доступом? Есть ли другой вид?
Роберт Харви
См последнее предложение для различия в условиях безопасности.
Гари Роу
4

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

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

PeterAllenWebb
источник
4

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

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

Можете ли вы представить, что у вас 10000 пользователей, и требуется 30 секунд, чтобы пройти пароль каждого пользователя, чтобы проверять уникальность каждый раз, когда кто-то новый регистрируется или меняет свой пароль?

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

Дин Хардинг
источник
Да. Это было бы хорошим замечанием.
PeterAllenWebb
1

Если подумать о подходящем месте, чтобы задать вопрос, то раздел информационной безопасности Stack Exchange должен быть для вас полезным. Попробуйте /security/tagged/passwords - ряд людей, специализирующихся на информационной безопасности, должны быть в состоянии дать конкретные ответы.

Рори Олсоп
источник
0

Он, вероятно, хотел бы RSA двухфакторного шифрования. Если вы используете Active Directory или членство в ASP.NET, это не сложно.

альтернативный текст

Аппаратный или программный токен генерирует зависящий от времени уникальный пароль, за которым следует PIN-код. Это вместе предоставляет уникальный пароль для каждого пользователя.

goodguys_activate
источник
Два фактора бесполезны для предотвращения атак «человек посередине».
BryanH
Да, но это утверждение, похоже, не относится к рассматриваемому вопросу.
goodguys_activate
Но теперь я знаю твой второй фактор !!! Ой, подождите ... пожалуйста, обновите свою фотографию
Майкл Харен
2
Хм, я думаю, было бы здорово сделать этот анимированный GIF
goodguys_activate