 Пароли Windows абсолютно ненадёжны. ОФкрак в действии
 Пароли Windows абсолютно ненадёжны. ОФкрак в действии 
Создана: 09 Июля 2008 Срд 17:46:05.
Раздел: "Компьютерная безопасность, коды, доступы и т.д."
Сообщений в теме: 23, просмотров: 10744
- 
А вы знаете, что для взлома пароля Windows наподобие Jn8Cjkywf9 любому желающему требуется менее одной секунды? Если не знали, то теперь знайте, что всё обстоит именно так. И не важно, какая система, XP или какая-нибудь Vista, любая система Windows хранит хэши паролей пользователей. Предполагается, что в хэше надёжно зашифрована информация, что на взлом пароля понадобится много времени и ресурсов... Увы, на самом деле всё гораздо проще. Достаточно один раз заранее просчитать хэши для возможных комбинаций паролей, занести в гигантскую базу данных, и после этого вместо взлома пароля просто брать из базы готовый ответ. Разумеется, всё это уже сделано, и посмотреть в действии можно по этой ссылке:
 http://www.objectif-securite.ch/
 
 Вводим хэш пароля, например,
 f00879b09f473413db6c67d5f1f76de9:3138968e2b8ef3d24b6a8142297f718f
 в ответ сразу получаем расшифрованый пароль: Jn8Cjkywf9
 
 С того же сайта можно скачать программку ОФкрак (ophcrack), которая даёт возможность любому желающему извлекать хэши из Windows-копьютеров и расшифровывать их. Есть и множество других программок на эту тему, желающие легко найдут их в сети.
 
 Как же быть? Ну, во-первых, можно воткнуть в свой пароль всякие спесцимволы. Самые крутые спецсимволы - это русские буквы. Вероятность взлома пароля со спецсимволами и русскими буквами намного ниже, по сравнению с традиционными алфавитно-цифровыми. Хотя конечно, сам принцип уже проиллюстрирован и ничто не мешает просчитать все комбинации паролей с учётом и русских букв, и спецсимволов, чтобы занести их в базу данных и взламывать любой хэш за доли секунды...
- 
- 
- 
- 
CrOm-cheg писал :он по моим данным белиберду выдал вместо реального пароля :он по моим данным белиберду выдал вместо реального пароля
 Некоторые (а может и большинство) функции шифрования не гарантируют уникальные выходные последовательности от уникальных входных. Т.е. как ваш реальный пароль, так и кракозябра что вы получили могут давать один и то же хэш. Попробуй воспользоваться советом АлексАдмина, должен подходить =)
- 
- 
KriG писал : :
 Некоторые (а может и большинство) функции шифрования не гарантируют уникальные выходные последовательности от уникальных входных. Т.е. как ваш реальный пароль, так и кракозябра что вы получили могут давать один и то же хэш. Попробуй воспользоваться советом АлексАдмина, должен подходить =)
 
 exactly!
 Это же хэш - а он и в Африке хэш.
 char* hash=f(char* password){ bla-bla-bla} /типа того..давно шашкой не махал -точность не гарантирую, но за смысл отвечаю/ Т.е. вашему паролю, преобразованному в хэш, соответствует бесконечное множество паролей (в свою очередь, тоже преобразованных в хэш). Простейшая хэш-функция - выдать остаток от деления на 2 хреновой тучи байтов, поданых на вход - в ответе либо 0, либо 1. Аргумент фунции - это ваш пароль, а взломать ваш пароль можно максимум за две попытки. И CRC практически в ту же степь.
 
 /Во мне сдох и воняет преподаватель всяких всячин - прошу извинить/
- 
 
 хэш можно получить массой способов, ну вот хотя бы парочка ссылок
 
 программа fgdump
 
 [внешняя ссылка]
 
 программа pwdump
 
 [внешняя ссылка]
 
 программы выдают файлик с расширением .pwdump
 затем его можно открыть любым текстовым редактором, нотепадом хотя бы, в нём все юзернеймы и хэши паролей.
 
 а сам файлик .pwdump можно скормить любой паролеломалке, хоть ОФкраку, хоть ЛЦП. Лофткрак тоже наверное съест (нет под рукой проверить).
 ЛЦП качать отсюда:
 [внешняя ссылка]
 
 кстати, LCP тоже умеет хэши выдёргивать, но делает это криво, можно вывалиться на "синий фон".
- 
- 
Прога Windows Key Enterprise Edition 8.0 к примеру, вставляем загрузочный диск с прогой-1 минута и пароля больше нет, вытаскиваем диск, перезагружаемся-готово, вводить ничего не надо, пароль просто сбрасывается будто его и не было
- 
В большинстве случаев все гораздо проще. Если систему ставил не шарящий чел, то на учетку одмина пароль не ставил. Т.е. можно преспокойно зайти под пользователем "Администратор" с пустым паролем. Если пароль есть то тоже не проблема :) загружаете машину с сд/флешки, вот вам и физический доступ :) Выдергиваете нужный файл, брутфорсите ,получаете пароль :)
- 
 как правило требуется чтобы хозяин пароля ничего не заподозрил.Ж3 писал :Прога Windows Key Enterprise Edition 8.0  к примеру, вставляем загрузочный диск с прогой-1 минута и пароля больше нет, вытаскиваем диск, перезагружаемся-готово, вводить ничего не надо, пароль просто сбрасывается будто его и не было :Прога Windows Key Enterprise Edition 8.0  к примеру, вставляем загрузочный диск с прогой-1 минута и пароля больше нет, вытаскиваем диск, перезагружаемся-готово, вводить ничего не надо, пароль просто сбрасывается будто его и не было
- 
Админам (да и пользователям) винды можно дать следующие рекомендации:
 
 1. Включить на уровне групповых политик требование по сложности пароля. Тогда пользователи не смогут вводить тупые пароли, состоящие только из латиницы и цифр. На локальных машинах эта настройка доступна из secpol.msc.
 
 2. Отключить на уровне групповых политик LM-хэши. Почти у всех эти хэши включены, т.к. они включены по умолчанию в виндовзах вплоть до Server 2003. Эти хэши используются только для 95/98/ME, поэтому в подавляющем большинстве случаев никаких проблем в связи с отключением LM-хэшей не будет.
 
 При отключенных LM-хэшах злоумышленнику придётся ломать NT-хэши, что сложнее. Базы радужных таблиц (т.е. таблиц с предварительно вычисленными хэшами для всех комбинаций паролей) для NT-хэшей имеют нереально огромные размеры (десятки гигабайт) и высчитаны только для тупых паролей (меньше восьми символов, без спецсимволов и т.п.). Также сама функция преобразования пароля в NT-хэш более ресурсоёмка, поэтому составление радужных таблиц для NT-хэшей требует от хакеров серьёзных вложений в ресурсы для вычисления всех хэшей.
 
 3. Шифровать EFS-ом или иными шифрующими системами свой реестр и БД AD. В этом случае злоумышленник, имея физический доступ к серверу с ломаемой ОС, не сможет получить хэши.
 
 4. Хоть это и непопулярно, но стараться устанавливать не бессрочные пароли, а пароли с временем жизни, допустим, в 3 месяца. По истечении этого срока все юзеры будут вынуждены менять пароли. Поэтому, если хакер украдёт хэши и если процедура их взлома займёт больше времени, нежели срок жизни паролей, то взлом таких хэшей окажется бессмысленным.
 
 5. Переименовывать учётки админа и гостя (там где гость не отключен), а также на уровне групповых политик отключать автоматический ввод имени последнего загруженного юзера. В этом случае злоумышленник не будет знать и имён пользователей, что также будет для него дополнительным препятствием.
 
 А майкрософту можно порекомендовать чаще менять формулу хэширования, а также дать админам контроль над формулой, чтобы админы самостоятельно могли конструировать свои собственные формулы. В этом случае стандартные радужные таблицы станут совершенно бесполезными. Кстати, а никто не в курсе, не дала ли уже майкрософт админам такие возможности, например, в 2008 сервере?
- 

 Компьютерная безопасность, коды, доступы и т.д.
 Компьютерная безопасность, коды, доступы и т.д.

























