Контрмеры для временной атаки на SQL SELECT хэш-токена

Мы хотим создать веб-API, в котором пользователи получают хеш-маркеры (196-бит) по электронной почте в рамках их приобретения нашей лицензии на программное обеспечение и могут затем использовать этот токен для активации их пробную версию программного обеспечения для «полного» программного обеспечения. Веб-API отвечает за получение хеш-маркера и подтверждает или отклоняет пользователя от обновления до полного.Контрмеры для временной атаки на SQL SELECT хэш-токена

Оставляя много подробностей об этом, кажется, что он получает хеш-маркер таким образом, а затем просто проверяет с помощью SQL SELECT, если этот токен находится в базе данных, предоставляет временную атаку. Злоумышленник может попытаться угадать отдельные байты из токенов в базе данных, измеряя время отклика.

Как защититься от этого? В общем и конкретно в Ruby on Rails.

Идея до сих пор: (? Как)

Достигнуть постоянное время для просмотровых окон
Добавить случайный шум (? Сколько)
Split маркера в ключевой части (32-разрядная версию) и остаток. Выполнять поиск только по ключу и безопасному сравнению с остальным

источник

2014-09-27 Christopher Oezbek

Вы можете запутать время запроса путем добавления случайного ожидания до возвращения данных клиенту. Таким образом, время запроса зависит не только от поиска базы данных. – Oliver

Что было бы подходящим количеством времени для компенсации? –

Я предполагаю, что он должен зависеть от среднего времени выполнения запроса (но я не специалист по статистике). Если вы знаете максимальное время выполнения, вы также можете максимизировать время отклика с некоторым отрывом (например, всегда требуется 10 секунд для ответа на такие запросы). Конечно, по-прежнему возникают проблемы с ситуациями с большой нагрузкой, но, по моему опыту, более тяжелая нагрузка увеличивает непредсказуемость индивидуального времени выполнения запроса. В сочетании с механизмом DOS-защиты это делает такие атаки неосуществимыми. – Oliver

Мой рабочий раствор с помощью второго индексированного token_key поле, которое первые 8 байт token_hash:

def valid_token(given_token_hash) 

    # don't look for hash, because of SQL timing attacks 
    token_key = given_token_hash[0,8] 
    token = ActivationToken.find_by_token_key(token_key) 

    # Even if not found in database, we should pretend to take some time 
    token_hash = token.nil? ? "123e4567-e89b-12d3-a456-426655440000" : token.token_hash 

    if (!secure_compare(token_hash, given_token_hash)) 
    return nil 
    end 

    return token 
end

источник

2014-10-15 22:25:39

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

https://gist.github.com/josevalim/fb706b1e933ef01e4fb6#file-2_safe_token_authentication-rb

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

источник

2014-10-15 22:12:29

Это то, что я закончил: я рассматриваю первый 32-разрядный токен как открытый (целочисленный идентификатор), который приведет к просмотру базы данных (тактика синхронизации будет работать над этим). Далее secure_compare остатка. –

@ChristopherOezbek вы генерируете первые 32 бита с помощью автоматического увеличения индекса? Если это случайный случай с использованием проблемы с днем рождения, у вас будет 50% вероятность столкновения этих первых 32 бит только с 77 000 токенов, которые кажутся слишком низкими. – danny

@danny: Я использую случайные, но затем проверяю наличие существующих идентификаторов. –

Контрмеры для временной атаки на SQL SELECT хэш-токена

ответ

Смежные вопросы