Учимся на чужих ошибках и защищаем пароли от брутфорса

Как усилить защиту паролей «12345» от brute-force атаки

Алгоритмы Из песочницы Объект: веб-форма входа в систему.Дана задача: усилить защиту аккаунта пользователя от подбора простого пароля к его аккаунту, используя минимум средств. Что такое минимум средств? Это не использовать таблицы-справочники для блокировки по IP-адресу и User-Agent. Не использовать лишние запросы к системе, не захламлять систему авторизации лишними циклами. И, выполнить совершенно волшебное требование — даже если бот введет нужные логин и пароль… не дать ему войти, а вот реального пользователя впустить. Можно ли так сделать? В теории, конечно, нет. Но в практике, в частном порядке и при определенных условиях, как оказалось, весьма возможно. Приглашаю под кат за подробностями. Итак, предположим, что, логин у нашего пользователя «test», а пароль «12345». Мерзкий бот подключил свой словарь сгенерированных паролей, и готов работать со скоростью 700 паролей в секунду. Он знает, что логин пользователя — «test». Ситуация аховая: пароль «12345» будет вычислен за очень малое время. Пользователь, тем временем, открыл сайт и начал вводить логин и пароль в веб-форму логина. Давайте внесем изменения в систему авторизации, пока ни один из них не начал свою работу, и не случилась беда. Магия будет заключаться в третьей переменной, которую следует «приклеить» к паре логин-пароль. Я назвал ее touch. Каждый раз, когда кто-то получает (внимание: получает, а не запрашивает!) логин-пароль, дата «touch» для пользователя «test» обновляется на текущую дату-время:

login/password/touch: 'test', '12345', '2014-12-13 14:00:00'.

Предположим, что бот начал первую итерацию и предложил пароль «1» для логина «test» в ‘2014-12-13 15:00:00’. Cрабатывает контроллер login_check, который читает из базы данных пару логин-пароль, которую никто не «трогал» целых 2 секунды! Откуда вообще эти 2 секунды?! Об этом будет дальше. Такая пара логин-пароль находится. Разница между последним «touch» и текущим временем — 1 час. Поэтому запись успешно возвращается на наш запрос. Сначала пара логин-пароль сличается и login_check приходит к выводу, что «test/12345» не равно «test/1». Контроллер возвращает «auth error». А затем дата «touch» для пользователя «test» обновляется на текущую: ‘2014-12-13 15:00:00’. Бот приступает к следующей итерации: пробует пароль «2». Скорость работы бота измеряется микросекундами. Он пытается авторизоваться сразу же: в ‘2014-12-13 15:00:00’. И тут вступает в действие наш алгоритм — условие по параметру «touch» уже не выполняется. 2 секунды еще не прошли. Fail. Модифицированный нашей логикой контроллер «login_check» не может получить пару логин-пароль. Запись существует, но ее дата «touch» еще слишком «свежая». И она она уже не попадает в выборку. А раз такой пары логин-пароль нет, то контроллер ответит боту «auth error». Бот не сдается, продолжает подбор и, наконец, приходит к правильному паролю «12345». Вероятность, что именно текущая попытка вернет успех — крайне и крайне мала. 1/700 на каждую попытку входа! То есть, если раньше было 1:1, то теперь 1:700. И чем быстрее бот, тем больше вероятность, что его ждет fail. В итоге только очень малая часть паролей будет действительно проверена. Остальные получат ложные срабатывания, даже если они будут верны.А что пользователь? Начнем с пользователя. Пользователь, в отличие от бота, вводит данные в веб-форму руками через клавиатуру и смотрит зрительными органами на монитор. А гибкость его алгоритмических способностей куда лучше, чем бота. По сути, пользователь в некотором роде искусственный интеллект. А значит, часть логики уже лежит в нем. И мы ею воспользуемся! Когда пользователь видит ошибку авторизации, он часто переписывает пароль заново. Даже если пароль он только что вбил сам. Даже если пароль подставлен автоматом из password-manager. Я делал это еще до того, как применил свою систему защиты простых паролей. Да, я обещал рассказать про две секунды. Рассказываю: Две секунды это оптимальное время, за которое пользователь проводит операции по корректировке данных и совершает следующую попытку входа. В эти две секунды пользователь укладывается полностью. Если пользователь не уложился — он всегда может повторить попытку и за это время действие touch уже наверняка аннулируется.В заключение. Что будет если бот узнает о 2-секундной задержке? Если применить наши тестовые данные, это значит, что эффективность бота снизится: всего 1 попытка подбора пароля вместо 1400.P.S. Очень хочется услышать критику, потому что система уже внедрена в один проект, и пока не создала ни одного тикета с проблемой доступа к системе. Заранее спасибо.

Ошибка начинающих криптоаналитиков

Многие начинающие криптоаналитики считают, что схема SHA1(SHA1(SHA1(..($hash)))) будет добавлять раунды в SHA1.

Все бы было именно так, если бы не одно фундаментальное свойство алгоритма SHA1. Из него следует, что вычислительно невозможно написать такую функцию SHA1000, которая будет эквивалентна тысячекратному вложенному вызову SHA1 и при этом будет легко вычислима. Обрати внимание, что результат SHA1(SHA1(..($hash))) — это не то же самое, что добавить больше раундов внутрь SHA1, так как там есть еще пре- и постобработка. Результатом такого хеширования может стать невыгодный во всех отношениях расход процессорных ресурсов.

Intro

Последнее время новостная лента пестрит постами об утечках паролей с крупных ресурсов. Если ты следишь за новостями мира ИБ, то наверняка слышал об утечке 6,46 миллиона хешей паролей крупнейшей социальной сети для профессионалов — LinkedIn. По сей день этот инцидент расследуют самые крутые спецы ФБР. Можно сказать, что последние полгода организация утечек паролей является негласным трендом в кругах анонимусов.

За это время были опубликованы хеши таких популярных ресурсов, как Last.fm, Yahoo Voice, eHarmony, NVIDIA. Небезызвестная компания Rapid 7 провела анализ 165 тысяч хешей, слитых с LinkedIn, и составила инфографику самых популярных (она приложена в качестве иллюстрации к этой статье).

На первый взгляд, пользователи сами виноваты, что используют такие простые для восстановления пароли. Но так ли это? В конечном счете компании удалось расшифровать и проанализировать все пароли, как сложные, так и простые. Механизмы защиты паролей, фигурировавшие в историях этих утечек, настолько примитивны, что при желании для восстановления исходных данных можно использовать минимальные ресурсы. Стоит ли в таком случае говорить о том, насколько уязвимыми мы становимся с неустойчивыми хешами, которые легко вскрываются ресурсами китайской ОЕМ-видеокарты стоимостью 42 доллара? Возможно ли существенно усложнить злоумышленникам восстановление паролей пользователей с утекшей БД? Возможно! Сегодня я расскажу тебе о том, как снизить риски восстановления паролей из неустойчивых хешей.

Дедик, dedik, dedicated — зачем нужен выделенный сервер

Если вы далеки от администрирования, то могли подумать, что Дедик и Брут — это два друга (или недруга?) с экзотическими именами. Но нет — слово «дедик» образовалось от английского dedicated, а точнее Dedicated server. Сленговое название «дедик» означает, как нетрудно догадаться, выделенный сервер. Опытные пользователи уже знают обо всех преимуществах физических серверов, но на всякий случай мы напомним.

Dedicated server — это, по сути, полноценный компьютер, расположенный в дата-центре провайдера в отдельной стойке и работающий 24 часа в сутки 7 дней в неделю. В отличие от виртуального хостинга, на нём не будут размещены сайты других клиентов, что, несомненно, даёт ощутимые преимущества:

— Все ресурсы принадлежат вам, что делает работу сервера более стабильной.

— Можно выбрать любую версию любой операционной системы и настроить её на своё усмотрение, а также установить необходимое ПО. 

— Вы будете осуществлять полноценное администрирование своего сервера с root-правами.

— Всё оборудование полностью изолировано и находится в отдельной стойке, что повышает безопасность и сохранность данных.

Используемые источники:

• https://m.habr.com/ru/post/245903/
• https://xakep.ru/2012/11/22/study-in-alien-mistakes-safe-password-from-brutforce/
• https://www.reg.ru/blog/kak-zashchitit-dedik-ot-bruta/