Часто встречаются в интернете таблицы времени подбора паролей от компании Hive Systems, которые публикуются без дополнительных данных о методе их формирования. Соответственно сразу в комментариях к таким публикациям появляются много "критиков", которые спешат поделиться своим мнением о бесполезности этих таблиц. Так возникла идея перевести и опубликовать основные тезисы авторов исследования, на основании которого возникли таблицы.
Авторский перевод
Оригинал
С 2020 года компания Hive Systems проводила исследования, чтобы разработать и представить таблицу времени подбора (брут-форса) паролей.
В 2020 году была впервые опубликована таблица паролей, основанная на данных с сайта www.howsecureismypassword.net (сейчас security.org) и собранная Майком Хэлси, Microsoft MVP. В этой таблице рассматривалась относительная стойкость хешированного пароля к попыткам взлома в зависимости от длины пароля, его сложности, алгоритма хеширования, который использует жертва, и оборудования, которое использует злоумышленник.
В 2022 году компания углубилась в изучение данных и используемого оборудования, чтобы составить более точную картину. Данные в этой таблице основаны на том, сколько времени потребуется обычному хакеру, чтобы взломать хеш пароля с помощью настольного компьютера с топовой видеокартой, а затем сколько времени потребуется организованному преступному хакеру, который использует ресурсы облачных вычислений. Были рассмотрены такие известные провайдеры, как Amazon AWS и Microsoft Azure, а также растущие некорпоративные варианты, где можно арендовать компьютер человека по цене за час.
В 2023 году было обновлено оборудование для взлома до самого современного, включая оборудование от ChatGPT, и выбран более реалистичный набор специальных символов в тестировании. Это повлияло только на самый правый столбец таблицы.
В 2024 году компания проанализировала, какое хеширование (если таковое имело место) наблюдалось при взломе паролей на протяжении многих лет, и, основываясь на последних данных и тенденциях, перешла от предположения MD5 к предположению bcrypt. Для bcrypt были установлены 32 итерации. Остановка на 12x RTX 4090 была вызвана тем, что это по-прежнему лучшая доступная для потребителя аппаратная конфигурация, которая не блокирует запуск инструментов, используемых для перебора паролей. Кроме того, теперь предлагается таблица паролей на нескольких языках!
Каковы различия во времени подбора?
При условии, что используется 8-символьный пароль, рекомендованный NIST, максимальное время, необходимое для взлома случайно сгенерированных 8-символьных хэшей паролей MD5 различной сложности на различном оборудовании, значительно варьируется.
Также, максимальное время, необходимое для взлома случайно сгенерированных 8-символьных хэшей паролей bcrypt, установленных на 32 итерации, различной сложности на различном оборудовании, сильно отличается.
Таким образом, даже при использовании bcrypt, мы говорим максимум о 5 днях, если у вас много денег. Но для большинства бюджетов срок до 12 лет кажется вполне приличным, если вы также меняете пароль и он генерируется случайным образом.
Почему в таблице 2024 года именно bcrypt?
Hive Systems проанализировали утечки данных о паролях с 2007 года по настоящее время, о которых сообщается на сайте HaveIBeenPwned.
Вот как выглядит количество взломанных учётных данных, независимо от источника, по состоянию на апрель 2024 года:
Данные с сайта www.haveibeenpwnd.com
Данные с сайта www.haveibeenpwnd.com
MD5 господствовал в течение многих лет, но bcrypt стал выбиваться в лидеры, начиная с 2020 года.
Такие решения для хранения паролей, как LastPass, 1Password и Bitwarden, используют подход хеширования PBKDF2 с сильным хешем с солью, альтернативным MD5, который называется SHA-256. Даже NIST рекомендует PBKDF2 SHA-256. Но, как мы видим, «в жизни» всё выглядит иначе.
Вскрытые хэши паролей от Dropbox, Ethereum, MyFitnessPal и DataCamp использовали bcrypt вместо функции PBKDF2. Bcrypt также кажется более безопасным вариантом с точки зрения ресурсов, необходимых для его взлома. В результате таблица паролей 2024 Hive Systems основана на мощности 12 графических процессоров RTX 4090 против bcrypt.
Но почему время подбора увеличилось по сравнению с прошлым годом?
В прошлом году Hive Systems использовали MD5 в качестве хэша пароля. Как уже упоминалось ранее, MD5 встречается не так часто при взломах, что, вероятно, означает, что веб-сайты и компании используют его меньше (это хорошо!). Поэтому в этом году они обновили таблицу паролей до bcrypt, который является более надёжным хэшем паролей. Это позволило вернуться к прежнему уровню безопасности, но, вероятно, это не будет продолжаться долго, поскольку вычислительные мощности растут.
В этом году таблица паролей рассчитывается с коэффициентом 32 для bcrypt. И хотя можно сказать: «Это не лучшая отраслевая практика/не рекомендуется OWASP», - то в данных о нарушениях присутствуют свидетельства, указывающие на небезопасные конфигурации и применение хэшей паролей, и этот год не стал исключением! Если в течение следующего года ситуация изменится, Hive Systems обновят методику!
Также стоит отметить, что таблица паролей сфокусирована на идее, что хакер работает в ситуации «черного ящика» и вынужден начинать с нуля, чтобы взломать ваш хэш, чтобы показать «худший случай» или «максимальное время, которое потребуется». Большинство хакеров определяют приоритеты слов и строк символов, над которыми они будут работать в первую очередь, используя радужные таблицы, словарные атаки и ранее украденные хэши. Если ваш пароль был частью другого взлома или использует словарные слова, то ваша таблица паролей выглядит следующим образом:
А как же тот комикс xkcd о парольных фразах?
Во-первых, этот комикс был создан 13 лет назад. График таблицы паролей не дотягивает до количества символов в примере xkcd (25) просто потому, что нужно где-то провести линию с размером изображения для получения статистики по паролям вида 'correcthorsebatterystaple'. Но для любопытных эта таблица и соответствующая статистика выглядят следующим образом:
Предполагая bcrypt на 8 x A100s: 406 нониллионов лет (это очень много нулей!)
Но пароль xkcd - это не случайно сгенерированный пароль. Пассфразы - это строки известных словарных слов. Это означает, что «взлом» займет меньше 14 квадриллионов лет, потому что при выборе комбинаций для взлома мы можем начать с относительно коротких, легко запоминающихся слов! Процесс можно ускорить еще больше, если мы знаем что-нибудь о человеке и можем сосредоточиться на словах из тем, которые, как мы подозреваем, его интересуют. Можно даже сузить круг поиска, зная, какой генератор парольных фраз или набор для игры в кости он использовал. Взлом парольных фраз все равно займет много времени, но не больше, чем взлом полностью случайно сгенерированных строк той же длины. Тем не менее, если парольные фразы позволят вам получить большее количество символов, то преимущества могут перевесить риски.
Более подробную информацию и хорошее объяснение комикса xkcd вы найдёте по ссылке.
Стоит ли доверять LastPass?
Вам следует провести оценку рисков и убедиться, что ваша методика моделирования рисков включает моделирование рисков самих средств контроля безопасности (попробуйте использовать Derive!). Времена, когда можно было спокойно считать, что технология безопасности несет в себе только преимущества и не несет никакого риска, прошли!
Но если у вас нет ресурсов для этого, надежный профессионал в области безопасности Дэниел Мисслер в статье «Моя философия и рекомендации по поводу взлома LastPass» сказал: «Короче говоря, все компании могут быть взломаны, включая такие, как LastPass, и гораздо лучше держать свои самые конфиденциальные активы в крупной компании, которая имеет почти бесконечные ресурсы безопасности для обнаружения и реагирования, когда это неизбежно произойдет», с чем в целом можно согласиться, если нет времени на проведение надлежащей оценки рисков.
Хорошо, но как быть с этими огромными цифрами?
В разных странах, регионах и научных школах используются разные сокращения для цифр. В таблице паролей используются следующие:
Ограничения работы по составлению таблиц времени подбора паролей
Взлом паролей таким способом предполагает, что злоумышленник получил хэш‑дайджест одного или нескольких паролей, как, например, в случаях утечки данных о паролях на HaveIBeenPwned или недавно на LastPass (см. таблицу паролей здесь)!
Подразумеваемая атака предполагает, что MFA не используется или была обойдена. Если вы можете получить доступ к зашифрованной базе данных, как это произошло в случае с LastPass, вам не нужно будет использовать MFA при последующих попытках.
Предполагается, что пароли генерируются случайным образом. Пароли, сгенерированные неслучайным образом, гораздо легче и быстрее взламываются, поскольку люди достаточно предсказуемы. Поэтому временные рамки, указанные в этих таблицах, служат ориентиром для «лучшего случая». Пароли, сгенерированные неслучайным образом, будут взломаны значительно быстрее.
Эти показатели предполагают, что вы используете пароль, который не был частью взлома в прошлом. Злоумышленники будут пробовать хэши всех распространенных и взломанных паролей, прежде чем пытаться взломать новые.
Вспомните, насколько масштабным был взлом LastPass. Были украдены секреты 30 миллионов клиентов. Но на момент публикации этой статьи вы не найдете информацию о взломе LastPass в HaveIBeenPwned. Почему? Да потому, что все эти пароли еще не стали достоянием общественности! Представьте себе, сколько украденных секретов и уязвимостей никогда не попадают на свет или даже в темную паутину. Я бы предположил, что сохранение секретов в тайне дает преступникам больше рычагов и власти, чем их раскрытие.
По умолчанию Hashcat использует 999 итераций для PBKDF2 SHA-256, но это не соответствует тому, что используют люди. NIST рекомендует минимум 10 000 итераций, а такие сайты, как LastPass (сейчас), используют 600 000, а 1password - 650 000 итераций.
Перебор комбинаций символов - это только один шаг к «взлому». Второй шаг - поиск совпадений между хэшированными строками и набором данных хэшированных паролей. Мы предполагаем, что этот поиск требует незначительного количества дополнительных вычислений и времени.
Взломы паролей, попавшие в HaveIBeenPwned, могут не соответствовать реальности. Может существовать предвзятость отбора и выживания, отсеивающая случаи до того, как они попадут туда. Например, у LastPass был большой и страшный взлом, но они не попали в HIBP, потому что фактические данные не были опубликованы публично. Возможно, когда люди используют достаточно сильное шифрование, они не стремятся делиться или продавать набор данных, потому что никто не купит его или не потрудится его взломать.
В предыдущих выпусках таблицы мы включали все символы QWERTY-клавиатуры, но в этом году мы остановились на наборе, который обычно используется на большинстве веб-сайтов и генерируется большинством генераторов паролей ^*%$!&@# . Этот выбор повлиял только на самый правый столбец наших таблиц. Другими словами, мы исключили символы, зачеркнутые в следующей таблице:
Ссылки
Контрольные значения количества хэшей в секунду (H/s) были либо сгенерированы Hive Systems с помощью hashcat на локальном оборудовании или в облаке, либо взяты из результатов поиска по Github repo/gist, содержащих чужие результаты работы hashcat (например, https://github.com/search?q=hashcat+benchmark).
Технические характеристики GPU мы получали от производителя или с сайта.
Комментарии (147)
NikaLapka
04.05.2024 06:44+4Ну сколько можно, из раза в раз писать про большие, маленькие, символы в 8-12 символьных паролях, пора бы уже просто написать, что любой пароль в 8 символов - скомпрометирован и закрыть тему. Пароль в 12 символов - мало надёжен. И рассматривать уже действительно интересные решение, например, из вашей таблички следует, что пароль в виде 10371202471119117211 более чем надёжен, а ведь я просто взял два номера телефона и первую цифру заменил на 1..
TVExpert
04.05.2024 06:44+14Тут вот какой момент ещё встречается...
Есть аппаратура (вполне современная), у которой возможность использовать пароль больше 8 знаков есть, но это приводит к "странностям" в работе.
Реально...
Сталкивался не раз, методом "научного тыка" пришёл к выводу "да ну на*ер!!!" (сброс до дефолтных = работает, ставишь пароль не с самого начала работы с железом, а уже в конце и хисторирепитинг...)
Смог пройти через кучу бестолковых "саппортников" (благо есть свои тропинки), и в итоге получить от более сведущих инженеров подтверждение, что "ну да, есть такое...".
А ведь в моей старой привычке менять заводской пароль на 12 значный (просто большие и маленькие буквы, БЕЗ спец символов, от которых у FW вообще бывает что крышу сносит).
P.S.
Пользуясь случаем (С) :)
Немного прорекламирую/посоветую ресурс passgen.ru но больше в попытке достучаться до владельцев этого несомненно полезного ресурса.
Пробовал связаться с ними несколько раз, для одной мелкой "рацухи".
Господа, введите PLS! ещё один фильтр в ограничение генерации !
"Исключить использование схожих по написанию/отображению символов"
(речь как минимум про про O0, IiLl)
Ну не вся техника в своих меню показывает их РАЗНЫМИ, а когда у тебя нет возможности копипастить, то вводить уже упомянутые 12 символьные пароли, особенно на 10-20-30 устройств подряд (все разные), становится тем ещё квестом.
ДА, вынужденно выбираю из сгененрированного списка вариантов, пароли с отсутствием таких символов, но это не дело...
СПАСИБО ! :)
tandzan
04.05.2024 06:44+7
Вот такой генератор давно накатал в приступе паранойи, похожие символы отсекаются одной галочкой, и сразу можно оценить количество бит для перебора.
TVExpert
04.05.2024 06:44+1To: tandzan - ВесчЪ !
Посмотрите ещё в сторону добавления фунционала генерации списка (на несколько экз.)
Например у меня, из профильного, это подготовка оборудования для монтажа на объектах. (это и горячий прогон+тестирование+проверка, и избежать потери времени на самом выезде/монтаже).
Для этого обычно заранее создаётся Excel таблица, в которой сразу и делается распределение IP + ID + прописываются MAC(и) и т.п. log/pass (+ ещё "по мелочи").
Необходимых генераций набегает заметно...
Даже на самый простой объект, условно на небольшой магазинчик о 16 камерах, надо:16 паролей для камер
1+х паролей для пользователей NVR (admin+user_N)
1 пароль для роутера
какое то кол-во pass для Wi-Fi (разным пользователям/группам разные учётки, QoS)
Опционально, ещё встречается необходимость генерации списка pass для удалённого входа на то или иное оборудование/софт.
Вот и набегает :)
P.S.
Было бы шикарно, предусмотреть ещё и вариант не "единичной" копипасты, а сразу столбца (для переноса в Excel таблицу).
Но это уже сложнее, через что-то csv подобное (?)
P.P.S.
Иконку/кнопку копипасты, удобнее пользовать если она находится сразу после строки с символами.
Да и про "модную" ситуацию с символом пробела в конце, тоже, желательно учесть :)
Lordbander
04.05.2024 06:44+1Ты устраиваешь заказчику жуткий геморрой. Ты работаешь в пуско-наладке. Твоя задача сдать работающую систему заказчику и отдать пароли. ВСЕ. Дальше Заказчик меняет пароль от админки системы и в идеале, через "программу для массовой конфигурации камер" пароли на камеры. Он должен на 1000 камер сделать это в идеале по 1 клику, а не по Excel таблице, каждой камере менять.
Подобрать нереально. Блок на 5 минут после 5 фейлов. Да и пароль обязателен не меньше 8 символов с Регистром и спецсимволами.
И при том, что у меня был сотрудник, который обиделся и его уволили, перед увольнением поменял пароли на 800 камер (да одним кликом, но была б у него табличка Excel, заняло бы у него часа 3).
Знал старый пароль от камер, довольно простой - это для настройки и сдачи. Но чел, тоже не дурак, классический логический перебор не удался. Брутфорс на камерах - никак.
Если честно, то и тема взлома паролей, даже по ХЕШ. У меня на домашнем маршрутизаторе вай-фай пароль 12345543218899. Вот взломает его кто?
TVExpert
04.05.2024 06:44+2Какие то взаимоисключающие и противоречивые условия получились :) (но в реальности встречаются и не такие выкрутасы).
1. Если у заказчика есть свои сильные айтишники, то пусть он сам строит систему.2.Если у него их нет, а есть "эникейщики", то качественная работа системы/оборудования в течении гарантийного срока как раз таки и обеспечивается "изоляцией" доступа к настройкам от таких посторонних, которые своими шаловливыми ручками могут наворотить такое, что бывает потом дольше разбираться, чем сбросить и настроить всё по новой (если без рабочих бэкапов).
(это как вариант).3. Про "одним кликом сменить все пароли" - м.б. где-то и актуально (по определённым сценариям), но довольно узкопрофильно и небезопасно. Причины уже описаны сразу, в вашем же комментарии.
Клиент/заказчик имеет предоставленный ему набор пользовательских паролей к регистратору/серверу.
Необходимые отделы/сотрудники разделены своими учётками, каждая даёт разные уровни доступа. Любая из них удаляется/добавляется при увольнении этого сотрудника (не затрагивая работу других).
Камеры сидят под админскими учётками, в некоторых случаях добавляются сервисные (для прописывания в регистраторы/серверы, примерно с такими же целями как и "пользовательские").
Вариант доступа к видео/звуку (через Onvif) блокируется в самих камерах, благо такая дыра уже пофиксена у многих нормальных производителей.
Все вопросы по ограничению/регуляции доступа решаются комплексно, а не "местами так, местами сяк".
P.S.
Способов "положить" всю систему видеонаблюдения предостаточно, особенно если давать к ней доступ посторонним. Или обижать тех, кто её грамотно создавал и полноценно обслуживал.
Отчасти поэтому, у стабильно работающих "установщиков" (любого масштаба), есть своя репутация и круг клиентов, с которыми они идут рука об руку много лет.
Ровно как и наоборот - среди профильных контор, есть "чёрный список" клиентов, с которыми связываться - себе дороже.Lordbander
04.05.2024 06:44Вот скажите. У Вас на объекте 500-1000 камер. И тут заказчик говорит, что-то нагрузка сильная, поменяй пожалуйста GOP на 10, Второй поток до 320. Вы будете в каждую камеру стучаться и менять настройку?
Посмотрите на новые версии Macroscope. Там можно в 1 клик добавить 254 камеры (ограничение в IP диапазоне) (Они вроде первые, на моей практике добавили оптовое добавление). Я добавил камеры, и они СРАЗУ работаю. Мне не надо копипастить на каждую камеру пароль.
Грамотные IT обычно больше вредят. Пробиться через их Доменные настройки и Антивирусы, это ад. Все порты перекрыты. При том, система безопасности обычно - изолированная сеть, с максимум, доступом по VPN но каждому свое.
Если сданную систему отдают Эникейщикам - ну дэк - Бэкапы никто не отменял, и просто у тебя появляется дополнительная оплачиваемая работа.
По поводу ограничения прав доступа, нет, ну тут и так все понятно. Каждому клиенту свое - тут спору нет, с ограничениями и т.п. Но админские пароли Вы же все равно передает? А как заказчик ими распорядится?
TVExpert
04.05.2024 06:44+1И тут заказчик говорит, что-то нагрузка сильная, поменяй пожалуйста GOP на 10, Второй поток до 320. Вы будете в каждую камеру стучаться и менять настройку?
Ситуации разные бывают, но мне как-то привычнее изначально грамотное проектирование (по крайней мере для моих ситуаций).
- h.265+ давно стало доступным. (битрейт на среднем сюжете для 5Мп камеры пляшет вокруг 250-300 кбс, максимум 1-1,2 мбс)
Ну пусть пиково 1,5-2 мбс для людных мест с пёстрым антуражем.Хотя...
Допускаю, что есть места где минимально (но массово) нужны 8Мп с полными 25(30) FPS, ну пусть там ситуация раскачивается до 5+ мб/с. Но ведь это не совсем уж массовая ситуация...
- зажимать FPS (и "соседние" параметры) до реально нужного для каждого направления/сюжета.
- учитывать суммарный битрейт сегмента до первого коммутатора (естественно с запасом). Причём применять проверенные коммутаторы, без особого доверия маркетологам производителя оных.
- учитывать архитектуру/особенность кольца или общей шины до регистратора(ов) сервера (обычные впрочем моменты)- при необходимости играть с CBR/VBR для каждой камеры изначально
- само-собой, отдельная CCTV сеть (без гибридизации под всякие 1С/офисные нужды).
- использовать монобренд, на котором (например) используется свой внутренний протокол связи IPC c NVR(сервером) (без зоопарка и костылей разных версий Onvif).
И благодаря этому, НЕ НАДО лазить на каждую камеру в отдельности - достаточно выставить нужные настройки на NVR/сервере (а он уже сам "донесёт до понимания").
Грамотные IT обычно больше вредят. Пробиться через их Доменные настройки и Антивирусы, это ад. Все порты перекрыты. При том, система безопасности обычно - изолированная сеть, с максимум, доступом по VPN но каждому свое.
Это извечный спор :)
Сейчас много заказчиков, кто по ТЗ требует использования коммутаторов с поддержкой 802.1х (даже для внутренней сети без возможности прямого доступа к кабелям/коммутации)
Тут уже другая консерватория, сейчас речь чуть про другое.Если сданную систему отдают Эникейщикам - ну дэк - Бэкапы никто не отменял, и просто у тебя появляется дополнительная оплачиваемая работа.
я про это сразу обозначил, полностью (просто посмотрите чуть внимательнее)
По поводу ограничения прав доступа, нет, ну тут и так все понятно. Каждому клиенту свое - тут спору нет, с ограничениями и т.п. Но админские пароли Вы же все равно передает? А как заказчик ими распорядится?
Тоже написал ранее.
Всё индивидуально и по ситуации.
- Если хотят гарантии, то админка у монтажной организации до окончания срока гарантии.
- Продление гарантии = админка продолжает находится у "монтажников".
- Клиент хочет получить полный доступ = клиенту демонстрируется полноценная работа, в момент передачи админки гарантия снимается.
meettya
04.05.2024 06:44+1Поднимите себе vaultwarden личный, если очень хочется - с доступом через vlan, там все есть.
TVExpert
04.05.2024 06:44+1На мой взгляд, это уже усложнение... (но кому как)
Для своих задач обкатал другой способ - создание Excel таблицы с внесением в неё необходимых данных по всему "своему" железу.
Если по каким то причинам с клиентом сотрудничество дальше не планируется, то после окончания гарантии ему отдаётся распечатка и всё.
Для особо "щепетильных", после сдачи объекта в эксплуатацию делается распечатка и убирается в "сетку"+фольгу а затем в опломбированный конверт.
Если на объекте (во время гарантийных сроков) что-то пошло "не так", первым делом проверяется этот "пакет под сургучом".
Вскрыт = одна цена восстановления (или "копошитесь сами").
Целый = работаем штатно. (по согласованным ранее условиям).
mizugoji
04.05.2024 06:44делается распечатка и убирается в "сетку"
а что за сетка?
Целый = работаем штатно. (по согласованным ранее условиям).
конверт может быть целым, а где гарантия что на вашем компьютере не живёт уже как пол года бекдор или ещё более совершенный аналог?
ShashkovS
04.05.2024 06:44+5Вот есть моя реализация:
https://shashkovs.ru/p/
TVExpert
04.05.2024 06:44+1To: ShashkovS
Недурно !
Утащил в закладки, однозначно. (по нынешним временам звучит кхм...) :)
На "свежий взгляд" [возможно тоже думали, но сомневались (?)].
- схожие по начертанию символы
(внешнему виду / отображению)- немного "дисс" по маленькие/заглавные (маленькие/большие, прописные/заглавные)
- Пароли готовы / Варианты паролей (готовы это больше кулинария + "утверждение")
- не силён в WEB/HTML, но хотелось бы иметь возможность "чистой" копипасты (паролей) для переноса, например в таблицу Excel, сейчас, мышкой получается тащить только с нумерацией строк.
Есть ещё (личное мнение) по взаиморасположению элементов на экране, но это личные "придирки".
Это уже больше на уровне "отдельная кнопка для копирования" (в конце поля пароля), возможно с индикацией "уже скопировано".
Плюс, возможно отдельную кнопку "скопировать ВСЕ"
Может быть (надо смотреть), не одну общую строку для всех символов, а отдельные, после раздельных же "условий":
маленькие_[_____________]
БОЛЬШИЕ_[_____________]
Цифры _ [_____________]
Спец.символы _[_____________]
Сейчас, с непривычки, глаза начинают "спотыкаться".
P.S.
Про символ единицы не задумывался, но скорее всего соглашусь.ShashkovS
04.05.2024 06:44+3Да, это всё можно подкрутить, совсем несложно. Там кода — 10 строк js и 10 строк html.
Про удобное копирование даже задумывался.Давайте так: если моё сообщение выше наберёт 10+ «лайков», то выделю время и прикручу :)
TVExpert
04.05.2024 06:44+1По возможным "алаверды" я уже отметился :) (не только за комментарий)
Какие-то сугубо свои "хотелки" обозначил, из "дальнесрочных" хотелось бы какой то простой способ (для памяти) попадания на страницу с генератором (у парней из passgen.ru это работает).
Если "шлифануть в идеал", то можно и отдельный сайт, хостинг сейчас недорогой (у многих есть свободные лоты от провайдера). У меня например из 5 предложенных по тарифному плану, заняты только 3.
Как минимум могу разместить иконку/ссылку в планируемых у себя "полезняшках" (но это планы).
unC0Rr
04.05.2024 06:44+1Стоит также добавить проверку, чтобы обязательно в пароль попало как минимум по одному символу из каждой выбранной категории.
Fedorkov
04.05.2024 06:44А я 20 лет назад (ещё в школе) написал на Boland C++ программу и тоже назвал её PassGen.
Она собирает статистику по корпусу текста (я обучал её на Толкиене), а потом за каждой буквой случайно выбирает следующую в соответствии с этой статистикой. В итоге получается легкозапоминаемая бессмыслица. Для большей англоподобности пароли составляются задом наперёд, потому что окончания в английском гораздо более однообразны, чем начала слов.
TVExpert
04.05.2024 06:44Заинтриговали :)
Примеры в студию ! (С)
Нечто стилистически схожее, сравнительно недавно предлагала одна компания, но в теме "шифрования" GPS координат для каких-либо "аварийных" ситуаций.
Там изюминка была в том, что при возникновении "как то жарко стало", человек открывал например на смартфоне приложение, приложение смотрело координаты, и на их основе генерировало нечто "читаемое" (на слух и удобство голосовой связи).
На другой стороне канала (условно спасатели или доверенное лицо) переданная фраза вводилась в такое же приложение, и после "дешифровки" появлялся квадрат поиска с вполне удобно/приемлимыми "контурами" (периметром).
P.S.
Речь не идёт про места с устойчивой сотовой связью, акцент/больше для классической радиосвязи, где не скопипастить и не заскриншотить.Fedorkov
04.05.2024 06:44
Только сейчас заметил, что многие пароли напоминают причудливые имена из Сильмариллиона.
JordanCpp
04.05.2024 06:44+14Только олды знают как должен выглядеть идеальный пароль: DYB3T-F2QYQ-9CRXR-DBC4V-CC4YG
drsmoll
04.05.2024 06:44+32этот лучше знают: J3QQ4-H7H2V-2HCH4-M3HK8-6M8VW и звучит как песня.
micronull
04.05.2024 06:44+8Забавно, что ваш и @JordanCppбез символа "-" скомпрометированы судя по https://haveibeenpwned.com/Passwords. C "-" утечек пока не было) Можно пользоваться.
feelamee
04.05.2024 06:44+9а где у хакеров есть возможность перебирать миллионы паролей в секунду?
Либо я чего-то не понимаю, но большинство сайтов просто не позволит так делать. Это не говоря уже о том, что просто дождаться пока пароль валидируется, это уже миллисекунды. Но тут, конечно, можно в параллель.
anayks
04.05.2024 06:44+3Современные возможности проксей и их низкая стоимость позволяют создавать атаку, которую тяжело завалидировать каким-то образом и запретить это делать. В случае эппл, например, был прикол с тем, что, когда кто-то брутфорсил пароль с множества разных IP, они (эппл) блокировали аутентификацию конкретной учетной записи и в итоге от этого страдал обычный пользователь — владелец учетной записи. Тут дилемма и сразу не одна — как грамотно обеспечить безопасность этому.
ABRogov
04.05.2024 06:44+5Интересно, почему тяжело завалидировать, ведь обращение идет к одному аккаунту? Что мешает ничего не блокировать, просто проверять не чаще раза в секунду?
ainoneko
04.05.2024 06:44+6Это будет _почти_блокировка аккаунта: из 10000 попыток в секунду пользовательская будет одна -- и скорее всего (99.99%) проверяться не будет.
Kanut
04.05.2024 06:44+8Это если пользователь пытается зайти в тот самый момент когда кто-то брутфорсит именно его пароль.
И в общем-то не плохо будет если пользователь в такой ситуации увидит ошибку а ля "слишком много попыток ввода пароля".
xSVPx
04.05.2024 06:44+8Вместо "ваш счет за ресторан оплачен"?
Совершенно не уверен, что лучше. В целом это даст возможность парализовать навсегда любую жертву. Просто будут слать запросы на авторизацию нонстоп и ваш айфон превратится в кирпич.
А это довольно просто и дешево. К сожалению.
PS. Насколько я понимаю речь не о подборе пароля, а о его получения из украденного хеша. Хеш добыть проще.
Kanut
04.05.2024 06:44+3Вместо "ваш счет за ресторан оплачен"?
Если мы говорим о относительно "критических" вещах вроде денег, то на мой взгляд там всё равно нельзя полагаться на один только пароль. То есть нужно минимум два фактора.
Просто будут слать запросы на авторизацию
Пароль это не единственный способ авторизации. То есть можно добавить какой-то "запасной" механизм, который работает по другому принципу.
Ну и вообще на мой взгляд логичнее всего в случае подозрения на брутфорс просто ограничивать скорость повторов. Даже банально если сделать одну попытку в секунду, то брутфорс становится не особо оптимальным вариантом.
Плюс можно смотреть на ip и блокировать только частые повторы с одного и того же. Что опять же усложнит жизнь мошенникам.
Плюс можно "запоминать" девайсы и давать известным девайсам приоритет по сравнению с незнакомыми.
И так далее и тому подобное.
Proscrito
04.05.2024 06:44+4Это просто и дешево для чего? Чтобы подгадить кому-то лично, не давая залогиниться в эпл айди? С трудом представляю мотивацию даже бесплатно этим заниматься, не говоря о каких-то распределенных атаках.
Тем более "окирпичить" айфон не выйдет таким образом, да и любой телефон. Пока вроде бы инет не нужен, чтоб телефон работал. О каком логине речь? Биометрия или фейс айди прямо в телефоне, у айфона даже отдельный чип для шифрования, вы можете всегда зайти в телефон даже если связи нет. И даже когда вы подтверждаете какую-то покупку, вы логинитесь в телефон, а не куда-то на сервер. Если введете пароль в телефон 10 раз неверно, тогда он превратится в кирпич. В самом прямом смысле слова, помочь вам сможет только техподдержка, которой надо отправить телефон физически, и набор документов подтверждающих личность и покупку. И подождать от 3 до 6 месяцев.
Если говорить не про айфон, а про рандомную веб-морду чего-либо, то брутфорсить пароль отправляя запросы на сервер на сегодня может прийти в голову только мамонту, пролежавшему во льдах всю компьютерную эпоху. Это имеет ровно ноль шансов, даже если у вас пароль кверти123. Учитывая время на проверку скорость перебора будет на порядки ниже, чем та что заложена в таблицах из статьи. А сам процесс вопиюще палевный, его пресекут на корню, а жертва будет предупреждена, что на нее идет атака.
Написанное в статье имеет смысл только для украденного хэша, когда он в руках хакера. Иначе никаких таблиц построить не выйдет. Все системы сегодня имеют защиту от брутфорса, а если где-то появляются уязвимости, то это случай из ряда вон с очень индивидуальным сценарием и метриками. Вот базы юзверей сливают регулярно тут и там, человеческий фактор, или корпоративная уязвимость и привет, 100500 тыщ аккаунтов утекли в даркнет, вполне вероятно с хэшами паролей.
saboteur_kiev
04.05.2024 06:44PS. Насколько я понимаю речь не о подборе пароля, а о его получения из украденного хеша. Хеш добыть проще.
Получить хеш проще чем подобрать пароль к хешу?
Это где такие уязвимости, что хеши просто разложены, бери не хочу?unC0Rr
04.05.2024 06:44+2Так постоянно всякие базы утекают.
saboteur_kiev
04.05.2024 06:44Если база утекла, вряд ли будет особый смысл в длинных паролях..
Lex98
04.05.2024 06:44+1Как раз весь смысл хеширования паролей (и соли) в том, что даже если база утекла нельзя было эти пароли получить. Точнее можно было, но (на текущем железе) это занимало бы миллиарды лет. Самый простой пример: пароли из одной цифры. Есть всего 10 вариантов, тут ни соль не поможет (слишком мало вариантов, можно быстро проверить все варианты с заданной солью), ни криптографические хеш-функции (если хеш-функция работает адекватное время для проверки одного пароля, то для 10 вариантов она тоже работает за небольшое время). А вот если пароли состоят из 100 цифр, то это уже 10^100, такое уже при всем желании (с использованием всех вычислительных мощностей планеты) не получится, вариантов слишком много. За этим и нужно и использовать длинные пароли (увеличиваем количество вариантов), и использовать медленные и затратные по памяти хеш-функции (увеличиваем время (или стоимость в деньгах) проверки одного варианта), и соль (чтобы нельзя было 1 раз предпосчитать все варианты до длины n и переиспользывать).
larasage
04.05.2024 06:44+1Это при условии, что хэш пароля из 100 цифр не совпадет с хешем пароля из например 2 цифр
Lex98
04.05.2024 06:44Для современных криптографических хеш-функций найти коллизию сложнее, чем подобрать пароль адекватной длины. Для Argon2 нужно перебрать 2^256 вариантов. Это, конечно, не 10^100, но 10^77 тоже неплохо.
anayks
04.05.2024 06:44И сможет все равно привнести некоторый вред даже не через достижение цели как "получение пароля" - а просто кто-нибудь будет дурачиться и блокировать кому-нибудь доступ к аутентификации.
Да, Ваше решение хорошее, но у него всего равно есть подводные камни.
Так, например, в играх была одна из интересных атак, когда с помощью множества проксей создавалось подключение под определенным псевдоним к серверу, занимая некоторый слот этого псевдонима, и игрок так же не мог зайти под этим псевдонимом, потому что слот его псевдонима был занят. И так могли делать на протяжении множества суток, создавая бесконечные переподключения.
Так вот, такое же может произойти соответственно с рядовым пользователем, если кто-то на него просто поставит не то чтобы буртфорс, а просто ддос на его псевдоним бесконечный (с учетом 1 запроса в секунду, это обойдется вообще не дорого, даже дешевле, если просто брутфорсить).
Всё сводится в итоге к тому, что самый оптимальный вариант - это повышение сложности пароля, чтобы не создавать такие лимитеры (то есть, чтобы и пользователю было удобно, и было безопасно).
Лимитеры, естественно, должны быть, но в разумных рамках.
Лимитер на аккаунт для аутентификации, имхо, не самый оптимальный вариант.anayks
04.05.2024 06:44+1Но я так же могу быть не прав, признаю.
Например, был момент, когда был брутфорс у Apple, суть которого заключалась в подборе 6-значного кода из цифр для авторизации. И у них не было лимитера корректного. Точнее он был - ограничение по запросам по IP и на аккаунт (вроде как 3 запроса) - но была некоторая неполадка в синхронизации лимитера, из-за чего можно было подобрать этот "пароль", отправив одновременно множество запросов в единицу времени с разных проксей.
Можно поискать эту статью на хабре, если конечно Apple не попросила её удалить (потому что другие статьи удалены на подобные темы).
UPD: При этом, когда лимитер отрабатывал как надо - он блокировал доступ реальному пользователю, это тоже было забавно. В итоге, пользователь терял на сутки по-моему доступ к восстановлению аккаунта или к авторизации - точно уже не помню.
olku
04.05.2024 06:44+5Есть дешёвый способ - отдавать ответ медленно. Человеку секунда туда, секунда сюда, без разницы.
Kanut
04.05.2024 06:44Куча сайтов делаю ещё проще. Ошибся три раза: жди 30 секунд пока сможешь снова попробовать. Ошибся ещё 5 раз: жди минуту. И так далее.
gimcnuk
04.05.2024 06:44Все сервера обрабатывают запросы параллельно. 10.000 одновременных всё равно займут секунду. Без учёта пропускной способности.
olku
04.05.2024 06:44Конечно, но непараллельный перебор значительно замедлится. Если против сервиса поднимают 10К ботов, значит ставки чуть иные, 1 строка с паузой для скрипт кидди не спасет.
Rsa97
04.05.2024 06:44Не факт, что к одному аккаунту. Один из методов брутфорса по таблице паролей - проверка одного пароля из таблицы сразу для многих аккаунтов. В этом случае обращения к каждому конкретному аккаунту достаточно редкие.
saboteur_kiev
04.05.2024 06:44Каким образом прокси позволят логиниться с тем же самым логином?
anayks
04.05.2024 06:44+2Прокси позволяет не залогиниться под тем же логином, а обойти рейт-лимит по определенному IP-адресу на запрос авторизации, чтобы заняться брутфорсом.
В то же время, если блокировать конкретно аккаунт, можно просто довести аккаунт до перманентного блокирования, это я описал уже (и не только я)
pae174
04.05.2024 06:44+15а где у хакеров есть возможность перебирать миллионы паролей в секунду?
Во всех подобных статьях под взломом пароля понимается попытка взлома утекшей базы хэшей. Сетевые задержки и ограничения на сервере в таком случае неприменимы.
mefepe
04.05.2024 06:44+2Это в случае, когда злоумышленник получил доступ к бд с хешами. То есть максимально плохой сценарий - ограничений на число итераций нет, задержки нет, оборудование для взлома под рукой.
pix_l
04.05.2024 06:44В принципе, брутфорсить учётку в онлайн никто и не будет. Посредством инъекций и разного рода ддоса, атакуется сайт. Сливается база с хэшами паролей и вот с ними уже можно работать оффлайн сколько душе угодно.
tbp2k5
04.05.2024 06:44+2Поправьте меня, но никто хеши публично не выкладывает. Соответственно получение хешей и есть взлом. То что представлено в данной статье - это скорее расчет времени которое остается у компании для реакции на инцидент с кражей хешей.
ImagineTables
04.05.2024 06:44+4Если бы хеши никогда не утекали, зачем бы они вообще были нужны? Можно было бы тупо хранить пароли. Все эти системы проектируют из предположения об утечках (и хешей, и всех алгоритмов) для минимизации вреда от них.
tbp2k5
04.05.2024 06:44> Если бы хеши никогда не утекали, зачем бы они вообще были нужны?
Ну например для того чтобы админы/девелоперы (аппликации, базы данных, бекапа) тоже не имели простого доступа к паролям. Или вам кажется что обычный админ с его обычными ресурсами будет ждать 100 лет для взлома 8 символьного пароля из чистого любопытства ?
ImagineTables
04.05.2024 06:44+3Это разновидность утечки.
tbp2k5
04.05.2024 06:44+3Мне, как пользователю, не принципиально как вы классифицируете инциденты безопасности. Мне важно чтобы мой пароль был недоступен в любом разумном сценарии - современные алгоритмы это обеспечивают.
Беда всех этих табличек со временем взлома - в том что с ними носятся безопасники или начальство которое не понимает банальных вещей:
подбор 8-символьного пароля через SSH (убираем все ограничители) или типичную веб-службу займет эдак лет 30000. Допускаю что поработав как следует вы оптимизируете на взлом за 3 столетия - не принципиально
поиск коллизии (подбор пароля любой длинны) по утекшему древнему хешу - фактически всегда мгновенный
Вывод (мой): бессмысленно морочить голову пользователям требуя сложный и длинный пароль - делайте нормальный бекофис (например PBKDF2), не допускайте утечек, а если утекло - меняйте все пароли.
ImagineTables
04.05.2024 06:44+5Мне важно чтобы мой пароль был недоступен в любом разумном сценарии
Именно для этого и разумно заранее считать хеши утёкшими. И делать так, чтобы утёкшие хеши не означали утекание паролей. Полагаться на то, что хеши не утекут, это… ну, не security through obscurity, но из той же области.
tbp2k5
04.05.2024 06:44Вы фундаментально ошибаетесь допуская принятие утечки как данность:
Хороших алгоритмов для хеширования единицы. Криптография - сложная наука и при попытке изобрести свой велосипед вы точно будете в зоне риска. А для извесных алгоритмов есть радужные таблицы или суррогаты основаные на той же идее.
Скорость поиска коллизии можно увеличивать практически до бесконечности (распараллеливать на все доступные ресурсы, специализирование ASICи, и.т.д.) да к тому-же все это можно делать незаметно для жертвы.
Не ленитесь: сегодня утечка хешей практичеки такая-же катастрофа как утечка паролей в чистом виде. Тот что лично вы не можете подобрать пароль от хеша не значит что у американского NSA, китайского SSM или достаточно крупное предприятие это хоть немного задержит. А с другой стороны, даже ваш домашний SSH (или другой сервис) все эти уважаемые организации смогут брутфорсить со скоростью, в лучшем случае, тысячи попыток в секунду. И париться они над этим будут не одно столетие.
ImagineTables
04.05.2024 06:44Вы фундаментально ошибаетесь допуская принятие утечки как данность
Тогда ответьте на один простой вопрос: в чём смысл существования хешей? Raison d'être, тысызыть?
Мне старшие товарищи в своё время так объяснили, почему они вслед за всем миром перешли от хранения паролей к хранению хешей: чтобы можно было не бояться, что при угоне базы утекут пароли.
tbp2k5
04.05.2024 06:44Я застал ту эпоху.
1) Основное: не допустить чтобы амин/девелопер мог по быстрому подсмотреть чужой пароль да и поправить чтонибуть себе или попросившей его подружке.
2) Убрать проблему "неприличных" паролей которые могли ранить тонкую психику админов. Было и такое :-)
И поначалу (до появления NVidia с CUDAой) коллизию реально трудно было найти - давным давно - это действительно защищало...
morijndael
04.05.2024 06:44+1Админ/девелопер может просто записать в базу хеш своего пароля, и залогиниться. Если есть админский доступ к базе, узнавать изначальный пароль не требуется
tbp2k5
04.05.2024 06:44Разного порядка риски: одно дело подсказать подружке пароль ее начальницы (и поди докажи откуда она его узнала), а другое - апдетить запись. Во первых не факт что обычный админ/девелопер сможет обновить хаш (при правильном дизайне - не сможет). Во вторых апдейт оставит всякие прямые и косвенные следы (время обновления, логи, бекапы, и т.д.)
askharitonov
04.05.2024 06:44+2А для извесных алгоритмов есть радужные таблицы или суррогаты основаные на той же идее
Так против радужных таблиц хорошо помогает соль. Для каждого пароля берём случайную строку символов большой длины (соль), добавляем её к паролю в конец, считаем хеш и сохраняем его значение и соль в таблицу. При проверке пароля тоже добавляем к паролю соль для этого пользователя, считаем хеш и сравниваем с сохранённым.
tbp2k5
04.05.2024 06:44Это все правда, но не вся правда: соль просто сильно увеличивает стоимость взлома.
При утечке утечет и хеш и соль: взломщик может практически до бесконечно распаралеливать поиск колизии. Просто, для примера, посмотрите в статье скорость поиска для bcrypt (он использует соль).
Lex98
04.05.2024 06:44+1соль просто сильно увеличивает стоимость взлома
Ну да, сочетание длинного пароля, соли и ресурсоемкого хеша увеличивает эту стоимость до такой, что даже 1 пароль нельзя взломать используя все вычислительные мощности планеты (по крайней мере те, о которых известно) за миллиарды лет. Мне кажется это достаточно хорошо гарантирует сохранность пароля даже при утекших хешах с солью.
kbnrjlvfrfrf
04.05.2024 06:44+1Соль предназначена для предотвращения взлома хэшей "широким бреднем", а не для "скорости". Т.е. вы утащили базу с 100500 млн. хэшей, зарядили брут и сверяете очередную комбинацию со всеми 100500 млн. аккаунтов. Засоленный пароль спасает от этого.
Lex98
04.05.2024 06:44Ну так это и есть скорость. И комбинация длинного пароля, соли и ресурсоемкого хеша делает невозможным как взлом конкретного пароля, так и создание радужных таблиц для перебора сразу всех.
askharitonov
04.05.2024 06:44+2Ещё соль не даёт использовать радужные таблицы. Не получится предварительно один раз вычислить хеши паролей на очень быстром компьютере (и сохранить их в относительно компактной форме) и потом эту информацию использовать для взлома на более медленных компьютерах, потому что невозможно создать радужные таблицы для всех вариантов с достаточно длинной солью.
Lex98
04.05.2024 06:44Скорость поиска коллизии можно увеличивать практически до бесконечности
Как раз скорость поиска очень даже ограничена (вычислительными мощностями всей планеты), а вот сложность пароля практически не ограничена. Сейчас будет сравнение апельсинов с карьерным самосвалом, но для увеличения скорости подбора в 2 раза надо либо в 2 раза больше железа (что дорого), либо ждать несколько лет пока индустрия выпустит новое, более мощное (или более эффективное в производительности за рубль) железо. А время подбора можно увеличить в n раз (n - размер словаря) просто добавив 1 символ. Что-то мне подсказывает, что сделать пароль чуть длиннее сильно проще.
kbnrjlvfrfrf
04.05.2024 06:44А время подбора можно увеличить в n раз (n - размер словаря) просто добавив 1 символ. Что-то мне подсказывает, что сделать пароль чуть длиннее сильно проще.
Да отстаньте вы наконец от пользователя! PBKDF alike предоставляют аргумент степени повторов-итераций. Увеличьте его ещё на единицу, и можете спать спокойно ещё пару ближайших столетий!
Lex98
04.05.2024 06:44+1PBKDF alike предоставляют аргумент степени повторов-итераций. Увеличьте его ещё на единицу, и можете спать спокойно ещё пару ближайших столетий!
When the standard was written in the year 2000 the recommended minimum number of iterations was 1,000, but the parameter is intended to be increased over time as CPU speeds increase. A Kerberos standard in 2005 recommended 4,096 iterations; Apple reportedly used 2,000 for iOS 3, and 10,000 for iOS 4; while LastPass in 2011 used 5,000 iterations for JavaScript clients and 100,000 iterations for server-side hashing. In 2023, OWASP recommended to use 600,000 iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512.
И если увеличивать его не с такой же скоростью, как растет скорость вычислений, то, соответственно, увеличится время хеширования. Думаю мало кому понравится ждать логина пару минут (а то и пару часов) чтобы его пароль
1234был настолько же безопасен, как иkz~:1yIf0ES_s1oG'6Js.kbnrjlvfrfrf
04.05.2024 06:44Всё правильно. Аргумент увеличивает экспоненту повторов.
чтобы его пароль
1234Чтобы подбирать 1234, надо точно знать что там хотя бы одни цифры. Если взломщик попытается пойти по пути буквы+цифры, чтобы уж типа точно наверняка, то и 1234 может устоять.
1 комбинация в сек. это ОЧЕНЬ медленно для перебора, но практически незаметна для логина. Вы просто видимо никогда не занимались подбором паролей, поэтому кажется что всё очень просто, мощное железо на дороге бесплатно валяется, а за электричество мамка платит.
настолько же безопасен, как и
kz~:1yIf0ES_s1oG'6JsТакие пароли небезопасны, потому что их надо где-то хранить, со всеми из этого вытекающими. Тот случай когда лекарство уже наоборот убивает.
Lex98
04.05.2024 06:44Аргумент увеличивает экспоненту повторов
Может быть в какой-то конкретной реализации, насколько я понимаю в общем случае это просто количество итераций.
DK = PBKDF2(PRF, Password, Salt, c, dkLen); c is the number of iterations desired
Да и даже если так, за 23 года это количество увеличилось на 2 порядка, увеличение на 1 явно не хватит на "ещё пару ближайших столетий".
Чтобы подбирать 1234, надо точно знать что там хотя бы одни цифры
Начинают как раз с паролей с наименьшей энтропией. Сначала словарные, потом только числа, только строчная латиница и т.д. Даже если повезет, что конкретно этот цифровой пароль в миллионе самых популярных паролей не окажется (а
1234там в первой двадцатке стабильно), он все равно первый на подбор.Такие пароли небезопасны, потому что их надо где-то хранить, со всеми из этого вытекающими
Менеджеры паролей придуманы уже очень давно. Даже в режиме параноика (не хранить пароли в облаке (любом), никакой автосинхронизации, нет автозаполнения и т.д.) это все равно удобнее, чем самому этими паролями управлять. Я даже маму свою на keepass подсадил, ничего сложного или неудобного тут нет. При этом это на много порядков безопаснее (как в смысле каждого отдельного пароля, так и того, что каждый пароль уникален и утечка пароля от одного сервиса не влияет на доступы к другим).
vesper-bot
04.05.2024 06:44+2поиск коллизии (подбор пароля любой длинны) по утекшему древнему хешу - фактически всегда мгновенный
Вот это вот - как это? Я помню, что в мелкомягких офисах защита документа была сделана на каком-то кривом хэше, к которому действительно коллизия подбиралась, но даже под соленый SHA1 хрена с два подберешь коллизию, особенно если соль проверяется при валидации хэша. Что уж говорить о более суровых "постквантовых" алгоритмах.
tbp2k5
04.05.2024 06:44Ключевой момент моей фразы " древнему ". Собственно вся статья об этом. MD5 - мгновенно, bcrypt - чуть дольше.
Собственно есть целая палитра взломщиков и способов. На одном конце спектра есть обычный человек как вы - вы на вашем компьютере ничего особого сделать не сможете (кроме MD5 или совсем коротких паролей завернутых в bcrypt). На другом есть заинтересованные люди побогаче (разведки крупных стран) которые активно эксплуатируют чужие утечки. Между ними целая палитра возможностей.
eps
04.05.2024 06:44+2Про методику XKCD 936 нет внятного ответа. Из статьи ясно, что 4 слова без пробела подбираются «быстрее 14 квадриллионов лет».
А методика удобная. Из неожиданного: такое удобно перепечатывать с другого экрана и вводить на виртуальных клавиатурах.
И неудобно, когда сайт ограничивает максимальную длину пароля или запрещает пробелы („ваш пароль слишком надёжный; пожалуйста, выберите менее надёжный пароль“). Или требует к отличному паролю добавить какой-нибудь глупый знак, чтобы разработчикам сайта было спокойнее.
Я видел крутой валидатор пароля на сайте, который оценивал энтропию пароля, и заполнял шкалу. Она росла с каждым новым знаком, резко падала от словарных слов, резко росла при добавлении необычных символов и т.п.
Идеально!
ky0
04.05.2024 06:44Проверялка на сайте с обратной связью (не тащить же в браузер весь словарь?) - это как-то стрёмно.
eps
04.05.2024 06:44+6Там мог быть небольшой словарь. Тысяча самых популярных паролей, плюс пара тысяч слов — это 20 кБ. На фоне 20-мегабайтных джаваскриптов на самых модных сайтах это ерунда.
А главное — это для безопасности. Компании любят говорить, что их главный приоритет — безопасность. Вот пусть делают хорошую проверялку паролей, не пожалеют 100 кБ на отдельной странице, покажут свою заботу на деле.
ky0
04.05.2024 06:44+2Я компаниям не доверяю, мне Keepass рассказывает, достаточно ли энтропичен мой пароль :)
Mr_Boshi
04.05.2024 06:44+16Самая большая проблема паролей -- программисты, которые решают понаставить фильтров, чтоб пользователь ни в коем случае не поставил пароль, который ему хочется. Вариантов миллион: от странных "пароль не должен превышать 20 символов" до смешных, когда требуется, чтоб в пароле "не было рядом стоящих повторяющихся цифр" и "должны быть следующие спецсимволы: !_+=-*?" (остальные спецсимволы таковыми не считаются".
Зачем -- непонятно. Мало того, что это уменьшает секьюрность паролей (из перебора можно исключить не подходящие комбинации), так это еще и не дает пользоваться общим для всех сайтов алгоритмом генерации паролей и приходится для этого случая придумывать что-то, что потом ни за что не вспомнишь (ведь у тебя есть алгоритм, ты знаешь, что здесь пароль должен быть такой, но он не подходит). А взламывают в итоге все равно не подбором пароля а через утечку хешей или кражу токена авторизации.
quakin
04.05.2024 06:44+4Причём, один из таких "умников" - это Яндекс, в моём случае он не принимает некоторые печатные спецсимволы, поэтому использовать свой генератор паролей для него проблематично.
Последний раз проверял около года назад.
David_Osipov
04.05.2024 06:44В их же копилку то, что они не поддерживают стандартные 2FA TOTP, а просят скачать их чёртов Яндекс.Ключ, который мне 100 лет не сдался.
lisisty
04.05.2024 06:44+2очень настойчиво просят, но, обычный тотп все же тоже можно использовать. Порой надо войти, раз в 100 лет, а тебе суют какие-то ребусы, выбери картинку или что у них там, какой-то яндекс ключ, чего. А потом вспоминаешь что через тотп войти можно. И на том спасибо
micronull
04.05.2024 06:44+3Подтверждаю слова @lisisty. Яндекс.Ключ можно заменить на любое приложение TOTP. Там есть ссылка на получение секретного ключа.
volas
04.05.2024 06:44Раньше они использовали свои велосипеды и было не возможно. Сейчас действительно, попробовал, и даже QR-код отсканился обычным гугловским аутентификатором. Спасибо, что сказали.
Но они не предоставляют коды для восстановления! Или я их не нашел. Для включения 2fa потребовалось привязать телефон, и, похоже, единственный способ восстановления доступа в случае чего - через телефон, что опять какой-то свой уникальный путь.
meettya
04.05.2024 06:44Зачем -- непонятно.
Могу подсказать - зачем. Скорее всего у сервиса имеется какой-то махровый легаси-кроваво-энтерпрайзный бекенд, написанный черт знает на чем черт знает когда.
И есть требование хранить данные там, а у поля — вот такие ограничения.
Т.е. скорее всего если вы видите такую ересь - пароль хранится плейнтекстом, ага.
kbnrjlvfrfrf
04.05.2024 06:44+3Как обычно, литкодмакаки не смогли решить нелиткод проблему, поэтому просто переложили её на плечи пользователей. Давным давно настоящими специалистами уже были придуманы PBKDF подобные подходы плюс SALT, когда даже '1234' заколебёшься перебирать даже на самом мощном железе.
С вебом ещё проще: хэши не на дороге валяются, а задержки и блокировки атакующих ещё проще. Но как обычно: мы обосрались с информационной безопасностью, но переложим решение этой проблемы на плечи пользователей - пусть придумывают пароли посложнее.
Lex98
04.05.2024 06:44Если 1 пароль можно захешировать за разумное время (а это необходимо чтобы этим пользоваться на практике), то и 10^4 паролей будут хешироваться не долго. Даже если хеширование занимает 1 минуту, то перебор всех четырехзначных цифровых паролей займет меньше 17 часов (и это без ферм карт, а на таком же сервере, что и атакуемые сервис).
kbnrjlvfrfrf
04.05.2024 06:44Если вы не Илон Маск, и не на карандаше у ФСБ, никто нафиг вашим хешем персонально заниматься не будет. А в последнем случае куда эффективнее применить терморектальный криптоанализ.
Lex98
04.05.2024 06:44Так для этого и нужен длинный пароль, чтобы каждым хешем надо было заниматься отдельно, а не за пару часов перебрать всю базу в сотню-другую тысяч пользователей. Мне кажется логичным, что надо предполагать, что взломщик как-то в этом заинтересован и ломает не на core2duo (или даже epyc или xeon), а как минимум на пачке видеокарт, что увеличивает скорость даже не знаю на сколько порядков.
kbnrjlvfrfrf
04.05.2024 06:44Достаточно соли чтобы пришлось заниматься каждым хэшем отдельно. И если вы не Илон Маск, брутить вас экономически нецелесообразно. Конечно, могут попытаться пройтись словарём самых самых паролей, чисто на удачу. Наверно это единственное предостережение - не использовать совсем уж очевидные словарные пароли.
titbit
04.05.2024 06:44+3Вы не влияете на то, как будут храниться ваши пароли, может с PKDF, а может открытым текстом и тогда вас не спасет даже 140 символов. Ну и про всякие искусственные ограничения на пароли (видимо для облегчения их взлома) - это тоже прямо беда. Решение пока только в том, чтобы жестко действовать по правилу: один сервис - один пароль. Минус в том, что надо заводить кучу паролей, и хранение их в менеджере паролей не всегда надежный выход - это становится единой точкой отказа с точки зрения безопасности.
Второе - ну хорошо, на нормальной клавиатуре можно вводить многосимвольные пароли со спецсимволами, а что делать на смартфонах? Вводить тамошней клавиатурой даже 16 символьный пароль - одно мучение. Речь именно про ввод, т. е. там где вставка из кармана не работает, например пароль на разблокировку телефона. Причем нормального решения нет, замена на биометрию - это не решение (да и не замена). Разве что носимые ключи безопасности на bluetooth/nfc могут что-то предложить, но их поддержка в телефонах на зачаточном уровне.
Lazhu
04.05.2024 06:44на нормальной клавиатуре можно вводить многосимвольные пароли со спецсимволами, а что делать на смартфонах?
Особый цимес с паролями "набирай в английской раскладке русскими буквами", ага
micronull
04.05.2024 06:44Я выучил комбинацию латинских букв и порядок ввода спецсимволов. Не скрываю, иногда на клавиатурах с другим расположением символов подводит мышечная память.
mixaip
04.05.2024 06:44Стало интересно за какое время я ввожу 16-символьный случайно сгенерированный пароль на телефоне. Оказалось чуть меньше 9 секунд. На практике никаких мучений, немного практики, и сейчас это больше похоже на соревнование на скорость ввода. Хотя это ввод с 2 рук, одной будет явно дольше.
askharitonov
04.05.2024 06:44+1Сейчас, к сожалению, многие сайты, чтобы сбросить пароль, используют SMS с числовым кодом, что в принципе делает бессмысленными длинные пароли: ну допустим, взламывать пароль нужно 10 миллионов лет, а четырёхзначный код из SMS с первой попытки угадывается с вероятностью 0.01%. Ладно бы это где-то настраивалось (хочешь — используй код с длиной по умолчанию, а хочешь — вводи хоть двадцатичетырёхзначный код из цифр, букв и специальных символов).
metric_ghost
04.05.2024 06:44Там же 0.0001%, не? В каждой новой сессии подбора такая вероятность, это очень низкий шанс. Коды ведь не исключаются после отправки, это не пароли - не подошло, пометил неверным, каждый раз выбирается новый из диапазона 0000-9999. И коды сессионные, через несколько попыток подбора или определённое время требуется отправка нового, а с ним всё заново нужно начинать, с той же вероятностью угадать.
askharitonov
04.05.2024 06:44Вероятность подбора 1/10000, то есть, 1/100 процента (0.0001 или 0.01%), при этом попыток на один код может быть несколько. Допустим, три попытки, тогда вероятность взлома одного кода — 0.03%. Тоже не очень много, но, при этом, если процесс подбора пароля будет автоматизирован, используя разные IP-адреса, то 10 тысяч вариантов могут перебрать достаточно быстро. Но там, понятно, сложность в том, чтобы иметь ботнет из нескольких тысяч узлов.
Как вариант — взламываться могут разные сайты (то есть, не атака на какого-то конкретного пользователя, а просто наугад, чтобы хоть кого-то взломать), тогда количество IP-адресов для взлома (чтобы не забанили по IP) будет меньше. Далее, если речь идёт о какой-то известной личности, например, чьи фотки очень многие хотели бы посмотреть, и чей телефон стал известен, то там могут несколько тысяч разных людей попробовать, и этого может быть достаточно, чтобы у кого-то из них получилось.
Да и в целом, часто на сайтах нас просят сделать безопасный пароль (большие и маленькие буквы, цифры, специальные символы), а, при этом, сами уменьшают стойкость защиты используя коды из SMS. Обидно. Если тупо выбирать случайным образом пароль из первых 10001 в списке наиболее часто используемых паролей, то это видимо будет надёжнее, чем восстановление пароля по SMS с кодом из четырёх десятичных цифр.
Lex98
04.05.2024 06:44На количество одноразовых паролей в единицу времени тоже обычно ставят ограничение (еще и потому, что сервису надо платить за каждую смску), реальный человек за минуту 100 одноразовых паролей не запросит. Больше 5 одноразовых паролей на операцию - подожди час, выглядит подозрительно.
metric_ghost
04.05.2024 06:44В смысле перебрать десять тысяч вариантов достаточно быстро? Каждая новая сессия высланного смс требует угадывания с условно трёх попыток из десяти тысяч вариантов. Ранее высланные коды не исключаются из диапазона перебора, в этом же и идея, нельзя запросить 10000 смс и в последнем смс гарантированно угадать код, так не работает или я не понимаю, о чём тут речь.
askharitonov
04.05.2024 06:4410000 вариантов - это не очень много. Если лимитов на SMS нет (а если они есть, то это возможность блокировки легального пользователя ложными запросами), то 10 тысяч вариантов - это, допустим, около недели, если перебирать в среднем по одному варианту в минуту. А если перебирать будут параллельно для разных аккаунтов разных сайтов с разных IP-адресов, то скорость может быть и выше.
metric_ghost
04.05.2024 06:44Как понять-то про около недели? Это может быть бесконечно долго, если не угадать. Вероятность угадывания в каждой сессии не зависит от других сессий. Что там параллелить? В первом смс 1245, скажем, во втором 5674, в третьем 2222, в четвёртом снова 1245, они же не исключаются, каждая новая сессия независима. Каждый раз - три попытки угадать единственную комбинацию из десяти тысяч.
pes_loxmaty
04.05.2024 06:44+1Для 4-значного OTP и 3 попытках ввода на каждый. Это шанс угадать 0,03%
Теперь представь, что ты каждую минуту играешь в эту лотерею. Думаю статистически можно оценить шансы.
askharitonov
04.05.2024 06:44Это может быть очень долго если не повезёт. При этом, если вероятность не угадать в результате одной попытки равна 0.9999, то, скажем, вероятность не угадать за 7000 таких попыток будет уже менее 50% (скорее угадаешь, чем не угадаешь).
pes_loxmaty
04.05.2024 06:44Но ведь тут злоумышленник должен владеть правильной симкой - в этом случае OTP должен устоять лишь пока истинный владелец не вернет контроль на симкой, либо не предпримет какие-то еще действия. А это скорей всего от пары часов, до пары дней.
yokotoka
04.05.2024 06:44А ещё забавно когда в валидаторе пишут что пароль должен быть не меньше 8 символов, но НЕ БОЛЬШЕ 12
Причём на каком-то серьезном посещаемом сайте такое было
lorc
04.05.2024 06:44Чем старее и "круче" банк тем тупее у него требования к паролям. Когда-то у CBS, кажется, требование к "паролю" было - ровно 6 цифр.
nronnie
04.05.2024 06:44А имя пользователя, типа:
O&wPAwi*SNT0+u8h? :))lorc
04.05.2024 06:44+1Да если бы :)
Еще я помню как пытался поставить 6-значный PIN на карточку. Стандарт это позволяет как бы. И софт в в пин-паде это определенно поддерживал. А вот софт в самом банкомате - к сожалению нет. Поэтому мне банкомат напечатал сообщение об ошибке через принтер. Но по ходу где-то налажал с длинной текста или терминирующим символом, потому что после сообщения об ошибке мне принтер напечатал еще два метра бумаги с кусками содержимого памяти. При чем там можно было найти интересные штуки типа выписки предыдущего клиента с остатком на его счету.
Когда я описал эту проблему техподдержке они мне ответили "ну не надо пробовать ставить такой длинный PIN, позязя".
D7ILeucoH
04.05.2024 06:44Мда. Я не в первой вижу что люди как бы невзначай экстраполируют Профит от сложности пароля. На самом же деле он с определённого числа символов в принципе теряется. Почему? Потому что коллизии. Подбор пароля не обязывает вас угадать точно тот единственный пароль который ввёл юзер. Подойдёт любой из бесконечного числа подходящих под заданный хеш вариант. То есть под один хеш подходит бесконечное число паролей. Зная это, хеши всё ещё выглядят безопасными для вас?
Тейки о необходимости двух факторной авторизации, где надо ввести 4-6 цифр, которые в принципе можно случайно и угадать - тоже дичь, как по мне. Борьба с брутфорсом в общем то ни к чему и не привела.
Antra
04.05.2024 06:44То есть под один хеш подходит бесконечное число паролей.
Звучит серьезно. И есть оценки повторяемости? Скажем, если у нас есть триллион паролей (длиной не более 12 символов), сколько "пар" разных паролей будут иметь одинаковый хеш? "Троек" паролей захешированы одной последовательностью (т.е. любой из этих трех паролей подойдет)?
askharitonov
04.05.2024 06:44+1Оценку повторяемости дать очень легко: делим количество возможных паролей на количество возможных значений хеша и получаем, сколько на один хеш в среднем приходится паролей. Хотя, если я не туплю, то с хешами достаточно большой длины (например, 256 бит) вероятность коллизии получается очень небольшая, даже при длине пароля, выходящей за разумные пределы. То есть, вариантов паролей гораздо меньше, чем возможных значений хеша.
strvv
04.05.2024 06:44А если брать виндовые пароли, то 2 половинки по 7 символов, приведенных к большим буквам, т.е. словарь исходно не по 128-32=96 символа, на 26 меньше, т.е. 70 символов, и генерируя хэш от коротких паролей, можно подобрать и простые последовательности.
И у windows была? уязвимость удаленных соединений, можно было получить хэш паролей и пользоваться хэшем без расшифровки.
pes_loxmaty
04.05.2024 06:44+3То есть под один хеш подходит бесконечное число паролей. Зная это, хеши всё ещё выглядят безопасными для вас?
Если я правильно понимаю суть хэширования, то коллизии неизбежны, когда длинна исходного пароля превышает длину хэша. Но для стандартного 256-битного хэша это получается длина пароля должна быть от 32 символов. Если ваш пароль короче, то вероятность коллизии
7313
04.05.2024 06:44А по-моему лучший пароль это пароль, который нигде не записан :) Еще и по заветам Перельмана - какие-нибудь "Усы застряли в машине дурацким образом" русскими буквами в английской раскладке с одновременной заменой всех з на 3, о на 0, а ш на #
exTvr
04.05.2024 06:44+1русскими буквами в английской раскладке с одновременной заменой всех з на 3, о на 0, а ш на #
Это замечательно до тех пор пока вам не потребуется ввести этот пароль не с нормальной клавиатуры, а на смартфоне например.
inkelyad
04.05.2024 06:44какие-нибудь
(запуская так и не дописанный генератор парольных фраз)
"В постовом макете растёкся хрип тряпочных леек" - В процессе генерации использовано 70 бит энтропии.
"управление дворца сгущалось его рычанием" - 41 бит
"уменье кагора светит в льготе статного харчо" - 65 битНе использовать редкие слова - длину фразы нужно увеличивать.
Больше ну пусть дюжины таких помнить порядком трудно.
русскими буквами в английской раскладке с одновременной заменой всех з на 3, о на 0, а ш на #
А этого вообще не вспомнишь, где какие замены делал, если пароль не используешь постоянно и без перерыва. В отпуск ушел - и все замены из головы выветрились. Так что увы, с паролями (точнее со способностью их запоминать) у людей все плохо.
askharitonov
04.05.2024 06:44Можно выработать постоянно используемый вариант для замены символов, чтобы добавлять в пароль цифры и другие символы. Если, допустим, Ш всегда заменяется на #, то путаницы не будет, при этом в пароли, основанные на тех или иных фразах, будет попадать этот символ, т.е. уже не сработают варианты, где подбирается пароль исходя из предположения, что используются только буквы или буквы с цифрами.
artemisia_borealis
04.05.2024 06:44Географические названия неплохо походят.
Ыгыатта интригующе отражала Луну не по Снеллиусу
Прилетел размеренно автобус Тируванантапурам--Вадуц
inkelyad
04.05.2024 06:44Географические названия неплохо походят.
А потом мучительно вспоминаешь, какое именно название/имя использовал.
ky0
Вспоминается пятнадцатилетней давности случай, когда я, посмотрев на код софта, разрабатываемого в тогдашнем моём месте работы, обнаружил DES, шифрующий обрезаемый до 8 символов пароль. Уверен, до сих пор ничего не изменилось.
SAWER
Похоже у mail.ru было давным давно) Захожу на акк, пароль не подходит, но точно верный. Сбрасываю, задаю тот же пароль. Захожу в почту - не получается. Так и дошло, что они пароль обрезают. Ну и, получается, тогда они хранили пароли у себя в открытом виде
Antra
Не обязательно. Могли хеш вычислять и хранить уже от укороченного.
InvisibleMan
Есть один известный банк в Германии, который лет 8 назад тоже самое делал. Я долго понять не мог, почему мой пароль не подходит.
strvv
У Windows, и у полуоси вместе была проблема на SMBv1 и NTLM Hash.
16 байтный хэш. Казалось бы дофига, но пароль ограничен был 14 символами и все буквы приводились к верхнему регистру, и короткие дополнялись нулями.
Неуверен, память отказывает, но было ещё расчёт пополам. Первая половина рассчитывалась, а вторая зависела от первой.
https://habr.com/ru/articles/114150/ - LM Hash по 7 символов расчитывался, т.е. до NT5.х (2000 и XP) включительно - можно было легко брутфорсить, с Висты LM Hash убрали.
strvv
нашлась относительно старая статья (2006год) про LOphtCrack v4,
там, в подвале, сроки взлома указывались:
Нет абсолютно надежных паролей. Есть пароли, которые взламываются слишком долго
В ходе исследования устойчивости паролей с помощью программного обеспечения для взлома Windows NT/2000 LC4 и словаря объемом 9 Мб было выяснено следующее.
Состав пароля
Время взлома
Стандартные слова английского или русского языка - до 2 мин
Цифры и буквы английского алфавита, не менее 8 символов - до 40 суток
Буквы, цифры, спецсимволы - всего не менее 8-ми символов - до 100 суток
В пароле встречается символ "возврат каретки" -
программа LC4 не может корректно обработать такой пароль
http://www.silicontaiga.ru/home.asp?artId=5014
saboteur_kiev
В юникс так было давным давно.
Но главная суть - сейчас хакеру не нужно давать доступ к хешу и все
mpa4b
Если "хеш" пароля считается каким-нить argon2id, то таковой хеш какеру мало поможет. Ну, за исключением словарных паролей, конечно. Просто корпорастам жалко своих вычислительных мощностей, чтоб такое считать на каждый логин. Ничего личного, просто бизнес, безопасность паролей -- да плевать.