Безопасно ли блокировать пароли, слишком похожие на старые пароли других сотрудников?

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

Ранее я никогда не думал об этом, но только что осознал, что это значит (или может значить).

Когда я отправил электронное письмо в IT-отдел, они с радостью предоставили мне детали:

• У них есть другая техническая политика, о которой я не знал, а именно: ваш пароль не может быть слишком похож на ваш старый,
• Когда вы меняете пароль, вам (очевидно) нужно ввести старый пароль, и затем этот старый пароль шифруется и сохраняется.
• Фактическое правило заключается в том, что ваш пароль не может быть слишком похожим (>5 совпадающих символов на одном месте) на старый пароль другого сотрудника.

Я неправильно понял причину этого правила изначально: оно на самом деле предотвращает возможность использования ранее утекших паролей для разных текущих пользователей.

Но является ли это безопасной или рискованной политикой паролей?

Проверка на схожесть требует, чтобы пароль хранился в восстанавливаемом формате, либо в открытом виде, либо зашифрованным с ключом, доступным серверу. В качестве альтернативы система могла бы сохранять вариации пароля, но это бы утекло информацию о пароле и имеет другие проблемы.* Хеширование паролей с помощью алгоритмов, таких как Argon2, scrypt или bcrypt, скрывает любые сходства. Если бы этого не было, это стало бы серьезной уязвимостью, так как злоумышленник, получивший доступ к базе данных, мог бы попробовать несколько паролей, а затем сравнить полученные хеши с сохраненными, чтобы получить информацию о паролях других пользователей.

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

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

*Как указал gnasher729, система могла бы хешировать вариации пароля и хранить эти хеши для реализации проверки на схожесть. Тем не менее, это все равно не решает проблему, поскольку алгоритмы хеширования паролей делают такое сравнение крайне медленным. Чтобы это исправить, хеши должны быть нарочно слабыми, что увеличивает риск успешной атаки методом подбора. schroeder предложил хешировать возможные префиксы с помощью быстрого алгоритма и хранить эти хеши. Это решило бы проблемы с производительностью и не обнажило бы пароль для атак методом подбора. Тем не менее, это все еще утекло бы информацию о первых n символах пароля.

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

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

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

Это также поймает мистера Смита, пытающегося использовать тот же пароль, который его клуб любителей голубей утек в прошлом году.

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

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

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

Одной из проблем безопасности является то, что сотрудник может повторно использовать один и тот же пароль где-то еще и только менять его на рабочем компьютере. Это увеличивает риск утечки пароля для всех этих других аккаунтов. Разъединение старого пароля с учетной записью немного помогает, так как потенциальный злоумышленник изначально не будет знать, какой сотрудник связан с паролем. Но та же проблема также возникает в случае, который компания пытается защитить: что если несколько сотрудников уже используют похожие пароли и один из них меняет свой? Это увеличивает риск утечки паролей этих других сотрудников. И компания не может обнаружить, что эти аккаунты используют один и тот же пароль, пока не получит в свои руки открытые пароли в следующий раз. Проведение этой проверки на схожесть при каждом входе, а не только при сбросе пароля, поможет выявить это раньше.

Может ли быть способ, чтобы они могли проверять, что пароли не похожи одновременно с их хешированием, или эта политика имеет изъян?

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

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

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

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

Это, вероятно, зависит от политики ротации паролей компании.

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

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

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

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

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

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

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

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

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

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

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

Как будто это похоже на игру Mastermind, если она говорит вам, сколько символов вы угадали и находятся ли они в правильном месте… Я имею в виду, что вам сообщают, что ваш пароль слишком похож в X местах. Серьезно, вы могли бы ввести пароль, который действителен, и модифицировать его, пока он не скажет вам, что вам следует использовать меньше 5 символов на той же позиции, что и другой (что означает, что у вас точно 5 символов на одной и той же позиции, что и у другого). Так что вы продолжаете менять 1 символ за раз, чтобы выяснить, какие из них вы угадали правильно, записываете их, выключаете один из 5 и продолжаете в другой позиции, пока снова не получите жалобу. Чем длиннее пароль, тем легче за короткий промежуток времени случайно получить 5 правильных, а после этого это тривиально…

Теперь кажется, что они просто считают старые пароли по сути скомпрометированными и общедоступными. Так что они проверяют новый пароль на наличие в списке старых. При этом удостоверяются, что новый пароль достаточно отличается от пароля в этом списке (по сути эквивалентно сообщению, что у вас слабый пароль). Что снова ставит вопрос, как они узнали старый пароль (хорошо, потому что вы ввели и отправили его), но им либо придется добавить это в базу данных в открытом виде, либо это будет бесполезно для дальнейшего сравнения, и в то время как новый пароль ДОЛЖЕН быть достаточно отличным от тех, которые можно найти в этом открытом файле, это также означает, что они ДОЛЖНЫ быть достаточно отличными от тех в этом файле, так что наличие этого файла может оказаться гораздо более ценным, чем они могут осознавать, так как это значительно уменьшает список возможных паролей, в зависимости от размера компании, что может охватывать множество вариантов паролей, которые теперь недействительны.