Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 104
Эвон как.
Мне кажется стоит описать что такое радужные таблицы, и почему именно SSD позволяет делать такие вещи…
А так спасибо за статью.
А так спасибо за статью.
Про радужные таблицы очень хорошо написано в английской Википедии. Обратите внимание на иллюстрацию.
SSD диски позволяют увеличить скорость, потому что они обладают огромной скоростью случайного считывания(не тратится время на передвижение считывающей головки), и у них уже приемлемые размеры. Раньше для достижения высокой скорости радужные таблицы помещали в оперативную память, например, но это очень дорого.
SSD диски позволяют увеличить скорость, потому что они обладают огромной скоростью случайного считывания(не тратится время на передвижение считывающей головки), и у них уже приемлемые размеры. Раньше для достижения высокой скорости радужные таблицы помещали в оперативную память, например, но это очень дорого.
эка невидаль — пароль по rainbow table подобрать. наверное, надо чтобы он там сначала был?
кто где был? пароль в таблице?
да, пароль в таблице.
ну глупость же сказали, даже язвить не охота…
Вы наверное просто не вполне знаете что такое радужные таблицы… Перечитайте
Генерируются пароли (редко когда по словарям, в основном по маскам и складываются в отдельные хранилища), для каждого пароля калькулируется его хэш и укладывается пара хэш/пароль в некое хранилище (которое в статье как раз и разместили на SSD за счет чего получился прирост в скорости).
Радужная таблица создается построением цепочек возможных паролей. Каждая цепочка начинается со случайного возможного пароля, затем подвергается действию хеш-функции и функции редукции. Данная функция преобразует результат хеш-функции в некоторый возможный пароль. Промежуточные пароли в цепочке отбрасываются и в таблицу записывается только первый и последний элементы цепочек.
Я не крипто-матан-гуру, но моих скромных знаний и практического опыта хватает, чтобы оценить высказывание товарищей выше, как полную абсолютную ересть :)
Хранить хеши в хешах перестали ещё до основания вхб ))
Таблица генерируется под определённый словарь и размер, если есть таблица допустим md5_mixalpha_numeric_1_8, то она расколет любой md5 в этом диапазоне (с вероятностью в ~99.9% в зависимости от настроек при генерации). Как там не может быть _того_самого_пароля_?
Опять же, как уже сказали ниже про 14 символов в винде, что это не совсем так, rainbow tables для 14 символов фантастика даже на ssd.
Хранить хеши в хешах перестали ещё до основания вхб ))
Таблица генерируется под определённый словарь и размер, если есть таблица допустим md5_mixalpha_numeric_1_8, то она расколет любой md5 в этом диапазоне (с вероятностью в ~99.9% в зависимости от настроек при генерации). Как там не может быть _того_самого_пароля_?
Опять же, как уже сказали ниже про 14 символов в винде, что это не совсем так, rainbow tables для 14 символов фантастика даже на ssd.
Интересно — сколько времени требуется на создание радужных таблиц, например md5 для 0..10 символьных паролей?
Вам так доставляет удовольствие пустое теоретизирование?
1) Даже ssd не нужно, ну да )) и все хранилищей гугла не нужно, потому что всё равно не хватит =)) Я про то, что 14 это не 14, если не понимаешь, погугли.
2) И, не скажем 98%, потому что это значение точно высчитывается при расчёте настроек генерации, success rate. и составляет минимум 99.9 по дефолту если речь идёт о распределённой генерации (а о другой и не может быть речи).
1) Даже ssd не нужно, ну да )) и все хранилищей гугла не нужно, потому что всё равно не хватит =)) Я про то, что 14 это не 14, если не понимаешь, погугли.
2) И, не скажем 98%, потому что это значение точно высчитывается при расчёте настроек генерации, success rate. и составляет минимум 99.9 по дефолту если речь идёт о распределённой генерации (а о другой и не может быть речи).
К тому же про 14 символов это не совсем честно, ибо пароль состоит из 2 частей по 8, если не ошибаюсь. И надо найти обе части. Реально насчитанный массив всех комбинаций был бы довольно большим.
В xp, введенный пароль дополняется нулями до 14ти символов, делится на 2е части по 7 байт и каждая часть шифруется DES. В большинстве случаев, этот факт только упрощает перебор ввиду того, что пользователи не любят 14ти значные пароли. Если пароль например 10 значный, то затратно подобрать первую чать из 7ми символов и совершенно просто подобрать вторую всего из 3х символов.
Так было до SP3, теперь же полученный из 2х половинок хэш, еще раз шифруется целиком утилитой syskey, что затрудняет посимвольный брутфорс, но естественно не спасает от подбора по радужным таблицам.
Так было до SP3, теперь же полученный из 2х половинок хэш, еще раз шифруется целиком утилитой syskey, что затрудняет посимвольный брутфорс, но естественно не спасает от подбора по радужным таблицам.
Да-да, до SP3. До Windows NT 4.0 SP3.
Это алгоритм вычисления LM hash, далее из википедии:
При присоединении к домену дефолтные политики вроде бы отключают использование устаревшего хеша.
Windows systems before Windows Vista/Windows Server 2008 still compute and store the LAN Manager hash by default for compatibility with LAN Manager and Windows Me or earlier clients, as well as some 16-bit applications...
При присоединении к домену дефолтные политики вроде бы отключают использование устаревшего хеша.
у меня в XP пароль был из 18 символов, винда откидывала все после 14го символа?
просчитанные радужные таблицы для NTLM можно поискать на торрентах, больше 100 гигов в распакованном виде.
кстати это не совсем взлом — все же надо сначала добыть хэш :) потом просто идет поиск.
кстати это не совсем взлом — все же надо сначала добыть хэш :) потом просто идет поиск.
тихо, не мешайте 3lit3 hak0rz взламывать хеши паролей, а то мы никогда не узнаем о «комплексных подходах» вот из этого пассажа:
«Данная демонстрация достаточно убедительно показывает, что использование для защиты данных только пароля уже давно является крайне недостаточным. Для надежной сохранности данных следует использовать комплексный подход.»
«Данная демонстрация достаточно убедительно показывает, что использование для защиты данных только пароля уже давно является крайне недостаточным. Для надежной сохранности данных следует использовать комплексный подход.»
для подбора таких сложных паролей нужны очень большие rainbow таблицы, счет идет на террабайты. Их можно купить, но стоят они очень не дешево а генерировать их самому займет годы, если использовать домашний пк пож эту задачу. Стало быть доступно это не будет для рядового «хакера», а те люди кто может себе позволить такие мощности и финансовые траты не будет «красть вашу почту». Тем более чтобы было что подбирать (md5 хеш например) его нужно откуда-то достать, бд сайта или куки, тоесть в цепочке безопасности md5 хеш вашего пароля не есть единственное звено что еще больше усложняет задачу абстрактного взлома вашего аккаунта вконтакте.)
Сходу могу предложить «швейцарской компании» еще увеличить скорость восстановления исходного значения хеша в 1,5-2 раза за счет использования дисков на RAM памяти ( www.xbitlabs.com/articles/storage/display/ssd-iram.html ), если, правда, денег хватит.
Сразу после этого пусть на нобелевку подают.
Сразу после этого пусть на нобелевку подают.
Непонятно, если в hash участвует salt, то каким образом могут помочь такие маленькие радужные таблицы за 5 секунд. Если не участвует, то возникает недоумение, неужели в XP salt не используется?
Убийственной полезности пост.
Вообще-то LM таблица (альфанумерик+символы) занимает что-то порядка 7Гб — ее и в память положить можно, безо всякого SSD.
Вообще-то LM таблица (альфанумерик+символы) занимает что-то порядка 7Гб — ее и в память положить можно, безо всякого SSD.
случайно создаваемая (но постоянная в рамках определнной системы) соль для каждой системы сольет все эти таблицы в мусор
Ну а на практике-то толку нет на самом деле. Все наши самый важные пароли лежатн а серверах.
Какой-нибудь гугл- через неверных запросов 5 уже капчу выдает, а через еще пару десятков наверняка на сутки закроет доступ, или что-нибудь в этом роде.
А этой программе нужны миллионы запросов, причем за считанные секунды.
Какой-нибудь гугл- через неверных запросов 5 уже капчу выдает, а через еще пару десятков наверняка на сутки закроет доступ, или что-нибудь в этом роде.
А этой программе нужны миллионы запросов, причем за считанные секунды.
Ей не нужны миллионы запросов. Ей нужен хеш. Который с сервера «законным» способом скорее всего не заберешь.
Ну, всё равно ведь она при переборе постоянно сранивает имеющийся хэш с тем, который нужно подобрать. Это и есть условно запрос.
1. получаете хэш с сервера на работе или в инете
2. дома подбираете к нему пароль
3. вводите пароль на сервер
4. ???????
5. PROFIT
2. дома подбираете к нему пароль
3. вводите пароль на сервер
4. ???????
5. PROFIT
А с какой стати сервер отдаст хэш?
М.б. потому что в нем дыра, которая позволяет слить хэши, но не позволяется записать свой хэш или обойти аутентификацию?
Хорошо попросить (загрузиться с флешки или винт в другую машину поставить на время на работе, сделать SQL-injection в инете и т. п., и т. д.) — отдаст ;)
Собственно поэтому и говорю, что одним только подбором задача не решается, поэтому и паниковать рановато.
Задача подбора пароля к известному хэшу по радужным таблицам с использованием SSD дисков значительно ускоряется по сравнению с «обычными» дисками. Собственно об этом и топик, как я понял. Паниковать или нет каждый решает сам.
Да. Но в топике в том числе высказывается мысль о том, что мол пароля в наши времена уже ой как недостаточно.
Мне же этот тезис показался сомнительным. И так оно и есть.
Всё же если на сервере нет дыры размером с кратер Коперник — то подбор попросту применить негде.
И наоборот: при дырявости сервера, скорость подбора уже не столь и принципиальна.
Мне же этот тезис показался сомнительным. И так оно и есть.
Всё же если на сервере нет дыры размером с кратер Коперник — то подбор попросту применить негде.
И наоборот: при дырявости сервера, скорость подбора уже не столь и принципиальна.
Расширенный ASCII можно юзать в XP. У меня по крайней мере был пароль вроде «☺пароль☻».
> пароль вроде «☺пароль☻».
и как вы его вводили?
и как вы его вводили?
не надоедало при каждом логине вводить?
а Вам не надоедает вообще пароли вводить при каждом логине?
Нет. Помимо системного пароля я ввожу ещё пароли на зашифрованные диски, причём их — намного чаще. И «Lock workstation» делаю при каждом походе на кухню за чашкой чая )
Это ж сколько денег на Игруне можно «выиграть», если он так хеши разлочивает
Солите и маринуйте. Совет от моей бабушки.
С моей точки зрения автор в своей статье дезинформирует нас, утверждая что подбор при помощи GPU медленнее чем при помощи SSD. Но это заявление в принципе не корректно! В случае использования GPU используются огромные математические вычисления, а в случае использования SSD используется высокая скорость доступа к уже просчитанным данным.
Выражаю яркий антиреспект автору.
Выражаю яркий антиреспект автору.
Речь лишь о том, что размещать радужные таблицы в видеопамяти космически дорого. А вот на SSD — вполне по карману.
Вы их размеры видели?! Посмотрите выше, упоминается к примеру 100 ГБ. А какой видеопамяти идет речь?! Вы что?
Зачем вообще заводить об этом речь? И вообще, зачем радужные таблицы в видео памяти? По радужным таблицам и без этого перебор идет колоссально быстро.
Зачем вообще заводить об этом речь? И вообще, зачем радужные таблицы в видео памяти? По радужным таблицам и без этого перебор идет колоссально быстро.
> По радужным таблицам и без этого перебор идет колоссально быстро.
Ага, а применение SSD еще на пару порядков ускорило этот и без того быстрый перебор. И всего делов. Если раньше для ускорени мутили RAM-диски колоссальной стоимости, то сейчас пачками покупают быстрые твердотельные накопители.
«Размещение радужных таблиц ввидеопамяти» — это лишь утрирование. А вы сразу в стойку — «Да не бывает столько видеопамяти!» Спокойнее надо :)
Ага, а применение SSD еще на пару порядков ускорило этот и без того быстрый перебор. И всего делов. Если раньше для ускорени мутили RAM-диски колоссальной стоимости, то сейчас пачками покупают быстрые твердотельные накопители.
«Размещение радужных таблиц ввидеопамяти» — это лишь утрирование. А вы сразу в стойку — «Да не бывает столько видеопамяти!» Спокойнее надо :)
Хотел бы поднять вопрос насколько SSD быстрей HDD, что так выгодно на них крутить таблицы? На шесть порядков штоле?
Эти результаты говорят лишь о том, что хеш-функция выбрана плохая.
Всего паролей из букв+цифр (62 символа) длиной 14: 62^14 = 12401769434657526912139264 > 10^25. Если мы перебираем по миллиарду (10^9) паролей в секунду, то нам понадобится 10^16 секунд > 100 миллионов лет.
Всего паролей из букв+цифр (62 символа) длиной 14: 62^14 = 12401769434657526912139264 > 10^25. Если мы перебираем по миллиарду (10^9) паролей в секунду, то нам понадобится 10^16 секунд > 100 миллионов лет.
Это если перебирать генерируя через хеш-функцию, но если используется радужная таблица, то она как бы отсортирована по хешам и тогда отыскать в ней хеш пустяк, если он там есть.
Ок. Если мы генерируем по миллиарду паролей в секунду, то на генерацию нам понадобится более ста миллионов лет.
Кроме того, если мы маги и способны хранить данные для каждого пароля в одном байте, нам понадобится примерно 10 йоттабайт на хранение этих таблиц, что несколько больше суммарной емкости всех накопителей, созданных к текущему моменту.
Кроме того, если мы маги и способны хранить данные для каждого пароля в одном байте, нам понадобится примерно 10 йоттабайт на хранение этих таблиц, что несколько больше суммарной емкости всех накопителей, созданных к текущему моменту.
RSA ключи и длина хеша бит так в 512 нас спасут
Тут представлен очень короткий хэш. В реальной жизни там хэш будет по 2 килобита — можно хоть обвосстанавливаться :)
Всё равно странно как-то.
Сказано что 300 миллионов паролей в секунду.
А теперь считаем: допустим все варианты англ букв + цифры = 26+26+10 = 62 комбинации. Далее берем допустим пароль 13 символов. Значит всего комбинаций пароля: 62^13 = 200028539268669788905472 вариантов пароля.
Если подбор будет 300 млн в сек, то потребуется 666761797562232 секунд для перебора всех комбинаций, что сравнимо с 21 миллионом лет.
Сказано что 300 миллионов паролей в секунду.
А теперь считаем: допустим все варианты англ букв + цифры = 26+26+10 = 62 комбинации. Далее берем допустим пароль 13 символов. Значит всего комбинаций пароля: 62^13 = 200028539268669788905472 вариантов пароля.
Если подбор будет 300 млн в сек, то потребуется 666761797562232 секунд для перебора всех комбинаций, что сравнимо с 21 миллионом лет.
Если у вас каким-то образом оказались хеши паролей пользователей windows xp какого-нибудь домена ad, то «расшифровывать» их вам не нужно, у вас ключи от дверей. Ваш К.О.
Чёрт с ним, с NTLM, но я так понимаю, что за соизмеримое при соизмеримых затратах дискового пространства можно находить ключи WiFi WEP2-PSK AES?! Это же ужас и кошмар!
теперь можно из МД5 хешей фильмы востанавливать! =)
похоже надо возвращаться к моим старым паролям длиной от 30 букв
раньше их мало где можно было использовать
но теперь сервисы снимают эти дурацкие ограничения на длину паролей
раньше их мало где можно было использовать
но теперь сервисы снимают эти дурацкие ограничения на длину паролей
Можно ли применить данную разработку к перебору пароля на архив из ~70 символов? Очень надо вскрыть домашний архивчик =) готов оказать материальную поддержку тому, кто поможет организовать взлом (ничего противозаконного. реально лично мой один архив. без всякого криминала.)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подбор 14 символьного сложного пароля за 5 секунд