Комментарии 46
Этой табличке 10+ лет.....
Сейчас Бум Крипты и последующие падения курса уронил цены из нее примерно раз в 300(в Три сотни раз, примерно)... а разработки алгоритмов для тех же SHA3 Zoo и подобных наборов алгоритмов подняли скорость брутфорса до 0,5-0,8 ГигаХешей в секунду почти для всех массовых алго(или их частей), т.е примерно в 30-40 раз....
согласились участвовать 51 доброволец из тематических сообществ r/PCMasterRace, r/SysAdmin и r/CyberSecurity
Мало того, что выборка состоит из крипто/it-энтузиастов и профи, так она еще и дополнительно скошена теми, кто согласился на эксперимент (а не решил "ну его нафиг").
Критика частой смены паролей не относится к этим людям, она относится к обычным гражданам.
Угу, социальный эксперимент нужно еще уметь поставить так, чтобы он не проверял что-то очень сильно отличающееся от того, что хотят проверить авторы идеи эксперимента.
Тем более что анти-паттерн "энтомолог с лупой" - известен, описан и должен был быть исключен в этой ситуации простым опросом о том, как именно испытуемые придумывали эти пароли. И если там преобладали бы ответы типа "использовал генератор", все результаты должны были быть отправлены в помойку.
Потому что "обычный гражданин" на порядки чаще использует при изменении шаблон, например - добавляет один символ, меняет один символ.
В случае если сервер принимает соответствующие современным рекомендациям меры защиты, такие как антифлуд, соль в хэше и правильные алгоритмы хэширования, - то восьми символов в пароле будет достаточно.
Если же сервер не принимает мер к защите - то пользователю бесполезно как-то шаманить со сверхдлинными паролями. Если вы предполагаете что сервер дырявый (т.е. можно скачать хэш) и хэш там сделан слабым алгоритмом, то почему вы тогда не предполагаете заодно что сервер вовсе хранит плейн-текст?
Если в обсуждении стойкости паролей с формулами (!) не упоминается антифлуд и блокировка с эскалацией (типа принудительной смены и т.п., зависит от контекста), то это тупо сенсационалистская писанина, не имеющая к серьезному техническому анализу проблемы никакого отношения. Что не странно, потому что уже сама методология исследования - из разряда garbage in, garbage out, потому что адский selection bias.
это тупо сенсационалистская писанина, не имеющая к серьезному техническому анализу проблемы никакого отношения.
Меня бы гораздо более интересовал тест вида:
* X пользователей завели аккаунты (пусть даже с искусственно короткими паролями, см. далее)
* В это время исследователи начали пароли ломать и ломали в течение Y дней
* Из тех, кто не менял — сломали N паролей, из тех, кто не менял — сломали M паролей.
Вывод: N > M, менять пароли надо (или N < M, менять пароли не надо).
А как сейчас — это измерение попугаев.
рекомендации против периодической смены паролей
Это, скорее, попытка угодить самим пользователям, потому что больше вероятность того, что новые пароли будут записываться, и хорошо если не на бумажках, которые клеят на монитор.
Но вот на внешних серверах пароли лучше менять, потому что довольно часто база паролей с них утекает, а так в дампе будет старый пароль.
Ну и принцип временной блокировки аккаунта после 3-5 неудачных попыток - тоже мешает эффективному подбору паролей.
Ну и принцип временной блокировки аккаунта после 3-5 неудачных попыток - тоже мешает эффективному подбору паролей.
Подбор в принципе невозможен с скоростями типа "более ста миллиардов вариантов в секунду". Это все актуально исключительно при доступности хешей паролей.
И тогда регулярная замена паролей чем-то напоминает сеансовый пароль того же https.
Любое правило информационной безопасности, превращенное в ритуал культа карго, скорее - вредит чем помогает.
В каких ситуациях регулярная смена паролей помогает?
1. От слитых хэшей паролей. Эффект - удовлетворительный, возможно успеть сменить пароль за время брута, даже если не знать о сливе хэша пароля.
2. От брутфорса сервиса. Эффект - околонулевой, нужно бороться с самим фактом брута(банить по ip, урезать кол-во попыток, в крайнем случае - прятать сервис во внутренней сети с доступом по vpn).
3. От слитых паролей. Эффект околонулевой(даже если менять пароли каждый день, злоумышленник успеет за это время сделать почти что угодно)
В двух с половиной случаях из трёх(слить белый пароль в открытом виде может как сервис, так и пользователь, а вот слить хэш от пароля или позволить брутить учётку модет только сервис) в уязвимости виноват сервис, а не пользователь, так что частая смена паролей, не смотря на некоторую эффективность, нужна сервису что-бы прикрыть жопу, а не конечному пользователю.
Теперь о минусах частой смены паролей.
1. Пользователь забывает пароли, как результат п.2, п.3, п4
2. Пользователь начинает записывать пароли, и создаёт ещё одно направление атаки
3. Пользователь начинает использовать одинаковые пароли на разных сервисах, что создаёт ещё одно направление атаки
4. Как сказано в статье, при частой смене паролей падает их энтропия, вплоть до "номерных" паролей, типа mypassword1 mypassword2, итд.
Есть еще один, очень частый пункт 4
4. Пользователи частенько "делятся" своими паролями, для быстрого решения какой то задачи (я в отпуске (в отгуле, на больничном...), зайди, посмотри - на комп, в почту, на портал и т.д.). И никакие административные запреты не помогают. А этот "временно" выданный пароль легко потом может использоваться для доступа к сервисам, к которым доступа то не должно быть.
Но да, часто менять вредно - начинаются пароли вида .... 1, 2, 3 ....
В трудовом договоре есть что-то про разглашение корпоративной информации третьим лицам? Значит надо привлекать, и привлекать жестко, с увольнениями и штрафами. Если юзверьки не способны понять самые простейшие правила информационной безопасности(не запускать непонятные файлы, не пытаться отключить антивирус, не давать свой пароль кому попало) то пускай работают на менее критичной к знаниям должности, например, моют унитазы.
Это теоретически так, а на практике не работает как хочется ИБ, жизнь сложнее. Поэтому лучше сразу закладываться на сценарий, что "пароль передан сознательно" как уже случившийся и подстраховываться другими способами.
Вообще в безоапсности самым слабым звеном является человек, а не технологии (за редким исключением)
Непонятно что изображено на картинке.
Какой метод взлома пароля использовался? Если взлом хеша из серверной бд - то наверное зависит от типа хеша. И типа оборудования на котором взлом производится. А если взлом дистанционный - то нормальный сервер не позволит больше 3 попыток за 3 секунды, а потом кукишь покажет.
Тем разрабам, кто делает на своих сайтах обязательную периодическую смену паролей, надо больно бить по рукам.
Не для всех пользователей смена паролей полезна. Если человек запомнил несколько разных паролей и использует, например, один для малодоверенных сайтов, второй для соцсетей, третий для известных почтовых сервисов, четвертый для платежных систем, пятый для интернет-банкинга, то в таком случае принудительная смена пароля вынудит человека использовать пароль другого целевого назначения, что кратно увеличит вероятность его компроментации.
Один раз выучить пять сложных паролей - это вполне себе посильная задача для обычного человека. А вот периодическая смена только вынуждает либо записывать пароли, либо использовать несколько паролей несистемно. А несистемное использование нескольких паролей может привести к тому, что чел может на каком-нибудь сайте начать вводить их все подряд, потому что забыл, какой именно пароль он использовал здесь. А если этот сайт окажется фишинговым, то он сольет в базу мошенникам все свои пароли.
У меня в компании нет настоящего ISO/CISO. И используется Microsoft single sign-on. И password TTL - 180 дней. И есть запрет на установку "стороннего ПО" (browser plug-in-ы под него подпадают, правда - это никто реально не проверяет). Аутентификация по смарткартам или токенам - не внедрена и, фактически, запрещена.
Мне, как (в прошлом) PSP, это глубоко смешно. На счастье, у меня другие задачи, если компанию сломают - не моя башка полетит.
Я уверен, что 99.999% людей не будут зубрить 5 паролей. Я лично помню только один длинный сложный от менеджера паролей и более я не в состоянии запомнить.
Сижу и пытаюсь понять, как автор получил, что пароль из 7 символов a-z,A-Z,0-9 ломается за 7 секунд. Это $62^7 = 3.5 * 10^{12}$ вариантов. Если система позволяет попытки раз в секунду, то это 111 тысяч лет. Откуда взялись 7 секунд?
Речь об оффлайн брутфорсе хэша пароля. Хэш пароля получается уже в результате атаки на протокол (разнообразие методов атак на протокол в сетях мкрософт), прослушивание трафика в рузультате удавшегося спуфинга и банального слива БД с хэшами пароля веб-приложений по причине наличия логических уязвимостей.
Объясните мне, каким образом длина пароля влияет на уровень защиты, если всё равно сверяется хэш, а не сам пароль? Длина хэша ограничена и хэш длинного пароля может совпадать с хэшем более короткого пароля. Говоря проще, после какого-то определённого значения длина пароля не будет иметь никакого смысла. Или я что-то неверно понимаю?
Зная пароль - злоумышленник может войти куда-то, особенно если пароли везде одинаковые. Зная коллизию - не факт, ибо есть соль, есть разные алгоритмы хеширования, и т. д.
Речь вероятно о поделиях, технологически сопоставимых со школьными лабораторными работами, которые еще не додумались блокировать множественные проваленные попытки аутентификации, и которые можно брутфорсить в лоб. В современной реальности гораздо актуальней уникальность паролей для каждого сайта/сервиса, чем их длина.
Да и вообще в статье проверяется не то, что следовало бы. Проблема частой смены паролей в том, их сложно запомнить. И если гик добавит запись в менеджер паролей, то простой обыватель запишет его на бумажке и приклеит к монитору. Вот - корень проблемы, а не энтропия пароля который завтра нужно придумать.
У популярных функций хеширования размер блока от 256 бит. Это 32 символа.
Можно считать, что разные пароли меньшей длины дадут разные хеши.
Но даже для более длинных паролей коллизия может содержать непечатные символы.
Злоумышленнику проще перебрать 20-ти символьную последовательность, чем 32-х байтовую.
Поэтому, грубо говоря, уровень защиты растет вместе с длиной пароля до длины блока хеша.
Тем не менее авторы делают вывод, что периодическая смена пароля скорее повышает, а не понижает их энтропию, как предполагала NIST.
А дело всего лишь в том, что когда сайт требует сменить пароль юзер считает, что админы сайта зачем-то сильно беспокоятся о безопасности аккаунта юзера, значит и юзеру надо сильнее беспокоиться и поставить пароль сложнее.
Короче, тупо манипуляция.
S@mp1ePas$word
А это вообще-то словарный пароль. Меняй — не меняй буквы на символы.
Я видимо не совсем правильно понял Ваш комментарий. Тогда попробую сформулировать свое мнение так:
Способ 99,(9) взлома паролей исключительно социальный, через людей(и из них 70% это фишинг). Единственная причина смены паролей которая действительно может помочь — это блокировка старых пользователей(например уволившихся)
Способ 99,(9) взлома паролей исключительно социальный
Небольшое уточнение. Число 99 целых и 9 в периоде это буквально ровно 100.
Не примите за личное, но в:
$sl = pow($set, $value);
$entropy = log($sl, 2);нет смысла вычислять степень... школьный курс математики говорит, что логарифм от степени, это произведение степени на логарифм, т.е.
$entropy = $value * log($set, 2);это вас обезопасит от переполнения double в случае с большими числами.
Другой момент, то как вы вычисляете набор символов для энтропии. Первое, preg_match_all вообще не для этого придуман, и вам нужен простой preg_match. Второе, вы очень смело ограничили пароли только латиницей и странным набором спец. символов, словно другие наборы символов не могут быть использованы. Ну и третье, намного проще, и наверно даже правильней, собирать набор по самому паролю, т.е. вычислять просто кол-во уникальных символов в предоставленном пароле, полагая что злоумышленник знает этот набор.
Вот, кстати, тоже задался вопросом: Как правильнее считать энтропию - по словарю или по символам в пароле? Ведь даже при хорошем словаре грубо говоря может получиться пароль чисто символьный и получается, что его энтропия будет ниже? Или хороший генератор паролей просто обязан включать в пароль символи из всех подмножеств словаря?
А разве возможно определить энтропию по одному единственному элементу? Для этого нужно знать всё можество возможных вариантов. Возможно, применение самого термина в данном случае некорректно. Возможно, правильней говорить о сложности подбора пароля или о чём-то подобном. Потому как высокая энтропия не означает, что брутфорс не начнётся именно с Вашего варианта.
Зачем менять надёжный пароль?
А затем. Mail.ru неделю назад прислал письмо типа ваш аккаунт взломан, бла-бла, подтвердите телефон, ваш пароль 15 знаков взломали.
Что ж смотрим варианты пароля:
1. Вообще ненадёжный пароль.
2. «Очень надёжный» пароль
3. Без комментариев
Если есть возможность вызвать представителей mail.ru — ткните их пожалуйста личиком в эту ересь.
Интересно в общем случае, почему против брутфорса не рассматривается использование, что-то типа «динамических паролей», когда например, в зависимости от дня недели и текущего времени к основному паролю нужно по какому-то правилу добавить дополнительную группу символов?
Вопрос безопасникам, а почему не используют такой простой способ усложнения пароля как использование кириллических/национальных символов/Использование всей таблицы Unicod ? Самый простой и самый тупой способ усложнить пароль. Во всех программах перебора паролей кириллические символы попросту отсутствуют.
У Касперского и некоторых свистов такие пароли например можно задавать. Раньше можно было и в сервисах яндекса.
Вопрос безопасникам, а почему не используют такой простой способ усложнения пароля как использование кириллических/национальных символов/Использование всей таблицы Unicod
Потому что так делать - это добавить ну 8 бит энтропии на символ (это если какой-нибудь далекий символ Unicode использовать, который еще набрать надо). Того же можно добиться, просто добавив соответствующее количество символов в латинице.
Почему-то в трёх группах получились очень разные значения "начальной средней энтропии": от 71,88 до 96,05. Наверное, потому что группы были слишком маленькими (10, 9 и 9 человек).
Раз уж у нас мало участников, то интересно было бы хотя бы посмотреть, как качество их паролей менялось со временем. Может, оно уже после первой смены стало выше, а дальше не менялось?
Есть подозрение, что вторую группу "вытянул" один энтузиаст, набравший очень длинный пароль.
Нас, по большому счёту, интересует не средняя энтропия, а минимальная (т.е. прочность самого слабого звена). От неё зависит вероятность того, что кого-то из сотрудников взломают и через его аккаунт доберутся до данных. Герой с длинным паролем - он, конечно, герой, но если рядом с ним сидит сотрудник с паролем "1", то смысла в таком героизме немного.
Зачем менять надёжный пароль? Брутфорс и энтропия