Надежно сохраняйте электронные письма в черном списке

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

Чтобы соблюдать защиту данных и по соображениям безопасности, я хочу хранить электронные письма в зашифрованном/хешированном виде. Я думал о простом md5(password), но его слишком легко взломать/перебором. Вторая мысль - использовать bcrypt/scrypt для медленной функции хеширования, но у них есть немного соли для каждой записи, поэтому мне нужно будет хешировать почту для каждой записи для сравнения. Это было бы довольно медленно, если бы время выполнения было равно O(n), где n — количество записей в черном списке.

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


security email hash blacklist
person arnep    schedule 01.12.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы можете использовать любую функцию получения ключа, например PBKDF2 или даже BCrypt/SCrypt.

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

С KDF мы можем извлечь выгоду из фактора стоимости, который значительно замедляет брутфорс. Статическая соль/ключ предотвращает брутфорс, если злоумышленник имеет доступ к базе данных, но не имеет привилегий на сервере (ключ остается секретным), это типичный сценарий SQL-инъекций. Просто убедитесь, что соль не является частью хеш-строки, большинство реализаций BCrypt делают это, потому что они предназначены для хеширования паролей.

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

person martinstoeckli    schedule 01.12.2017