У меня возникли разногласия с кем-то (клиентом) относительно процесса идентификации / аутентификации пользователя для системы. Суть в том, что они хотят, чтобы у каждого пользователя был глобально уникальный пароль (т.е. два пользователя не могут иметь одинаковый пароль). Я привел все очевидные аргументы против этого (это уязвимость безопасности, она путает идентификацию с аутентификацией, это бессмысленно и т. Д.), Но они настаивают на том, что в этом подходе нет ничего плохого.
Я проводил различные поиски в Google в поисках авторитетных (или полу-авторитетных, или даже просто независимых) мнений по этому поводу, но не могу найти ни одного (в основном, это настолько очевидное измышление, против которого не стоит предупреждать, так как насколько я могу судить). Кто-нибудь может указать мне на такое независимое мнение, пожалуйста?
[ПРАВИТЬ]
Спасибо за все ваши ответы, но я уже понимаю проблемы с этим предложенным подходом / требованием и даже могу объяснить их клиенту, но клиент не примет их, поэтому мой запрос на независимые и / или авторитетные источники ,
Я также нашел статью Daily WTF, но она страдает от проблемы, на которую указал Джон Хопкинс - что это такой самоочевидный WTF, что, похоже, не стоит объяснять почему .
И да, пароли будут засолены и хешированы. В этом случае глобальную уникальность может быть трудно обеспечить, но это не решает мою проблему - это просто означает, что у меня есть требование, чтобы клиент не сдвинулся с места, это не только опрометчиво, но и трудно осуществлять. И если бы я был в состоянии сказать: «Я не сдвигаюсь с мертвой точки и хэширования», то я был бы в состоянии сказать: «Я не использую глобально уникальные пароли».
Любые ссылки на независимые и / или авторитетные источники о том, почему это плохая идея, до сих пор с благодарностью принимаются ...
[/ EDIT]
Ответы:
Всякий раз, когда клиент пытается создать пароль, который уже существует, он получает сообщение о том, что какой-то пользователь уже использует этот пароль, что обычно является нарушением соглашения о конфиденциальности.
Кроме того, имена пользователей гораздо проще угадать (и если есть форум, вы можете просто найти там много имен пользователей), и вы намекаете пользователю, как взломать сайт.
Где-то в Интернете должна быть какая-то страница, описывающая часть нарушения соглашения о конфиденциальности, за исключением того, что это просто здравый смысл: в основном они дают кому-то ключ и список домашних адресов.
РЕДАКТИРОВАТЬ: Не близко к автору, но, возможно, полезно после того, как вы объясните им, что означает WTF: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx
источник
Лучшая практика мешает выполнению требования:
Вы не можете сделать это, потому что вы не знаете, что такое пароли, поэтому вы не можете сравнить их, потому что все, что вы храните, это хэш пароля и соль (которую вы можете хранить рядом с хешированным паролем). Это лучшая практика, вот что вы делаете. Выполнено.
Другое редактирование: Doh! Оглядываясь назад легко - вы все равно можете проверить уникальность, потому что (конечно) у вас есть соль ... просто застрелите меня сейчас ... конечно, вам не нужно упоминать эту деталь клиенту.
FWIW, это не так глупо, как вы думаете - цель состоит в том, чтобы не дать группам пользователей согласовать и использовать один и тот же пароль, который люди будут делать, полагая, что это облегчит их жизнь.
При применении с требованием регулярно менять пароль и ограничением, которое не позволяет людям повторно использовать текущий или ранее использовавшийся пароль (вообще, когда-либо) и разумными требованиями к надежности (или, по крайней мере, предварительно загруженным словарем «заблокированных» «пароли», вы довольно быстро доберетесь до точки, где шансы в любом случае не в пользу хакера.
Хорошо, мой ответ изначально начинался с:
Видимо, неуместный юмор - дело в том, что если у вас нет уникального в глобальном масштабе ограничения, вы создаете разные возможности, возможно, менее опасные - я не знаю.
источник
Применение неповторимых паролей приводит к утечке информации
Как? Поскольку каждый раз, когда взломщик пытается создать нового пользователя с простым паролем, ваша система отвечает «Нет, пароль не может быть», взломщик говорит: «Хорошо, это один из списка».
Утечка информации о вашей безопасности, как правило, плохо. Хорошо, третьи лица знают, что алгоритм в порядке (он требует экспертной оценки), но позволяют специальному взломщику выводить ключи - плохо, действительно, очень плохо.
Ресурсы, описывающие хорошие и плохие политики управления паролями
Прочитайте эту статью эксперта по безопасности Брюса Шнайера для подробного обсуждения надежности пароля.
Прочитайте этот PDF от исследователей безопасности Филиппа Инглесанта и М. Анжелы Сасс для углубленного обсуждения «Истинной стоимости неиспользуемых политик паролей». Цитировать из заключения:
Ложное чувство безопасности
Таким образом, клиент работает с: «Если никто не имеет такой же пароль, то, если он взломан, то затрагивается только один человек». Нет. Это затронуто всеми, потому что взломщик продемонстрировал, что ваша система паролей имеет принципиальные недостатки: она уязвима для атаки по словарю в онлайновой системе. В первую очередь взломщик не мог попытаться сделать несколько попыток угадать пароль.
Для онлайнового доступа достаточно 6 символов
Уходя не по теме, но я подумал, что стоит упомянуть заинтересованных читателей. С точки зрения безопасности онлайновая система - это система, которая имеет активный процесс управления безопасностью, контролирующий и контролирующий доступ к данным. Автономная система - это система, которая этого не делает (например, имеет зашифрованные данные на украденном жестком диске).
Если у вас есть система паролей, которая работает в режиме онлайн, вам не нужны пароли с высоким уровнем безопасности. Пароли должны быть достаточно сложными, чтобы предотвратить угадывание в течение 20 попыток (поэтому простая атака «имя супруга / ребенка / питомца» не удастся). Рассмотрим следующий алгоритм:
Для простого 6-символьного пароля вышеупомянутый алгоритм предотвратит атаки по словарю, в то же время позволяя даже самому неумелому пользователю на мобильной клавиатуре со временем дозвониться. Ничто не помешает так называемой «атаке резинового шланга», когда вы бьете держателя пароля резиновым шлангом, пока вам не сообщат.
Для автономной системы, когда зашифрованные данные лежат на флэш-накопителе, и взломщик имеет возможность попробовать что-либо против него, вам нужен наиболее надежный ключ, который вы можете найти. Но эта проблема уже решена .
источник
Если бы вы посоветовали им противостоять этому курсу действий и предоставили им причины, я бы взял их на слово и просто внедрил систему, как они предлагают. Это может не удовлетворять, но вы выполнили свою работу, и они оплачивают счета, поэтому они должны получить то, что они хотят.
Есть одно исключение. Если негативные последствия взлома системы будут серьезными (например, если конфиденциальная информация может быть скомпрометирована из-за взлома системы безопасности), на самом деле у вас может быть профессиональная обязанность не внедрять требуемую систему. Не ожидайте, что это сделает вас популярным, если вы откажетесь, но не позволяйте этому быть вашим гидом.
источник
Я просто хочу подтвердить ответ Мерфа. Да, это проблема безопасности, и в ее реализации есть уязвимости, связанные с раскрытием информации. Но с точки зрения клиента он, кажется, не слишком обеспокоен этим.
На что следует обратить внимание, так это на то, что это физически невозможно реализовать проверку «уникального пароля». Если вы солите и хэшируете пароль, а не сохраняете его в виде открытого текста, тогда это O (n) (дорогие) операции, чтобы фактически выполнить проверку уникальности.
Можете ли вы представить, что у вас 10000 пользователей, и требуется 30 секунд, чтобы пройти пароль каждого пользователя, чтобы проверять уникальность каждый раз, когда кто-то новый регистрируется или меняет свой пароль?
Я думаю, что это ответ, который вы должны принять к своему клиенту.
источник
Если подумать о подходящем месте, чтобы задать вопрос, то раздел информационной безопасности Stack Exchange должен быть для вас полезным. Попробуйте /security/tagged/passwords - ряд людей, специализирующихся на информационной безопасности, должны быть в состоянии дать конкретные ответы.
источник
Он, вероятно, хотел бы RSA двухфакторного шифрования. Если вы используете Active Directory или членство в ASP.NET, это не сложно.
Аппаратный или программный токен генерирует зависящий от времени уникальный пароль, за которым следует PIN-код. Это вместе предоставляет уникальный пароль для каждого пользователя.
источник