Какая лучшая контрмера для распределенной грубой силы?

Question

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

Я знаю все обычные трюки:

1. Ограничение # неудачных попыток на IP / хост и отказ в доступе нарушителей (например, Fail2Ban) - который больше не работает , так как ботнеты стали умнее
2. Объединение вышеперечисленного с черным списком известных «плохих» IP / хостов (например, DenyHosts) - который опирается на ботнеты, попадающие на # 1, , чего они все чаще не делают
3. Белые списки IP / хостов в сочетании с традиционной аутентификацией (к сожалению, бесполезно для пользователей с динамическим IP и высоким оттоком на большинстве веб-сайтов)
4. Установка ограничения по всему на число неудачных попыток в течение N минут / часов и регулирование (приостановка) всех попыток входа в систему после этого в течение нескольких минут / часов (с проблемой, с которой атакует DoS). ты становишься ботнетом детской игры)
5. Обязательные цифровые подписи (сертификаты открытого ключа) или аппаратные токены RSA для всех пользователей без опции логин / пароль (без сомнения, надежное решение, но практично только для закрытых, выделенных служб)
6. Принудительные схемы сверхсильных паролей (например,> 25 бессмысленных символов с символами - опять же, слишком непрактично для случайных пользователей)
7. И, наконец, CAPTCHA (которые могут работать в большинстве случаев, но раздражают пользователей и практически бесполезны против решительного, находчивого злоумышленника )

Теперь, это только теоретически осуществимые идеи. Существует множество идей мусора, которые взрывают сайт широко (например, для тривиальных DoS-атак). То, что я хочу, это что-то лучше. А под лучше я имею в виду:

• Он должен быть защищен (+) от DoS и атак методом перебора, и не должен содержать каких-либо новых уязвимостей, которые могут позволить слегка подлому боту продолжить работу под радаром

• Должен быть автоматизирован. Если для проверки каждого входа в систему или отслеживания подозрительной активности требуется оператор-человек, в реальном сценарии это не сработает

• Это должно быть осуществимо для широкого использования в Интернете (т. Е. Высокий отток, большой объем и открытая регистрация, которую могут выполнять непрограммисты)

• Это не может помешать работе пользователя до такой степени, что случайные пользователи будут раздражены или разочарованы (и потенциально могут покинуть сайт)

• Это не может включать котят, если они не действительно действительно безопасны котята

(+) Под «безопасным» я подразумеваю, по крайней мере, такую ​​же безопасность, как и способность пользователя-параноика хранить свой пароль в секрете

Итак - давайте послушаем это! Как бы вы это сделали ? Знаете ли вы о лучшем опыте, о котором я не упомянул (о, пожалуйста, говорите)? Я признаю, что у меня есть собственная идея (объединяющая идеи из 3 и 4), но я позволю истинным экспертам высказаться, прежде чем смущать себя; -)

Answer 1

Хорошо, хватит останавливаться; вот что я придумала до сих пор

(простите, длинный пост вперед. Будь смелым, друг, путешествие того стоит)

Объединение методов 3 и 4 из исходного поста в своего рода «нечеткий» или динамический белый список, а затем - и вот в чем хитрость - не блокирование IP-адресов, не занесенных в белый список, просто удушение их в ад и обратно .

Обратите внимание, что эта мера только предназначена для предотвращения этого очень специфического типа атаки. На практике, конечно, он будет работать в сочетании с другими передовыми подходами к аутентификации: регулирование фиксированного имени пользователя, регулирование для каждого IP-адреса, политика надежных паролей с применением кода, неконтролируемый вход в систему cookie, хэширование всех эквивалентов паролей перед их сохранением, никогда использование вопросов безопасности и т. д.

Предположения о сценарии атаки

Если злоумышленник нацеливается на переменные имена пользователей, наше регулирование имен пользователей не срабатывает. Если злоумышленник использует ботнет или имеет доступ к большому диапазону IP, наше регулирование IP бессильно. Если злоумышленник предварительно очистил наш список пользователей (обычно это возможно в веб-службах с открытой регистрацией), мы не можем обнаружить продолжающуюся атаку на основании количества ошибок «пользователь не найден». И если мы введем ограничивающий дросселирование в масштабе всей системы (все имена пользователей, все IP-адреса), любая такая атака будет делать DoS для всего нашего сайта на время атаки плюс период регулирования.

Так что нам нужно сделать что-то еще.

Первая часть контрмеры: Белый список

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

Таким образом, наша схема внесения в белый список будет функционировать как заблокированная «входная дверь», где пользователь должен быть подключен с одного из его признанных «хороших» IP-адресов, чтобы вообще войти в систему. Атака грубой силой на эту «парадную дверь» была бы практически невозможна (+).

(+), если злоумышленник не «владеет» ни сервером, ни ящиками всех наших пользователей, ни самим соединением - и в этих случаях у нас больше не возникает проблема «аутентификации», у нас есть подлинный размер франшизы Ситуация FUBAR с откидной крышкой

Вторая часть контрмер: общесистемное регулирование нераспознанных IP-адресов

Для того, чтобы белый список работал для веб-службы с открытой регистрацией, где пользователи часто переключают компьютеры и / или подключаются с динамических IP-адресов, нам необходимо держать «кошачью дверь» открытой для пользователей, подключающихся с нераспознанных IP-адресов. Хитрость заключается в том, чтобы спроектировать эту дверь так, чтобы ботнеты застревали, и чтобы законные пользователи беспокоились как можно меньше .

В моей схеме это достигается установкой ограничивающего максимального числа неудачных попыток входа в систему * по неутвержденным IP-адресам, скажем, в течение 3 часов (может быть, целесообразнее использовать более короткий или более длинный). период в зависимости от типа услуги) и установив это ограничение global , т.е. для всех учетных записей пользователей.

Даже медленная (1-2 минуты между попытками) грубая сила была бы обнаружена и сорвана с помощью этого метода. Конечно, действительно медленная грубая сила все еще может остаться незамеченной, но слишком медленные скорости наносят ущерб самой цели атаки грубой силы.

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

• Либо путем подключения с одного из их распознанных IP-адресов
• Или с помощью постоянного файла cookie для входа (из любого места)

Единственные законные пользователи, которые будут затронуты во время атаки - т.е. в то время как регулирование было активировано - это были бы пользователи без постоянных файлов cookie для входа, которые входили в систему из неизвестного местоположения или имели динамический IP-адрес. Эти пользователи не смогут войти в систему, пока не прекратится регулирование (это может занять некоторое время, если злоумышленник продолжит работу ботнета, несмотря на регулирование).

Чтобы позволить этой небольшой группе пользователей протиснуться через запечатанную в противном случае дверцу кошки, даже когда боты все еще стучали в нее, я бы использовал «резервную» форму входа в систему с CAPTCHA. Чтобы при отображении сообщения «Извините, но вы не можете войти с этого IP-адреса в данный момент», добавьте ссылку « безопасный резервный вход в систему - ТОЛЬКО ЧЕЛОВЕК ( боты: нет лжи *») 1069 *) ». Помимо шутки, когда они щелкают по этой ссылке, дают им аутентифицированную reCAPTCHA форму входа в систему, которая обходит регулирование всего сайта. Таким образом, ЕСЛИ они люди и знают правильный логин + пароль (и могут читать CAPTCHA), они будут никогда получать отказ в обслуживании, даже если они подключаются с неизвестного хоста и не используют автологин печенье.

Да, и просто для пояснения: поскольку я считаю, что CAPTCHA, как правило, являются злыми, опция входа в систему «резервного копирования» будет только появляться , в то время как регулирование было активно .

Нельзя отрицать, что подобная устойчивая атака все еще будет представлять собой форму DoS-атаки, но с описанной системой она будет влиять только на то, что, как я подозреваю, будет крошечной группой пользователей, а именно на людей, которые не t использовать cookie-файл "запомнить меня", и он входит в систему, когда происходит атака, И не входит в систему с любого из своих обычных IP-адресов И не может читать CAPTCHA. Только те, кто может сказать «нет» ВСЕМ из этих критериев - особенно боты и действительно неудачливые инвалиды - будут отвергнуты во время атаки ботов.

РЕДАКТИРОВАТЬ: На самом деле, я подумал о том, чтобы позволить даже пользователям с CAPTCHA проходить через 'блокировку': вместо или в качестве дополнения к резервному входу в CAPTCHA, предоставить пользователю возможность иметь одноразовый, специфичный для пользователя код блокировки, отправленный на его электронную почту, который он затем может использовать для обхода регулирования. Это определенно пересекает мой порог «раздражения», но поскольку он используется только как последнее средство для небольшого подмножества пользователей, и, поскольку он все еще превосходит блокировку вашей учетной записи, это будет приемлемо.

(Также обратите внимание, что нет этого происходит, если атака менее сложна, чем описанная здесь противная распределенная версия. Если атака идет с нескольких IP-адресов или только с удара несколько имен пользователей, это будет сорвано намного раньше, и с нет последствия для всего сайта)

---

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

Answer 2

Несколько простых шагов:

Черный список определенных распространенных имен пользователей и использование их в качестве приманки. Администратор, гость и т. Д. Не позволяйте никому создавать учетные записи с этими именами, поэтому, если кто-то попытается войти в систему, вы знаете, что кто-то делает то, что не должен.

Убедитесь, что у любого, кто имеет реальную власть на сайте, есть безопасный пароль. Требовать от администраторов / модераторов иметь более длинные пароли с сочетанием букв, цифр и символов. Отклоните тривиально простые пароли от обычных пользователей с объяснением.

Одна из самых простых вещей, которую вы можете сделать, это сообщить людям, когда кто-то пытался войти в их учетную запись, и дать им ссылку, чтобы сообщить об инциденте, если это был не они. Простое сообщение, когда они входят в систему: «Кто-то пытался войти в вашу учетную запись в 4:20 утра среды бла-бла. Нажмите здесь, если это был не вы». Это позволяет вам вести статистику атак. Вы можете усилить мониторинг и меры безопасности, если увидите, что внезапный рост числа мошеннических обращений.

Answer 3

Если я правильно понимаю МО атак грубой силы, то одно или несколько имен пользователей будут пробоваться непрерывно.

Есть два предложения, которые, я не думаю, я уже видел здесь:

• Я всегда думал, что стандартная практика - иметь небольшую задержку (секунду или около того) после каждого неправильного входа в систему для каждого пользователя. Это удерживает грубую силу, но я не знаю, как долго задержка в одну секунду будет сдерживать атаку по словарю. (словарь из 10000 слов == 10000 секунд == около 3 часов. Хм. недостаточно хорошо.)
• вместо замедления по всему сайту, почему бы не использовать имя пользователя. Дроссель становится все более резким с каждой неправильной попыткой (до предела, я думаю, что настоящий пользователь все еще может войти)

Редактировать : В ответ на комментарии о дросселе имени пользователя: это дроссель, специфичный для имени пользователя, без учета источника атаки.

Если имя пользователя задушено, то может быть обнаружена даже скоординированная атака имени пользователя (мульти IP, одно предположение на IP, то же имя пользователя). Отдельные имена пользователей защищены дросселем, даже если злоумышленники могут попробовать другого пользователя / пройти в течение тайм-аута.

С точки зрения злоумышленников, в течение тайм-аута вы сможете впервые сделать предположение о 100 паролях и быстро обнаружить один неверный пароль для каждой учетной записи. Вы можете только сделать 50-секундные предположения за тот же период времени.

С точки зрения учетной записи пользователя, для взлома пароля все равно требуется одинаковое среднее число догадок, даже если догадки поступают из нескольких источников.

Для злоумышленников в лучшем случае это будет та же самая попытка взломать 100 учетных записей, что и 1 учетная запись, но, поскольку вы не ограничиваете работу на всем сайте, вы можете увеличить дроссель довольно быстро. *

Дополнительные уточнения:

• обнаружение IP-адресов, которые предполагают наличие нескольких учетных записей - 408 Время ожидания запроса
• обнаружение IP-адресов, которые используют одну и ту же учетную запись - 408 Время ожидания запроса после большого (скажем, 100) числа догадок.

Идеи пользовательского интерфейса (могут не подходить в этом контексте), которые также могут уточнить выше:

• если вы контролируете настройку пароля, то показ пользователю насколько надежен его пароль побуждает его выбрать лучший.
• если вы контролируете логин страницу , то после небольшого (скажем, 10) угадывания одного имени пользователя предложите CAPTCHA.

Answer 4

Существует три фактора аутентификации:

1. Пользователь знает что-то (т.е. пароль)
2. Пользователь имеет что-то (т.е. брелок)
3. Пользователь - это что-то (т. Е. Сканирование сетчатки)

Обычно веб-сайты применяют только политику № 1. Даже большинство банков применяют только политику 1. Вместо этого они полагаются на «знает что-то другое» подход к двухфакторной аутентификации. (IE: пользователь знает свой пароль и девичью фамилию своей матери.) Если вы можете, способ добавить второй фактор аутентификации не слишком сложен.

Если вы можете сгенерировать около 256 символов случайности, вы можете структурировать их в таблице 16 & times; 16, а затем попросить пользователя указать значение, например, в таблице ячейки A-14. Когда пользователь регистрируется или меняет свой пароль, дайте ему таблицу и попросите его распечатать и сохранить.

Сложность такого подхода заключается в том, что когда пользователь забывает свой пароль, как он хочет, вы не можете просто предложить стандарт «ответьте на этот вопрос и введите новый пароль», поскольку он также уязвим для перебора. , Кроме того, вы не можете сбросить его и отправить им по электронной почте новый, так как их электронная почта также может быть скомпрометирована. (См .: Makeuseof.com и их украденный домен.)

Другая идея (которая включает в себя котят), это то, что BOA называет SiteKey (я думаю, они торговали торговой маркой). Вкратце, у вас есть пользователь, загружающий изображение при регистрации, и когда он пытается войти в систему, попросите его выбрать свое изображение из 8 или 15 (или более) случайных. Таким образом, если пользователь загружает фотографию своего котенка, теоретически только он точно знает, какая картинка у него из всех других котят (или цветов или чего-то еще). Единственная реальная уязвимость, которой обладает этот подход, - это атака «человек посередине».

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

Редактировать, Новая идея:

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

Ключ в данном случае является наиболее важным аспектом. Распространенным методом их генерации является некоторая комбинация данных пользователя, их IP-адреса и времени их отправки.

Answer 5

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

Вы не можете просто предотвращать DoS-атаки, связывая регулирование до одного IP-адреса или имени пользователя. Черт, вы даже не можете предотвратить попытки быстрого входа в систему с помощью этого метода.

Почему? Поскольку атака может охватывать несколько IP-адресов и учетных записей пользователей, чтобы обойти ваши попытки регулирования.

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

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

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

---

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

---

Запросите таблицу при каждой неудачной попытке входа в систему, чтобы найти количество неудачных попыток входа в систему за определенный период времени, скажем, 15 минут:

---

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

---

Если количество попыток в течение указанного периода времени превышает ваш лимит, либо принудите регулирование, либо заставьте всех пользователей использовать капчу (то есть reCaptcha), пока количество неудачных попыток за указанный период времени не станет меньше порогового значения ,

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Использование reCaptcha при определенном пороге гарантирует, что атака с нескольких фронтов будет сведена к минимуму , и обычные пользователи сайта не будут испытывать значительную задержку для законных неудачных попыток входа в систему. Я не могу гарантировать гарантию, так как это уже было расширено, что CAPTCHA могут быть уничтожены. Существуют альтернативные решения, возможно, вариант «Назови это животное», который вполне может подойти в качестве замены.

Answer 6

Я должен спросить, провели ли вы анализ затрат и выгод по этой проблеме; Похоже, вы пытаетесь защитить себя от злоумышленника, у которого достаточно присутствия в сети, чтобы угадать количество паролей, отправляя, возможно, 3-5 запросов на IP (поскольку вы отклонили регулирование IP). Сколько (примерно) будет стоить такая атака? Это дороже, чем стоимость счетов, которые вы пытаетесь защитить? Сколько гигантских ботнетов хочет то, что у тебя есть?

Ответ может быть нет - но если это так, я надеюсь, что вы получите помощь от какого-то специалиста по безопасности; навыки программирования (и оценка StackOverflow) не сильно связаны с ноу-хау безопасности.

Answer 7

Чтобы обобщить схему Йенса в диаграмму перехода псевдосостояния / rulebase:

1. пользователь + пароль -> запись
2. пользователь +! Пароль -> отказано
3. пользователь + known_IP (пользователь) -> входная дверь, // never throttle
4. пользователь + unknown_IP (пользователь) -> catflap
5. (# отказано> n) через catflaps (сайт) -> дроссельные кошки (сайт) // slow the bots
6. catflap + throttle + пароль + капча -> запись // humans still welcome
7. catflap + throttle + password +! Captcha -> denied // a correct guess from a bot

Замечания:

• Никогда не дросселируйте переднюю дверь. Элбонская государственная полиция хранит ваш компьютер в вашем доме, но не может допрашивать вас. Грубая сила - это жизнеспособный подход с вашего компьютера.
• Если вы предоставите «Забыли пароль?» после ссылки, ваша учетная запись электронной почты становится частью поверхности атаки.

Эти наблюдения охватывают различные типы атак, против которых вы пытаетесь противостоять.

Answer 8

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

Answer 9

Отказ от ответственности: я работаю в двухфакторной компании, но не здесь, чтобы подключить его. Вот некоторые наблюдения.

Файлы cookie могут быть украдены с помощью XSS и браузера. Пользователи обычно меняют браузеры или очищают свои куки.

Исходные IP-адреса могут быть динамически изменяемыми и поддельными.

Captcha полезен, но не аутентифицирует конкретного человека.

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

Сложность пароля хорошая, все, что основано на пароле, критически зависит от паролей, имеющих достаточную энтропию. ИМХО, надежный пароль, записанный в безопасном физическом месте, лучше слабого пароля в памяти. Люди знают, как оценить безопасность бумажных документов гораздо лучше, чем знают, как определить эффективную энтропию в имени своей собаки, когда она используется в качестве пароля для трех разных веб-сайтов. Подумайте о том, чтобы дать пользователям возможность распечатать большую или маленькую страницу, полную разовых паролей.

Вопросы безопасности, такие как «каким был талисман в старшей школе», в основном являются еще одной паршивой формой «чего-то, что вы знаете», большинство из них легко угадать или открыто сделать достоянием общественности.

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

Лично я не вижу выгоды от принудительного истечения срока действия пароля на веб-сайте. Атакующий получает ваш пароль один раз, затем он может изменить его и выполнить эту политику так же легко, как и вы. Возможно, одним из преимуществ является то, что пользователь может заметить раньше, если злоумышленник изменит пароль учетной записи. Еще лучше было бы, если бы пользователь был как-то уведомлен до того, как злоумышленник получил доступ. В этом отношении полезны сообщения типа «N неудачных попыток с момента последнего входа в систему».

Наилучшая защита обеспечивается вторым фактором аутентификации, который является внеполосным по сравнению с первым. Как вы сказали, аппаратные токены в «чем-то, что у вас есть» великолепны, но у многих (не у всех) есть реальные накладные расходы администратора, связанные с их распространением. Я не знаю ни одного биометрического решения «что-то, что ты есть», подходящего для веб-сайтов. Некоторые двухфакторные решения работают с поставщиками openid, у некоторых есть PHP / Perl / Python SDK.

Answer 10

Моя самая высокая рекомендация - просто убедиться, что вы держите пользователей в курсе неудачных попыток входа в их учетные записи-- Скорее всего, пользователи будут более серьезно относиться к надежности своего пароля, если им будут представлены доказательства того, что кто-то действительно пытается получить доступ к их аккаунту.

Я действительно поймал кого-то, кто взломал учетную запись моего брата на myspace, потому что он пытался войти в учетную запись gmail, которую я для него настроил, и использовал функцию «сбросить пароль по электронной почте» ... которая зашла в мой почтовый ящик.