Comments 10
Очень спорная статья.
Например, тезис про добавление хеширования для защиты от плохого генератора случайности. Хеши — это однозначные функции, они не исправят слабость генератора. Да, на выходе после хеширования результат будет с равномерным распределением, но если злоумышленник использует слабость генератора, то он точно так же высчитает и хеши, от неравномерных случайностей.
Или предложение строить токен на основе id (или как-то иначе, но не случайно) и подписывать его хешированием с «перцем». Использование «перца», не сказать что сильно плохая, но точно не хорошая практика. Для некоторых систем не предполагающих надежной защиты или сильно экономящей ресурсы (валидация неслучайного токена без БД), возможно, это сгодится.
И ничего нет, например, о атаках по времени при обработке токена. Что токен должен быть разделен на две части, по одной из которых идет поиск токена с защитой от таких атак, а по другой проверка на валидность.
Например, тезис про добавление хеширования для защиты от плохого генератора случайности. Хеши — это однозначные функции, они не исправят слабость генератора. Да, на выходе после хеширования результат будет с равномерным распределением, но если злоумышленник использует слабость генератора, то он точно так же высчитает и хеши, от неравномерных случайностей.
Или предложение строить токен на основе id (или как-то иначе, но не случайно) и подписывать его хешированием с «перцем». Использование «перца», не сказать что сильно плохая, но точно не хорошая практика. Для некоторых систем не предполагающих надежной защиты или сильно экономящей ресурсы (валидация неслучайного токена без БД), возможно, это сгодится.
И ничего нет, например, о атаках по времени при обработке токена. Что токен должен быть разделен на две части, по одной из которых идет поиск токена с защитой от таких атак, а по другой проверка на валидность.
Вроде как раз в последних абзацах говорится о том, что не следует эту статью обсуждать в ключе «это хороший или плохой метод», а доносится понятие о необходимости использования разных уровней безопасности.
Пост скорее направлен на широкую аудиторию (то есть людей вроде меня) и в этом плане свою задачу решает — появилось желание на своих проектах уделить вопросу подобной многоуровневой защиты больше внимания (не своими руками, конечно).
Пост скорее направлен на широкую аудиторию (то есть людей вроде меня) и в этом плане свою задачу решает — появилось желание на своих проектах уделить вопросу подобной многоуровневой защиты больше внимания (не своими руками, конечно).
И ничего нет, например, о атаках по времени при обработке токена. Что токен должен быть разделен на две части, по одной из которых идет поиск токена с защитой от таких атак, а по другой проверка на валидность.
Разве добавление хэша в идентификатор сессии не является тем самым делением его на 2 части, содержащую данные и проверяющую валидность.
Можно, конечно и так, хотя по-мне лучше случайные данные. Но в статье предназначение хеша совсем другое — для подписи токена, если токен не случаен, и несет в себе какие-либо данные. Либо для исправления потенциальных дыр в источнике случайности. Хотя, имхо, это ничего не исправляет.
Про проблемы связанные с атаками по времени — нет ничего. А разделение хеша на две части решает вопрос сочетания хранения токенов в БД и использования поиска в БД, который разумеется не предназначен для защиты от атак по времени с алгоритмом сравнения, который соотв. предназначен.
Про проблемы связанные с атаками по времени — нет ничего. А разделение хеша на две части решает вопрос сочетания хранения токенов в БД и использования поиска в БД, который разумеется не предназначен для защиты от атак по времени с алгоритмом сравнения, который соотв. предназначен.
Возможно я и ошибаюсь, а может что-то прочел не так детально как полагалось бы, но описанная в статье атака скорее называется не brute-force, а hijacking (или session hijacking) — ограбить сессию, дословно. Одна из наиболее распространненных атак 21 века.
Brute-force же скорее, в простом понимании, является нагрузкой на сервер (как web, так и sql-server) перебором «сложных» и «проблемных» запросов. Например, можно подобрать, открытые в сети, запросы на карту, где собирается множество объектов и дергать их в циклах с разных тачек.
Brute-force же скорее, в простом понимании, является нагрузкой на сервер (как web, так и sql-server) перебором «сложных» и «проблемных» запросов. Например, можно подобрать, открытые в сети, запросы на карту, где собирается множество объектов и дергать их в циклах с разных тачек.
Нет, вы путаете brute force и DDOS.
Жаль у автора в оригинале комментарии закрыты.
А у нас в системе используется два токена, первый в cookies, второй в строке запроса. Стоит упомянуть, что сайты работают как одностраничные морды, подключённые к API. Оба токена — SHA-512 хеши с солью, основанные на отпечатках браузера, с элементом случайности. Без обоих валидных ключей сервер даже пытаться запрашивать базу не будет. C HTTPS двойную систему можно обойти, оставив только один из хешей, тот, что в cookies. В основном, это сделано для упрощения жизни системам в стиле API-to-API.
Сессия существует только 12 минут (почему-то так сложилось), с возможностью продления. При продлении можно выдавать новые токены, но это вызывает проблему с синхронизацией, если открыты несколько вкладок. Для долговременной авторизации (запоминания пароля), генерируется отдельный временный ключ, который наглухо привязан к пользователю (в отличии от сессии, которая просто является ключом к каким-то данным в базе), который тоже привязан к браузеру. Таких ключей может быть несколько.
Меня всегда удивляло, почему подписи браузеров не используют для защиты сессий, это ведь очевидное решение. Можно делать сильный отпечаток, который может стать неверным при изменении настроек, или слабый, которому и обновление браузера — не помеха. Зависит от того, что защищаем, ключи от банка или любимые фоточки котиков.
Сессия существует только 12 минут (почему-то так сложилось), с возможностью продления. При продлении можно выдавать новые токены, но это вызывает проблему с синхронизацией, если открыты несколько вкладок. Для долговременной авторизации (запоминания пароля), генерируется отдельный временный ключ, который наглухо привязан к пользователю (в отличии от сессии, которая просто является ключом к каким-то данным в базе), который тоже привязан к браузеру. Таких ключей может быть несколько.
Меня всегда удивляло, почему подписи браузеров не используют для защиты сессий, это ведь очевидное решение. Можно делать сильный отпечаток, который может стать неверным при изменении настроек, или слабый, которому и обновление браузера — не помеха. Зависит от того, что защищаем, ключи от банка или любимые фоточки котиков.
Обычно все эти «двух токенные» костыли имеют еще больше изъянов чем проверенные временем схемы. Почему не используют подписи? Потому что ее легко подделать, единственное чему более менее можно доверять это ip адрес. Ну и если кто то нашел XSS у него нет задачи украсть сессию, они просто делают что им нужно в том же контексте.
Это называется простым словом — ПАРАНОЙЯ.
Даже, если каким-либо чудесным образом будет осуществлён брутфорс сессии, надо чтобы архитектура приложения была построена без проверок аутентификационных данных при критичных действиях.
Даже, если каким-либо чудесным образом будет осуществлён брутфорс сессии, надо чтобы архитектура приложения была построена без проверок аутентификационных данных при критичных действиях.
Sign up to leave a comment.
Немного о защите идентификаторов веб-сессий