Комментарии 160
Вспоминается пятнадцатилетней давности случай, когда я, посмотрев на код софта, разрабатываемого в тогдашнем моём месте работы, обнаружил DES, шифрующий обрезаемый до 8 символов пароль. Уверен, до сих пор ничего не изменилось.
Похоже у mail.ru было давным давно) Захожу на акк, пароль не подходит, но точно верный. Сбрасываю, задаю тот же пароль. Захожу в почту - не получается. Так и дошло, что они пароль обрезают. Ну и, получается, тогда они хранили пароли у себя в открытом виде
Не обязательно. Могли хеш вычислять и хранить уже от укороченного.
Есть один известный банк в Германии, который лет 8 назад тоже самое делал. Я долго понять не мог, почему мой пароль не подходит.
У Windows, и у полуоси вместе была проблема на SMBv1 и NTLM Hash.
16 байтный хэш. Казалось бы дофига, но пароль ограничен был 14 символами и все буквы приводились к верхнему регистру, и короткие дополнялись нулями.
Неуверен, память отказывает, но было ещё расчёт пополам. Первая половина рассчитывалась, а вторая зависела от первой.
https://habr.com/ru/articles/114150/ - LM Hash по 7 символов расчитывался, т.е. до NT5.х (2000 и XP) включительно - можно было легко брутфорсить, с Висты LM Hash убрали.
нашлась относительно старая статья (2006год) про LOphtCrack v4,
там, в подвале, сроки взлома указывались:
Нет абсолютно надежных паролей. Есть пароли, которые взламываются слишком долго
В ходе исследования устойчивости паролей с помощью программного обеспечения для взлома Windows NT/2000 LC4 и словаря объемом 9 Мб было выяснено следующее.
Состав пароля
Время взлома
Стандартные слова английского или русского языка - до 2 мин
Цифры и буквы английского алфавита, не менее 8 символов - до 40 суток
Буквы, цифры, спецсимволы - всего не менее 8-ми символов - до 100 суток
В пароле встречается символ "возврат каретки" -
программа LC4 не может корректно обработать такой пароль
В юникс так было давным давно.
Но главная суть - сейчас хакеру не нужно давать доступ к хешу и все
Ну сколько можно, из раза в раз писать про большие, маленькие, символы в 8-12 символьных паролях, пора бы уже просто написать, что любой пароль в 8 символов - скомпрометирован и закрыть тему. Пароль в 12 символов - мало надёжен. И рассматривать уже действительно интересные решение, например, из вашей таблички следует, что пароль в виде 10371202471119117211 более чем надёжен, а ведь я просто взял два номера телефона и первую цифру заменил на 1..
Тут вот какой момент ещё встречается...
Есть аппаратура (вполне современная), у которой возможность использовать пароль больше 8 знаков есть, но это приводит к "странностям" в работе.
Реально...
Сталкивался не раз, методом "научного тыка" пришёл к выводу "да ну на*ер!!!" (сброс до дефолтных = работает, ставишь пароль не с самого начала работы с железом, а уже в конце и хисторирепитинг...)
Смог пройти через кучу бестолковых "саппортников" (благо есть свои тропинки), и в итоге получить от более сведущих инженеров подтверждение, что "ну да, есть такое...".
А ведь в моей старой привычке менять заводской пароль на 12 значный (просто большие и маленькие буквы, БЕЗ спец символов, от которых у FW вообще бывает что крышу сносит).
P.S.
Пользуясь случаем (С) :)
Немного прорекламирую/посоветую ресурс passgen.ru но больше в попытке достучаться до владельцев этого несомненно полезного ресурса.
Пробовал связаться с ними несколько раз, для одной мелкой "рацухи".
Господа, введите PLS! ещё один фильтр в ограничение генерации !
"Исключить использование схожих по написанию/отображению символов"
(речь как минимум про про O0, IiLl)
Ну не вся техника в своих меню показывает их РАЗНЫМИ, а когда у тебя нет возможности копипастить, то вводить уже упомянутые 12 символьные пароли, особенно на 10-20-30 устройств подряд (все разные), становится тем ещё квестом.
ДА, вынужденно выбираю из сгененрированного списка вариантов, пароли с отсутствием таких символов, но это не дело...
СПАСИБО ! :)
Вот такой генератор давно накатал в приступе паранойи, похожие символы отсекаются одной галочкой, и сразу можно оценить количество бит для перебора.
To: 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.
Иконку/кнопку копипасты, удобнее пользовать если она находится сразу после строки с символами.
Да и про "модную" ситуацию с символом пробела в конце, тоже, желательно учесть :)
Ты устраиваешь заказчику жуткий геморрой. Ты работаешь в пуско-наладке. Твоя задача сдать работающую систему заказчику и отдать пароли. ВСЕ. Дальше Заказчик меняет пароль от админки системы и в идеале, через "программу для массовой конфигурации камер" пароли на камеры. Он должен на 1000 камер сделать это в идеале по 1 клику, а не по Excel таблице, каждой камере менять.
Подобрать нереально. Блок на 5 минут после 5 фейлов. Да и пароль обязателен не меньше 8 символов с Регистром и спецсимволами.
И при том, что у меня был сотрудник, который обиделся и его уволили, перед увольнением поменял пароли на 800 камер (да одним кликом, но была б у него табличка Excel, заняло бы у него часа 3).
Знал старый пароль от камер, довольно простой - это для настройки и сдачи. Но чел, тоже не дурак, классический логический перебор не удался. Брутфорс на камерах - никак.
Если честно, то и тема взлома паролей, даже по ХЕШ. У меня на домашнем маршрутизаторе вай-фай пароль 12345543218899. Вот взломает его кто?
Какие то взаимоисключающие и противоречивые условия получились :) (но в реальности встречаются и не такие выкрутасы).
1. Если у заказчика есть свои сильные айтишники, то пусть он сам строит систему.
2.Если у него их нет, а есть "эникейщики", то качественная работа системы/оборудования в течении гарантийного срока как раз таки и обеспечивается "изоляцией" доступа к настройкам от таких посторонних, которые своими шаловливыми ручками могут наворотить такое, что бывает потом дольше разбираться, чем сбросить и настроить всё по новой (если без рабочих бэкапов).
(это как вариант).
3. Про "одним кликом сменить все пароли" - м.б. где-то и актуально (по определённым сценариям), но довольно узкопрофильно и небезопасно. Причины уже описаны сразу, в вашем же комментарии.
Клиент/заказчик имеет предоставленный ему набор пользовательских паролей к регистратору/серверу.
Необходимые отделы/сотрудники разделены своими учётками, каждая даёт разные уровни доступа. Любая из них удаляется/добавляется при увольнении этого сотрудника (не затрагивая работу других).
Камеры сидят под админскими учётками, в некоторых случаях добавляются сервисные (для прописывания в регистраторы/серверы, примерно с такими же целями как и "пользовательские").
Вариант доступа к видео/звуку (через Onvif) блокируется в самих камерах, благо такая дыра уже пофиксена у многих нормальных производителей.
Все вопросы по ограничению/регуляции доступа решаются комплексно, а не "местами так, местами сяк".
P.S.
Способов "положить" всю систему видеонаблюдения предостаточно, особенно если давать к ней доступ посторонним. Или обижать тех, кто её грамотно создавал и полноценно обслуживал.
Отчасти поэтому, у стабильно работающих "установщиков" (любого масштаба), есть своя репутация и круг клиентов, с которыми они идут рука об руку много лет.
Ровно как и наоборот - среди профильных контор, есть "чёрный список" клиентов, с которыми связываться - себе дороже.
Вот скажите. У Вас на объекте 500-1000 камер. И тут заказчик говорит, что-то нагрузка сильная, поменяй пожалуйста GOP на 10, Второй поток до 320. Вы будете в каждую камеру стучаться и менять настройку?
Посмотрите на новые версии Macroscope. Там можно в 1 клик добавить 254 камеры (ограничение в IP диапазоне) (Они вроде первые, на моей практике добавили оптовое добавление). Я добавил камеры, и они СРАЗУ работаю. Мне не надо копипастить на каждую камеру пароль.
Грамотные IT обычно больше вредят. Пробиться через их Доменные настройки и Антивирусы, это ад. Все порты перекрыты. При том, система безопасности обычно - изолированная сеть, с максимум, доступом по VPN но каждому свое.
Если сданную систему отдают Эникейщикам - ну дэк - Бэкапы никто не отменял, и просто у тебя появляется дополнительная оплачиваемая работа.
По поводу ограничения прав доступа, нет, ну тут и так все понятно. Каждому клиенту свое - тут спору нет, с ограничениями и т.п. Но админские пароли Вы же все равно передает? А как заказчик ими распорядится?
И тут заказчик говорит, что-то нагрузка сильная, поменяй пожалуйста 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х (даже для внутренней сети без возможности прямого доступа к кабелям/коммутации)
Тут уже другая консерватория, сейчас речь чуть про другое.
Если сданную систему отдают Эникейщикам - ну дэк - Бэкапы никто не отменял, и просто у тебя появляется дополнительная оплачиваемая работа.
я про это сразу обозначил, полностью (просто посмотрите чуть внимательнее)
По поводу ограничения прав доступа, нет, ну тут и так все понятно. Каждому клиенту свое - тут спору нет, с ограничениями и т.п. Но админские пароли Вы же все равно передает? А как заказчик ими распорядится?
Тоже написал ранее.
Всё индивидуально и по ситуации.
- Если хотят гарантии, то админка у монтажной организации до окончания срока гарантии.
- Продление гарантии = админка продолжает находится у "монтажников".
- Клиент хочет получить полный доступ = клиенту демонстрируется полноценная работа, в момент передачи админки гарантия снимается.
Только дай знать где ты находишься, дай знать и всё
Юзеры, записывая пароль, умудряются путать 9 и g, 5 и s, 6 и b, 8 и B. Следует это учитывать, сделав вторую галочку "пароль будет записан балбесом на бумажке". :)
Поднимите себе vaultwarden личный, если очень хочется - с доступом через vlan, там все есть.
На мой взгляд, это уже усложнение... (но кому как)
Для своих задач обкатал другой способ - создание Excel таблицы с внесением в неё необходимых данных по всему "своему" железу.
Если по каким то причинам с клиентом сотрудничество дальше не планируется, то после окончания гарантии ему отдаётся распечатка и всё.
Для особо "щепетильных", после сдачи объекта в эксплуатацию делается распечатка и убирается в "сетку"+фольгу а затем в опломбированный конверт.
Если на объекте (во время гарантийных сроков) что-то пошло "не так", первым делом проверяется этот "пакет под сургучом".
Вскрыт = одна цена восстановления (или "копошитесь сами").
Целый = работаем штатно. (по согласованным ранее условиям).
Вот есть моя реализация:
https://shashkovs.ru/p/
To: ShashkovS
Недурно !
Утащил в закладки, однозначно. (по нынешним временам звучит кхм...) :)
На "свежий взгляд" [возможно тоже думали, но сомневались (?)].
- схожие по начертанию символы
(внешнему виду / отображению)
- немного "дисс" по маленькие/заглавные (маленькие/большие, прописные/заглавные)
- Пароли готовы / Варианты паролей (готовы это больше кулинария + "утверждение")
- не силён в WEB/HTML, но хотелось бы иметь возможность "чистой" копипасты (паролей) для переноса, например в таблицу Excel, сейчас, мышкой получается тащить только с нумерацией строк.
Есть ещё (личное мнение) по взаиморасположению элементов на экране, но это личные "придирки".
Это уже больше на уровне "отдельная кнопка для копирования" (в конце поля пароля), возможно с индикацией "уже скопировано".
Плюс, возможно отдельную кнопку "скопировать ВСЕ"
Может быть (надо смотреть), не одну общую строку для всех символов, а отдельные, после раздельных же "условий":
маленькие_[_____________]
БОЛЬШИЕ_[_____________]
Цифры _ [_____________]
Спец.символы _[_____________]
Сейчас, с непривычки, глаза начинают "спотыкаться".
P.S.
Про символ единицы не задумывался, но скорее всего соглашусь.
Да, это всё можно подкрутить, совсем несложно. Там кода — 10 строк js и 10 строк html.
Про удобное копирование даже задумывался.
Давайте так: если моё сообщение выше наберёт 10+ «лайков», то выделю время и прикручу :)
По возможным "алаверды" я уже отметился :) (не только за комментарий)
Какие-то сугубо свои "хотелки" обозначил, из "дальнесрочных" хотелось бы какой то простой способ (для памяти) попадания на страницу с генератором (у парней из passgen.ru это работает).
Если "шлифануть в идеал", то можно и отдельный сайт, хостинг сейчас недорогой (у многих есть свободные лоты от провайдера). У меня например из 5 предложенных по тарифному плану, заняты только 3.
Как минимум могу разместить иконку/ссылку в планируемых у себя "полезняшках" (но это планы).
Стоит также добавить проверку, чтобы обязательно в пароль попало как минимум по одному символу из каждой выбранной категории.
немного "дисс" по маленькие/заглавные (маленькие/большие, прописные/заглавные)
Больше дисс по "прописные/заглавные": в русском языке это одно и тоже (тогда уж прописные/строчны́е).
А я 20 лет назад (ещё в школе) написал на Boland C++ программу и тоже назвал её PassGen.
Она собирает статистику по корпусу текста (я обучал её на Толкиене), а потом за каждой буквой случайно выбирает следующую в соответствии с этой статистикой. В итоге получается легкозапоминаемая бессмыслица. Для большей англоподобности пароли составляются задом наперёд, потому что окончания в английском гораздо более однообразны, чем начала слов.
Заинтриговали :)
Примеры в студию ! (С)
Нечто стилистически схожее, сравнительно недавно предлагала одна компания, но в теме "шифрования" GPS координат для каких-либо "аварийных" ситуаций.
Там изюминка была в том, что при возникновении "как то жарко стало", человек открывал например на смартфоне приложение, приложение смотрело координаты, и на их основе генерировало нечто "читаемое" (на слух и удобство голосовой связи).
На другой стороне канала (условно спасатели или доверенное лицо) переданная фраза вводилась в такое же приложение, и после "дешифровки" появлялся квадрат поиска с вполне удобно/приемлимыми "контурами" (периметром).
P.S.
Речь не идёт про места с устойчивой сотовой связью, акцент/больше для классической радиосвязи, где не скопипастить и не заскриншотить.
Только сейчас увидел, почему то после появления комментария картинки не было, (сейчас зашёл в ветку после уточнения/поправки к моему комментарию, и увидел такой набор).
На мой взгляд(и опыт), это "чуть" специфично и адресно (для фанатов этого направления скорее всего Ок, а для непривычных - можно удачно забыть сразу после первого ввода).
Хотя, работал в одной конторе, там админ на "чувствительных" ПК прошивал такую абракадабру, что пользователи сначала фотографировали, а потом (неожиданно) смогли запомнить.
Только олды знают как должен выглядеть идеальный пароль: DYB3T-F2QYQ-9CRXR-DBC4V-CC4YG
этот лучше знают: J3QQ4-H7H2V-2HCH4-M3HK8-6M8VW и звучит как песня.
Забавно, что ваш и @JordanCppбез символа "-" скомпрометированы судя по https://haveibeenpwned.com/Passwords. C "-" утечек пока не было) Можно пользоваться.
Там было про стотысячобезьян
а где у хакеров есть возможность перебирать миллионы паролей в секунду?
Либо я чего-то не понимаю, но большинство сайтов просто не позволит так делать. Это не говоря уже о том, что просто дождаться пока пароль валидируется, это уже миллисекунды. Но тут, конечно, можно в параллель.
Современные возможности проксей и их низкая стоимость позволяют создавать атаку, которую тяжело завалидировать каким-то образом и запретить это делать. В случае эппл, например, был прикол с тем, что, когда кто-то брутфорсил пароль с множества разных IP, они (эппл) блокировали аутентификацию конкретной учетной записи и в итоге от этого страдал обычный пользователь — владелец учетной записи. Тут дилемма и сразу не одна — как грамотно обеспечить безопасность этому.
Интересно, почему тяжело завалидировать, ведь обращение идет к одному аккаунту? Что мешает ничего не блокировать, просто проверять не чаще раза в секунду?
Это будет _почти_блокировка аккаунта: из 10000 попыток в секунду пользовательская будет одна -- и скорее всего (99.99%) проверяться не будет.
Это если пользователь пытается зайти в тот самый момент когда кто-то брутфорсит именно его пароль.
И в общем-то не плохо будет если пользователь в такой ситуации увидит ошибку а ля "слишком много попыток ввода пароля".
Вместо "ваш счет за ресторан оплачен"?
Совершенно не уверен, что лучше. В целом это даст возможность парализовать навсегда любую жертву. Просто будут слать запросы на авторизацию нонстоп и ваш айфон превратится в кирпич.
А это довольно просто и дешево. К сожалению.
PS. Насколько я понимаю речь не о подборе пароля, а о его получения из украденного хеша. Хеш добыть проще.
Вместо "ваш счет за ресторан оплачен"?
Если мы говорим о относительно "критических" вещах вроде денег, то на мой взгляд там всё равно нельзя полагаться на один только пароль. То есть нужно минимум два фактора.
Просто будут слать запросы на авторизацию
Пароль это не единственный способ авторизации. То есть можно добавить какой-то "запасной" механизм, который работает по другому принципу.
Ну и вообще на мой взгляд логичнее всего в случае подозрения на брутфорс просто ограничивать скорость повторов. Даже банально если сделать одну попытку в секунду, то брутфорс становится не особо оптимальным вариантом.
Плюс можно смотреть на ip и блокировать только частые повторы с одного и того же. Что опять же усложнит жизнь мошенникам.
Плюс можно "запоминать" девайсы и давать известным девайсам приоритет по сравнению с незнакомыми.
И так далее и тому подобное.
Это просто и дешево для чего? Чтобы подгадить кому-то лично, не давая залогиниться в эпл айди? С трудом представляю мотивацию даже бесплатно этим заниматься, не говоря о каких-то распределенных атаках.
Тем более "окирпичить" айфон не выйдет таким образом, да и любой телефон. Пока вроде бы инет не нужен, чтоб телефон работал. О каком логине речь? Биометрия или фейс айди прямо в телефоне, у айфона даже отдельный чип для шифрования, вы можете всегда зайти в телефон даже если связи нет. И даже когда вы подтверждаете какую-то покупку, вы логинитесь в телефон, а не куда-то на сервер. Если введете пароль в телефон 10 раз неверно, тогда он превратится в кирпич. В самом прямом смысле слова, помочь вам сможет только техподдержка, которой надо отправить телефон физически, и набор документов подтверждающих личность и покупку. И подождать от 3 до 6 месяцев.
Если говорить не про айфон, а про рандомную веб-морду чего-либо, то брутфорсить пароль отправляя запросы на сервер на сегодня может прийти в голову только мамонту, пролежавшему во льдах всю компьютерную эпоху. Это имеет ровно ноль шансов, даже если у вас пароль кверти123. Учитывая время на проверку скорость перебора будет на порядки ниже, чем та что заложена в таблицах из статьи. А сам процесс вопиюще палевный, его пресекут на корню, а жертва будет предупреждена, что на нее идет атака.
Написанное в статье имеет смысл только для украденного хэша, когда он в руках хакера. Иначе никаких таблиц построить не выйдет. Все системы сегодня имеют защиту от брутфорса, а если где-то появляются уязвимости, то это случай из ряда вон с очень индивидуальным сценарием и метриками. Вот базы юзверей сливают регулярно тут и там, человеческий фактор, или корпоративная уязвимость и привет, 100500 тыщ аккаунтов утекли в даркнет, вполне вероятно с хэшами паролей.
PS. Насколько я понимаю речь не о подборе пароля, а о его получения из украденного хеша. Хеш добыть проще.
Получить хеш проще чем подобрать пароль к хешу?
Это где такие уязвимости, что хеши просто разложены, бери не хочу?
Так постоянно всякие базы утекают.
Если база утекла, вряд ли будет особый смысл в длинных паролях..
Как раз весь смысл хеширования паролей (и соли) в том, что даже если база утекла нельзя было эти пароли получить. Точнее можно было, но (на текущем железе) это занимало бы миллиарды лет. Самый простой пример: пароли из одной цифры. Есть всего 10 вариантов, тут ни соль не поможет (слишком мало вариантов, можно быстро проверить все варианты с заданной солью), ни криптографические хеш-функции (если хеш-функция работает адекватное время для проверки одного пароля, то для 10 вариантов она тоже работает за небольшое время). А вот если пароли состоят из 100 цифр, то это уже 10^100, такое уже при всем желании (с использованием всех вычислительных мощностей планеты) не получится, вариантов слишком много. За этим и нужно и использовать длинные пароли (увеличиваем количество вариантов), и использовать медленные и затратные по памяти хеш-функции (увеличиваем время (или стоимость в деньгах) проверки одного варианта), и соль (чтобы нельзя было 1 раз предпосчитать все варианты до длины n и переиспользывать).
Это при условии, что хэш пароля из 100 цифр не совпадет с хешем пароля из например 2 цифр
Для современных криптографических хеш-функций найти коллизию сложнее, чем подобрать пароль адекватной длины. Для Argon2 нужно перебрать 2^256 вариантов. Это, конечно, не 10^100, но 10^77 тоже неплохо.
И при этом оставить ему самому возможность логиниться через passkey
И сможет все равно привнести некоторый вред даже не через достижение цели как "получение пароля" - а просто кто-нибудь будет дурачиться и блокировать кому-нибудь доступ к аутентификации.
Да, Ваше решение хорошее, но у него всего равно есть подводные камни.
Так, например, в играх была одна из интересных атак, когда с помощью множества проксей создавалось подключение под определенным псевдоним к серверу, занимая некоторый слот этого псевдонима, и игрок так же не мог зайти под этим псевдонимом, потому что слот его псевдонима был занят. И так могли делать на протяжении множества суток, создавая бесконечные переподключения.
Так вот, такое же может произойти соответственно с рядовым пользователем, если кто-то на него просто поставит не то чтобы буртфорс, а просто ддос на его псевдоним бесконечный (с учетом 1 запроса в секунду, это обойдется вообще не дорого, даже дешевле, если просто брутфорсить).
Всё сводится в итоге к тому, что самый оптимальный вариант - это повышение сложности пароля, чтобы не создавать такие лимитеры (то есть, чтобы и пользователю было удобно, и было безопасно).
Лимитеры, естественно, должны быть, но в разумных рамках.
Лимитер на аккаунт для аутентификации, имхо, не самый оптимальный вариант.
Но я так же могу быть не прав, признаю.
Например, был момент, когда был брутфорс у Apple, суть которого заключалась в подборе 6-значного кода из цифр для авторизации. И у них не было лимитера корректного. Точнее он был - ограничение по запросам по IP и на аккаунт (вроде как 3 запроса) - но была некоторая неполадка в синхронизации лимитера, из-за чего можно было подобрать этот "пароль", отправив одновременно множество запросов в единицу времени с разных проксей.
Можно поискать эту статью на хабре, если конечно Apple не попросила её удалить (потому что другие статьи удалены на подобные темы).
UPD: При этом, когда лимитер отрабатывал как надо - он блокировал доступ реальному пользователю, это тоже было забавно. В итоге, пользователь терял на сутки по-моему доступ к восстановлению аккаунта или к авторизации - точно уже не помню.
Есть дешёвый способ - отдавать ответ медленно. Человеку секунда туда, секунда сюда, без разницы.
Не факт, что к одному аккаунту. Один из методов брутфорса по таблице паролей - проверка одного пароля из таблицы сразу для многих аккаунтов. В этом случае обращения к каждому конкретному аккаунту достаточно редкие.
Каким образом прокси позволят логиниться с тем же самым логином?
а где у хакеров есть возможность перебирать миллионы паролей в секунду?
Во всех подобных статьях под взломом пароля понимается попытка взлома утекшей базы хэшей. Сетевые задержки и ограничения на сервере в таком случае неприменимы.
Это в случае, когда злоумышленник получил доступ к бд с хешами. То есть максимально плохой сценарий - ограничений на число итераций нет, задержки нет, оборудование для взлома под рукой.
В принципе, брутфорсить учётку в онлайн никто и не будет. Посредством инъекций и разного рода ддоса, атакуется сайт. Сливается база с хэшами паролей и вот с ними уже можно работать оффлайн сколько душе угодно.
Поправьте меня, но никто хеши публично не выкладывает. Соответственно получение хешей и есть взлом. То что представлено в данной статье - это скорее расчет времени которое остается у компании для реакции на инцидент с кражей хешей.
Если бы хеши никогда не утекали, зачем бы они вообще были нужны? Можно было бы тупо хранить пароли. Все эти системы проектируют из предположения об утечках (и хешей, и всех алгоритмов) для минимизации вреда от них.
> Если бы хеши никогда не утекали, зачем бы они вообще были нужны?
Ну например для того чтобы админы/девелоперы (аппликации, базы данных, бекапа) тоже не имели простого доступа к паролям. Или вам кажется что обычный админ с его обычными ресурсами будет ждать 100 лет для взлома 8 символьного пароля из чистого любопытства ?
Это разновидность утечки.
Мне, как пользователю, не принципиально как вы классифицируете инциденты безопасности. Мне важно чтобы мой пароль был недоступен в любом разумном сценарии - современные алгоритмы это обеспечивают.
Беда всех этих табличек со временем взлома - в том что с ними носятся безопасники или начальство которое не понимает банальных вещей:
подбор 8-символьного пароля через SSH (убираем все ограничители) или типичную веб-службу займет эдак лет 30000. Допускаю что поработав как следует вы оптимизируете на взлом за 3 столетия - не принципиально
поиск коллизии (подбор пароля любой длинны) по утекшему древнему хешу - фактически всегда мгновенный
Вывод (мой): бессмысленно морочить голову пользователям требуя сложный и длинный пароль - делайте нормальный бекофис (например PBKDF2), не допускайте утечек, а если утекло - меняйте все пароли.
Мне важно чтобы мой пароль был недоступен в любом разумном сценарии
Именно для этого и разумно заранее считать хеши утёкшими. И делать так, чтобы утёкшие хеши не означали утекание паролей. Полагаться на то, что хеши не утекут, это… ну, не security through obscurity, но из той же области.
Вы фундаментально ошибаетесь допуская принятие утечки как данность:
Хороших алгоритмов для хеширования единицы. Криптография - сложная наука и при попытке изобрести свой велосипед вы точно будете в зоне риска. А для извесных алгоритмов есть радужные таблицы или суррогаты основаные на той же идее.
Скорость поиска коллизии можно увеличивать практически до бесконечности (распараллеливать на все доступные ресурсы, специализирование ASICи, и.т.д.) да к тому-же все это можно делать незаметно для жертвы.
Не ленитесь: сегодня утечка хешей практичеки такая-же катастрофа как утечка паролей в чистом виде. Тот что лично вы не можете подобрать пароль от хеша не значит что у американского NSA, китайского SSM или достаточно крупное предприятие это хоть немного задержит. А с другой стороны, даже ваш домашний SSH (или другой сервис) все эти уважаемые организации смогут брутфорсить со скоростью, в лучшем случае, тысячи попыток в секунду. И париться они над этим будут не одно столетие.
Вы фундаментально ошибаетесь допуская принятие утечки как данность
Тогда ответьте на один простой вопрос: в чём смысл существования хешей? Raison d'être, тысызыть?
Мне старшие товарищи в своё время так объяснили, почему они вслед за всем миром перешли от хранения паролей к хранению хешей: чтобы можно было не бояться, что при угоне базы утекут пароли.
Я застал ту эпоху.
1) Основное: не допустить чтобы амин/девелопер мог по быстрому подсмотреть чужой пароль да и поправить чтонибуть себе или попросившей его подружке.
2) Убрать проблему "неприличных" паролей которые могли ранить тонкую психику админов. Было и такое :-)
И поначалу (до появления NVidia с CUDAой) коллизию реально трудно было найти - давным давно - это действительно защищало...
Админ/девелопер может просто записать в базу хеш своего пароля, и залогиниться. Если есть админский доступ к базе, узнавать изначальный пароль не требуется
Разного порядка риски: одно дело подсказать подружке пароль ее начальницы (и поди докажи откуда она его узнала), а другое - апдетить запись. Во первых не факт что обычный админ/девелопер сможет обновить хаш (при правильном дизайне - не сможет). Во вторых апдейт оставит всякие прямые и косвенные следы (время обновления, логи, бекапы, и т.д.)
А для извесных алгоритмов есть радужные таблицы или суррогаты основаные на той же идее
Так против радужных таблиц хорошо помогает соль. Для каждого пароля берём случайную строку символов большой длины (соль), добавляем её к паролю в конец, считаем хеш и сохраняем его значение и соль в таблицу. При проверке пароля тоже добавляем к паролю соль для этого пользователя, считаем хеш и сравниваем с сохранённым.
Это все правда, но не вся правда: соль просто сильно увеличивает стоимость взлома.
При утечке утечет и хеш и соль: взломщик может практически до бесконечно распаралеливать поиск колизии. Просто, для примера, посмотрите в статье скорость поиска для bcrypt (он использует соль).
соль просто сильно увеличивает стоимость взлома
Ну да, сочетание длинного пароля, соли и ресурсоемкого хеша увеличивает эту стоимость до такой, что даже 1 пароль нельзя взломать используя все вычислительные мощности планеты (по крайней мере те, о которых известно) за миллиарды лет. Мне кажется это достаточно хорошо гарантирует сохранность пароля даже при утекших хешах с солью.
Ну так это и есть скорость. И комбинация длинного пароля, соли и ресурсоемкого хеша делает невозможным как взлом конкретного пароля, так и создание радужных таблиц для перебора сразу всех.
Ещё соль не даёт использовать радужные таблицы. Не получится предварительно один раз вычислить хеши паролей на очень быстром компьютере (и сохранить их в относительно компактной форме) и потом эту информацию использовать для взлома на более медленных компьютерах, потому что невозможно создать радужные таблицы для всех вариантов с достаточно длинной солью.
Скорость поиска коллизии можно увеличивать практически до бесконечности
Как раз скорость поиска очень даже ограничена (вычислительными мощностями всей планеты), а вот сложность пароля практически не ограничена. Сейчас будет сравнение апельсинов с карьерным самосвалом, но для увеличения скорости подбора в 2 раза надо либо в 2 раза больше железа (что дорого), либо ждать несколько лет пока индустрия выпустит новое, более мощное (или более эффективное в производительности за рубль) железо. А время подбора можно увеличить в n раз (n - размер словаря) просто добавив 1 символ. Что-то мне подсказывает, что сделать пароль чуть длиннее сильно проще.
PBKDF 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.
Аргумент увеличивает экспоненту повторов
Может быть в какой-то конкретной реализации, насколько я понимаю в общем случае это просто количество итераций.
DK = PBKDF2(PRF, Password, Salt, c, dkLen); c is the number of iterations desired
Да и даже если так, за 23 года это количество увеличилось на 2 порядка, увеличение на 1 явно не хватит на "ещё пару ближайших столетий".
Чтобы подбирать 1234, надо точно знать что там хотя бы одни цифры
Начинают как раз с паролей с наименьшей энтропией. Сначала словарные, потом только числа, только строчная латиница и т.д. Даже если повезет, что конкретно этот цифровой пароль в миллионе самых популярных паролей не окажется (а 1234 там в первой двадцатке стабильно), он все равно первый на подбор.
Такие пароли небезопасны, потому что их надо где-то хранить, со всеми из этого вытекающими
Менеджеры паролей придуманы уже очень давно. Даже в режиме параноика (не хранить пароли в облаке (любом), никакой автосинхронизации, нет автозаполнения и т.д.) это все равно удобнее, чем самому этими паролями управлять. Я даже маму свою на keepass подсадил, ничего сложного или неудобного тут нет. При этом это на много порядков безопаснее (как в смысле каждого отдельного пароля, так и того, что каждый пароль уникален и утечка пароля от одного сервиса не влияет на доступы к другим).
радужных таблиц нет с момента появления соли к хешам.
поиск коллизии (подбор пароля любой длинны) по утекшему древнему хешу - фактически всегда мгновенный
Вот это вот - как это? Я помню, что в мелкомягких офисах защита документа была сделана на каком-то кривом хэше, к которому действительно коллизия подбиралась, но даже под соленый SHA1 хрена с два подберешь коллизию, особенно если соль проверяется при валидации хэша. Что уж говорить о более суровых "постквантовых" алгоритмах.
Ключевой момент моей фразы " древнему ". Собственно вся статья об этом. MD5 - мгновенно, bcrypt - чуть дольше.
Собственно есть целая палитра взломщиков и способов. На одном конце спектра есть обычный человек как вы - вы на вашем компьютере ничего особого сделать не сможете (кроме MD5 или совсем коротких паролей завернутых в bcrypt). На другом есть заинтересованные люди побогаче (разведки крупных стран) которые активно эксплуатируют чужие утечки. Между ними целая палитра возможностей.
Про методику XKCD 936 нет внятного ответа. Из статьи ясно, что 4 слова без пробела подбираются «быстрее 14 квадриллионов лет».
А методика удобная. Из неожиданного: такое удобно перепечатывать с другого экрана и вводить на виртуальных клавиатурах.
И неудобно, когда сайт ограничивает максимальную длину пароля или запрещает пробелы („ваш пароль слишком надёжный; пожалуйста, выберите менее надёжный пароль“). Или требует к отличному паролю добавить какой-нибудь глупый знак, чтобы разработчикам сайта было спокойнее.
Я видел крутой валидатор пароля на сайте, который оценивал энтропию пароля, и заполнял шкалу. Она росла с каждым новым знаком, резко падала от словарных слов, резко росла при добавлении необычных символов и т.п.
Идеально!
Проверялка на сайте с обратной связью (не тащить же в браузер весь словарь?) - это как-то стрёмно.
Там мог быть небольшой словарь. Тысяча самых популярных паролей, плюс пара тысяч слов — это 20 кБ. На фоне 20-мегабайтных джаваскриптов на самых модных сайтах это ерунда.
А главное — это для безопасности. Компании любят говорить, что их главный приоритет — безопасность. Вот пусть делают хорошую проверялку паролей, не пожалеют 100 кБ на отдельной странице, покажут свою заботу на деле.
Самая большая проблема паролей -- программисты, которые решают понаставить фильтров, чтоб пользователь ни в коем случае не поставил пароль, который ему хочется. Вариантов миллион: от странных "пароль не должен превышать 20 символов" до смешных, когда требуется, чтоб в пароле "не было рядом стоящих повторяющихся цифр" и "должны быть следующие спецсимволы: !_+=-*?" (остальные спецсимволы таковыми не считаются".
Зачем -- непонятно. Мало того, что это уменьшает секьюрность паролей (из перебора можно исключить не подходящие комбинации), так это еще и не дает пользоваться общим для всех сайтов алгоритмом генерации паролей и приходится для этого случая придумывать что-то, что потом ни за что не вспомнишь (ведь у тебя есть алгоритм, ты знаешь, что здесь пароль должен быть такой, но он не подходит). А взламывают в итоге все равно не подбором пароля а через утечку хешей или кражу токена авторизации.
Причём, один из таких "умников" - это Яндекс, в моём случае он не принимает некоторые печатные спецсимволы, поэтому использовать свой генератор паролей для него проблематично.
Последний раз проверял около года назад.
В их же копилку то, что они не поддерживают стандартные 2FA TOTP, а просят скачать их чёртов Яндекс.Ключ, который мне 100 лет не сдался.
очень настойчиво просят, но, обычный тотп все же тоже можно использовать. Порой надо войти, раз в 100 лет, а тебе суют какие-то ребусы, выбери картинку или что у них там, какой-то яндекс ключ, чего. А потом вспоминаешь что через тотп войти можно. И на том спасибо
Подтверждаю слова @lisisty. Яндекс.Ключ можно заменить на любое приложение TOTP. Там есть ссылка на получение секретного ключа.
Раньше они использовали свои велосипеды и было не возможно. Сейчас действительно, попробовал, и даже QR-код отсканился обычным гугловским аутентификатором. Спасибо, что сказали.
Но они не предоставляют коды для восстановления! Или я их не нашел. Для включения 2fa потребовалось привязать телефон, и, похоже, единственный способ восстановления доступа в случае чего - через телефон, что опять какой-то свой уникальный путь.
Это просто праздник какой-то :)
Зачем -- непонятно.
Могу подсказать - зачем. Скорее всего у сервиса имеется какой-то махровый легаси-кроваво-энтерпрайзный бекенд, написанный черт знает на чем черт знает когда.
И есть требование хранить данные там, а у поля — вот такие ограничения.
Т.е. скорее всего если вы видите такую ересь - пароль хранится плейнтекстом, ага.
Если 1 пароль можно захешировать за разумное время (а это необходимо чтобы этим пользоваться на практике), то и 10^4 паролей будут хешироваться не долго. Даже если хеширование занимает 1 минуту, то перебор всех четырехзначных цифровых паролей займет меньше 17 часов (и это без ферм карт, а на таком же сервере, что и атакуемые сервис).
Так для этого и нужен длинный пароль, чтобы каждым хешем надо было заниматься отдельно, а не за пару часов перебрать всю базу в сотню-другую тысяч пользователей. Мне кажется логичным, что надо предполагать, что взломщик как-то в этом заинтересован и ломает не на core2duo (или даже epyc или xeon), а как минимум на пачке видеокарт, что увеличивает скорость даже не знаю на сколько порядков.
1234 на 16-ом месте по популярности в 2023 году, кстати.
Вы не влияете на то, как будут храниться ваши пароли, может с PKDF, а может открытым текстом и тогда вас не спасет даже 140 символов. Ну и про всякие искусственные ограничения на пароли (видимо для облегчения их взлома) - это тоже прямо беда. Решение пока только в том, чтобы жестко действовать по правилу: один сервис - один пароль. Минус в том, что надо заводить кучу паролей, и хранение их в менеджере паролей не всегда надежный выход - это становится единой точкой отказа с точки зрения безопасности.
Второе - ну хорошо, на нормальной клавиатуре можно вводить многосимвольные пароли со спецсимволами, а что делать на смартфонах? Вводить тамошней клавиатурой даже 16 символьный пароль - одно мучение. Речь именно про ввод, т. е. там где вставка из кармана не работает, например пароль на разблокировку телефона. Причем нормального решения нет, замена на биометрию - это не решение (да и не замена). Разве что носимые ключи безопасности на bluetooth/nfc могут что-то предложить, но их поддержка в телефонах на зачаточном уровне.
на нормальной клавиатуре можно вводить многосимвольные пароли со спецсимволами, а что делать на смартфонах?
Особый цимес с паролями "набирай в английской раскладке русскими буквами", ага
Стало интересно за какое время я ввожу 16-символьный случайно сгенерированный пароль на телефоне. Оказалось чуть меньше 9 секунд. На практике никаких мучений, немного практики, и сейчас это больше похоже на соревнование на скорость ввода. Хотя это ввод с 2 рук, одной будет явно дольше.
Какие должны быть пароли в 2024 году?
В 2024 году не должно быть паролей.
интересно выслушать альтернативы, которые вы предлагаете
Passkeys/WebAuthn а также варианты на тему SAML/OAuth, если самому с их поддержкой возиться не хочется, работают уже почти везде.
если я правильно понял, то это никакая не замена.
Вам нужно "доверенное" устройство для подтверждения. Чтобы разблокировать это устройство (телефон/пк/etc), вам опять же нужен пароль или биометрия, которая тоже не является заменой пароля. В итоге это устройство становится точкой отказа.
Ваш телефон сломался? Как вам настроить эту систему на новом? И вот вы опять вводите пароль.
Использование парольного менеджера, в сравнении с этим, ничем не хуже.
Да, какой-то credential вам всегда будет нужен. Но при этом он ни в каком виде (даже в виде hash) на сервере куда вы аутентифицируетесь уже не хранится, а значит один потенциальный источник утечки устраняется.
В итоге это устройство становится точкой отказа.
Ваш телефон сломался? Как вам настроить эту систему на новом? И вот вы опять вводите пароль.
Это верно только если используется один телефон. Если их больше - то инициализацию нового устройства можно подтвердить на оставшихся, не вводя никаких паролей. Тот же гугл с андроидом так умеет. Вот буквально спрашивает "тут на устройстве XYZ пытаются в учетку залогинится, пустить?"
Но вот что доверенных артефактов входа должно бы быть больше одного - это зря не объясняют.
TOTP и его друзья.
Сейчас, к сожалению, многие сайты, чтобы сбросить пароль, используют SMS с числовым кодом, что в принципе делает бессмысленными длинные пароли: ну допустим, взламывать пароль нужно 10 миллионов лет, а четырёхзначный код из SMS с первой попытки угадывается с вероятностью 0.01%. Ладно бы это где-то настраивалось (хочешь — используй код с длиной по умолчанию, а хочешь — вводи хоть двадцатичетырёхзначный код из цифр, букв и специальных символов).
Там же 0.0001%, не? В каждой новой сессии подбора такая вероятность, это очень низкий шанс. Коды ведь не исключаются после отправки, это не пароли - не подошло, пометил неверным, каждый раз выбирается новый из диапазона 0000-9999. И коды сессионные, через несколько попыток подбора или определённое время требуется отправка нового, а с ним всё заново нужно начинать, с той же вероятностью угадать.
Вероятность подбора 1/10000, то есть, 1/100 процента (0.0001 или 0.01%), при этом попыток на один код может быть несколько. Допустим, три попытки, тогда вероятность взлома одного кода — 0.03%. Тоже не очень много, но, при этом, если процесс подбора пароля будет автоматизирован, используя разные IP-адреса, то 10 тысяч вариантов могут перебрать достаточно быстро. Но там, понятно, сложность в том, чтобы иметь ботнет из нескольких тысяч узлов.
Как вариант — взламываться могут разные сайты (то есть, не атака на какого-то конкретного пользователя, а просто наугад, чтобы хоть кого-то взломать), тогда количество IP-адресов для взлома (чтобы не забанили по IP) будет меньше. Далее, если речь идёт о какой-то известной личности, например, чьи фотки очень многие хотели бы посмотреть, и чей телефон стал известен, то там могут несколько тысяч разных людей попробовать, и этого может быть достаточно, чтобы у кого-то из них получилось.
Да и в целом, часто на сайтах нас просят сделать безопасный пароль (большие и маленькие буквы, цифры, специальные символы), а, при этом, сами уменьшают стойкость защиты используя коды из SMS. Обидно. Если тупо выбирать случайным образом пароль из первых 10001 в списке наиболее часто используемых паролей, то это видимо будет надёжнее, чем восстановление пароля по SMS с кодом из четырёх десятичных цифр.
На количество одноразовых паролей в единицу времени тоже обычно ставят ограничение (еще и потому, что сервису надо платить за каждую смску), реальный человек за минуту 100 одноразовых паролей не запросит. Больше 5 одноразовых паролей на операцию - подожди час, выглядит подозрительно.
В смысле перебрать десять тысяч вариантов достаточно быстро? Каждая новая сессия высланного смс требует угадывания с условно трёх попыток из десяти тысяч вариантов. Ранее высланные коды не исключаются из диапазона перебора, в этом же и идея, нельзя запросить 10000 смс и в последнем смс гарантированно угадать код, так не работает или я не понимаю, о чём тут речь.
10000 вариантов - это не очень много. Если лимитов на SMS нет (а если они есть, то это возможность блокировки легального пользователя ложными запросами), то 10 тысяч вариантов - это, допустим, около недели, если перебирать в среднем по одному варианту в минуту. А если перебирать будут параллельно для разных аккаунтов разных сайтов с разных IP-адресов, то скорость может быть и выше.
Как понять-то про около недели? Это может быть бесконечно долго, если не угадать. Вероятность угадывания в каждой сессии не зависит от других сессий. Что там параллелить? В первом смс 1245, скажем, во втором 5674, в третьем 2222, в четвёртом снова 1245, они же не исключаются, каждая новая сессия независима. Каждый раз - три попытки угадать единственную комбинацию из десяти тысяч.
Для 4-значного OTP и 3 попытках ввода на каждый. Это шанс угадать 0,03%
Теперь представь, что ты каждую минуту играешь в эту лотерею. Думаю статистически можно оценить шансы.
Это может быть очень долго если не повезёт. При этом, если вероятность не угадать в результате одной попытки равна 0.9999, то, скажем, вероятность не угадать за 7000 таких попыток будет уже менее 50% (скорее угадаешь, чем не угадаешь).
Но ведь тут злоумышленник должен владеть правильной симкой - в этом случае OTP должен устоять лишь пока истинный владелец не вернет контроль на симкой, либо не предпримет какие-то еще действия. А это скорей всего от пары часов, до пары дней.
А как вообще подбирают-то? Как понимают, что пароль подобран правильно?
А ещё забавно когда в валидаторе пишут что пароль должен быть не меньше 8 символов, но НЕ БОЛЬШЕ 12
Причём на каком-то серьезном посещаемом сайте такое было
Чем старее и "круче" банк тем тупее у него требования к паролям. Когда-то у CBS, кажется, требование к "паролю" было - ровно 6 цифр.
А имя пользователя, типа: O&wPAwi*SNT0+u8h? :))
Да если бы :)
Еще я помню как пытался поставить 6-значный PIN на карточку. Стандарт это позволяет как бы. И софт в в пин-паде это определенно поддерживал. А вот софт в самом банкомате - к сожалению нет. Поэтому мне банкомат напечатал сообщение об ошибке через принтер. Но по ходу где-то налажал с длинной текста или терминирующим символом, потому что после сообщения об ошибке мне принтер напечатал еще два метра бумаги с кусками содержимого памяти. При чем там можно было найти интересные штуки типа выписки предыдущего клиента с остатком на его счету.
Когда я описал эту проблему техподдержке они мне ответили "ну не надо пробовать ставить такой длинный PIN, позязя".
Мда. Я не в первой вижу что люди как бы невзначай экстраполируют Профит от сложности пароля. На самом же деле он с определённого числа символов в принципе теряется. Почему? Потому что коллизии. Подбор пароля не обязывает вас угадать точно тот единственный пароль который ввёл юзер. Подойдёт любой из бесконечного числа подходящих под заданный хеш вариант. То есть под один хеш подходит бесконечное число паролей. Зная это, хеши всё ещё выглядят безопасными для вас?
Тейки о необходимости двух факторной авторизации, где надо ввести 4-6 цифр, которые в принципе можно случайно и угадать - тоже дичь, как по мне. Борьба с брутфорсом в общем то ни к чему и не привела.
То есть под один хеш подходит бесконечное число паролей.
Звучит серьезно. И есть оценки повторяемости? Скажем, если у нас есть триллион паролей (длиной не более 12 символов), сколько "пар" разных паролей будут иметь одинаковый хеш? "Троек" паролей захешированы одной последовательностью (т.е. любой из этих трех паролей подойдет)?
Оценку повторяемости дать очень легко: делим количество возможных паролей на количество возможных значений хеша и получаем, сколько на один хеш в среднем приходится паролей. Хотя, если я не туплю, то с хешами достаточно большой длины (например, 256 бит) вероятность коллизии получается очень небольшая, даже при длине пароля, выходящей за разумные пределы. То есть, вариантов паролей гораздо меньше, чем возможных значений хеша.
А если брать виндовые пароли, то 2 половинки по 7 символов, приведенных к большим буквам, т.е. словарь исходно не по 128-32=96 символа, на 26 меньше, т.е. 70 символов, и генерируя хэш от коротких паролей, можно подобрать и простые последовательности.
И у windows была? уязвимость удаленных соединений, можно было получить хэш паролей и пользоваться хэшем без расшифровки.
То есть под один хеш подходит бесконечное число паролей. Зная это, хеши всё ещё выглядят безопасными для вас?
Если я правильно понимаю суть хэширования, то коллизии неизбежны, когда длинна исходного пароля превышает длину хэша. Но для стандартного 256-битного хэша это получается длина пароля должна быть от 32 символов. Если ваш пароль короче, то вероятность коллизии
del (перенес в правильную ветку)
del
А по-моему лучший пароль это пароль, который нигде не записан :) Еще и по заветам Перельмана - какие-нибудь "Усы застряли в машине дурацким образом" русскими буквами в английской раскладке с одновременной заменой всех з на 3, о на 0, а ш на #
русскими буквами в английской раскладке с одновременной заменой всех з на 3, о на 0, а ш на #
Это замечательно до тех пор пока вам не потребуется ввести этот пароль не с нормальной клавиатуры, а на смартфоне например.
какие-нибудь
(запуская так и не дописанный генератор парольных фраз)
"В постовом макете растёкся хрип тряпочных леек" - В процессе генерации использовано 70 бит энтропии.
"управление дворца сгущалось его рычанием" - 41 бит
"уменье кагора светит в льготе статного харчо" - 65 бит
Не использовать редкие слова - длину фразы нужно увеличивать.
Больше ну пусть дюжины таких помнить порядком трудно.
русскими буквами в английской раскладке с одновременной заменой всех з на 3, о на 0, а ш на #
А этого вообще не вспомнишь, где какие замены делал, если пароль не используешь постоянно и без перерыва. В отпуск ушел - и все замены из головы выветрились. Так что увы, с паролями (точнее со способностью их запоминать) у людей все плохо.
Можно выработать постоянно используемый вариант для замены символов, чтобы добавлять в пароль цифры и другие символы. Если, допустим, Ш всегда заменяется на #, то путаницы не будет, при этом в пароли, основанные на тех или иных фразах, будет попадать этот символ, т.е. уже не сработают варианты, где подбирается пароль исходя из предположения, что используются только буквы или буквы с цифрами.
Географические названия неплохо походят.
Ыгыатта интригующе отражала Луну не по Снеллиусу
Прилетел размеренно автобус Тируванантапурам--Вадуц
Публикации
Какие должны быть пароли в 2024 году?