Python-сообщество

Чаще всего, если речь идёт об обыкновенном человеке, дело-то должно быть несложным! Скорее всего там какое-то слово или популярное число, в общем, какая-нибудь чушь, которая за, казалось бы, какое-то небольшое время должна подобраться по словарю. В реальности каждый ресурс не позволяет пробовать более одного пароля в секунду, возможно, отслеживает IP и не позволяет пробовать ещё пароли после определённого числа попыток. С другой стороны, ресурс не может “заморозить” даже явно взламываемый аккаунт, поскольку на действительном пользователе это никак не должно отразиться. “Профессионалы” (хе-хе-хе), наверное применяют кластеры, что-то ещё, но что если на взлом ты готов либо потратить минут двадцать своего внимания или согласен вообще им не заниматься? Кажется, моя идея может дать ответ в подобном случае.

Представьте сайт, на котором каждый может скачать программное обеспечение – клиент, скачивание и работа которого в течение какого-то времени (скажем, получаса) даёт возможность осуществить распределённый подбор пароля.

Обыкновенно:

1. Вы оставляете на сайте заявку на подбор пароля.
   
2. Сайт немедленно пушит запущенному у вас клиенту задачу на подбор пароля c вашей машины, а также несколько задач-довесков на подбор пароля от других пользователей:
   Пользовательские идентификационные данные.
   Смещение внутри файла-словаря, с которого следует начать перебор.
   Схема подбора паролей сайта: URL, HTTP-method, POST-data, HTTP-Cookies, маркер успешно подобранной страницы (скорее всего, наличие или отсутствие на ней некоторой строки), минимальную задержку между запросами и прочее.
   
   
3. Клиент с высоким приоритетом подбирает пароль от интересующего вас аккаунта, параллельно подбирая задачи с более низким приоритетом.
   
4. Спустя некоторое значительное время работы вашего клиента сайт рассылает другим работающим в данный момент клиентам вашу задачу и начинается теперь уже распределённая работа над подбором.
   
5. Клиент, подобравший пароль, сообщает его на сервер.
   
6. Сервер, получив пароль, командует всем клиентам остановить подбор задачи.
   

Минусищищщще этой схемы в том, что её можно использовать лишь для совсем не важных вам аккаунтов: кто угодно, лишь немного возлюбопытствовав, увидит, что за аккаунты подбираются его машиной, а если повезёт, получит и пароль.

Второй минус, или слабое место, в том, что очень скоро некто напишет клиента, который станет врать. Нетрудно поймать за руку того, кто сообщает ложный пароль (нужно лишь воспользоваться известными нам критериями), однако ловить разгильдяя-лгунишку, который качает фильмы вместо того, чтобы помогать подбирать, и при этом хвалится своими преодолёнными чанками в файлах-словарях, кажется, очень трудно. Ключ к решению этой проблемы в том, что нужно заставить посетителей дорожить своей репутацией: старожилы должны быть достойны более высокого приоритета подбора своих паролей на чужих машинах, к примеру.

Можно использовать сайт-honeypot, постоянно размещая заявки на его взлом. Сравнив статистику запросов на нём и заявленные клиентами данные, найти шарлатанов должно быть просто; после этого достаточно пометить их, сразу отменив распределённый подбор их задач, а спустя некоторое случайное время работы клиента, занести его в окончательный и беспощадный чёрный список. Все эти реверансы с нарушителем нацелены на то, чтобы замести следы к honeypot'у, который следует держать в тайне.

Нужно нисколько не поощрять владельца машины, с которой был подобран пароль к отдельно взятому аккаунту. Как бы это ни было, наверное, маркетингово неправильно, “везучесть” ничего не стоит, в отличии от объёма перебранных паролей. Это сведёт число создателей подложных аккаунтов к минимуму.

Клиенты при переборе оказываются весьма рационально нагруженными: ведя подбор собственной задачи, они в интервалах простоя выполняют запросы к другим задачам. Если проект станет успешен в подборе, проводя статистику мы сможем принимать обоснованные решения об эффективности словарей. Только представьте, каким умным может стать алгоритм выставления приоритета перебору: вероятно, более высокий приоритет задача должна получить на клиентах, имеющих до неё пинг меньше сравнительно с как их собственными задачами, так и с пингами на других машинах до этой задачи. Полагаю, следует сразу заявить о том, что ваши пароли могут стать в результате известны кому угодно, даже не пытаясь закрыть код клиента и расхваливать HTTPS: только выложив его публично, мы получаем шанс дать ход замечательным идеям талантливых программистов. Такой ресурс будет полезен хотя бы тем, что станет первым хостингом схем подбора паролей на различных сайтах, что делает систему применимой даже когда вы вынуждены подбирать пароль к какому-то важному аккаунту: для этого случая в клиенте должен быть предусмотрен режим приватного, нераспределённого перебора.

Я не одобрю побуждений, которые могут сподвигнуть кого-то пользоваться подобным ресурсом (задумайтесь: не очень важные человеку аккаунты, наверное, какой-то не имеющей к нему отношения персоны – по всей видимости это мелочная месть за какой-то пустяк?), но мне очень нравится идея, сама по себе.

…ну вот, никогда не понимал обожателей оружия, возвышенных, видевших его только в музеях и книгах, а сам…