Pull to refresh

Comments 7

NIST SP 800-63B-3 прошел Вашу контору стороной?

Verifiers should not require passwords to be changed arbitrarily (e.g., periodically). However, verifiers shall force a change if there is evidence of compromise of the password.

Уже даже MS отказывается от практики регулярной смены пароля…

Она не отказывается на On-Prem. Только в облаке. А в облаке у них умная авторизация, которая заорет, если вы внезапно вошли из Гондураса, например.

Это вы с чего взяли? Вы вообще читали по ссылке, что я привел? Какая разница Cloud или On-Premises? Речь о том, что многочисленные иследования показали, что регулярная смена паролей, как правило, ничего не дает, а зачастую просто вредна. В итоге плюсов значительно меньше, чем минусов. Это официальная рекомендация NIST с 2017-ого года, и включено в текущий baseline-драфт для всех актуальных MS OS.

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

Я исключительно отвечал про Майкрософт. По NIST в курсе, но при использовании однофактопной авторизации MS в On-Prem инфраструктуре пока что не в состоянии обеспечить сравнимый уровень защиты. Потому и написал что они только в облаке это внедряют

Э… Я даже не знаю что и сказать. Еще раз (в последний):

Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903

Что кто куда внедряет? Начиная с v1903 повсеместно требование по умолчанию о регулярной рутинной смены пароля отменяется (в On-Premises тоже, естественно). Это финально принятый baseline. Вот тут, например, разжевано, если все равно не понятно.
Возможно, интуитивно чувствуется проблема в другом. Пароль скомпрометирован, пользователь ни сном ни духом, это дает простор для подготовки ленивой атаки. Вообще, чем дольше пароль существует, тем больше вероятность, что пользователь его где-то оставит. Есть такая тенденция у юзеров, унифицировать пароли.

Что до документа, там рекомендуется использовать вместо смены пароля более прогрессивные методы защиты, а не слепо отключить смену пароля, а это же совсем другой разговор.
NIST — NIST-ом, но есть и иные стандарты, так же носящие, в целом, рекомендательный характер, и в них такой нормы пока не описано, за исключением самых современных.
Да и обязательны к исполнению они лишь там, где такие стандарты взяты за основу политики безопасности, или есть соответствующие требования аудиторов.
Многие (подавляющее большинство) компании до сих пор имеют критикуемую Вами норму в своих политиках безопасности. Именно поэтому, им необходимо иметь такой индикатор «перед глазами».

Чтобы немного контраргументировать, в том же документе NIST есть следующее обязующее условие:
“force a change if there is evidence of compromise of the password.”
Предположим (вполне обоснованно), что у средней компании нет средств эффективного обнаружения данного события. Следует ли именно данной компании отказываться от практики периодической смены пароля(хоть она и неудобна)?

Тот же вопрос, по сути, можно усмотреть и во фразах представителя Microsoft в приводимой Вами же статье:
«If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration?»
«At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.»
Ну и просто чтобы не устраивать холивар по несущественному, на наш взгляд, поводу:
неплохая подборка выдержек из различных актуальных стандартов, и вывод по требуемой сложности и длине паролей: www.diwebsity.com/2019/08/10/password-security-standards, с которым на текущий момент мы согласны, но сложности паролю следовало бы добавлять и региональными символами из Unicode, и, вероятно, псевдографикой, что также предусмотрено в большей части самых новых версий стандартов.
Sign up to leave a comment.