Хэширование против эффективности поиска базы данных

Question

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

email:username:salt 

хэш генерируется с использованием алгоритма SHA256 и та же соль используется для каждого маркера, генерируемого.

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

Мой вопрос: является ли это эффективным (с учетом использования процессора и диска и т. Д.) В целях достижения генерации токена для проверки подлинности электронной почты.

Answer 1

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

важные вещи, которые нужно иметь в виду:

• Маркер должен быть невозможно для конечного пользователя, чтобы воспроизвести, в противном случае он может быть подделана.
• Токен должен быть криптографически подписан вашим веб-сервером (в идеале), чтобы КЛИЕНТ знал, что это действительный токен. Это также важно, потому что, когда пользователь отправляет этот токен BACK на ваш сервер, вы можете проверить, что ваш сервер - тот, который его создал.
• Маркер должен быть expireable: вы должны быть в состоянии «истекает» этот знак, если он не используется в течение определенного промежутка времени: 24 часа, 3 дня, и т.д.

По этой причине, Я бы не рекомендовал подход, который вы принимаете.

Вместо этого я бы использовал JSON web token (для них это идеальный вариант использования). У этого другого SO question есть приличное резюме.

Использование JWT позволит вам:

• Создать маркер на вашем веб-сервере.
• Установите дату истечения срока действия этого токена, чтобы он не мог использоваться по истечении определенного срока.
• Кодировать любые пользовательские данные в токене, который вы хотите: обычно это идентификатор пользователя или что-то подобное.

Когда пользователь отправляет маркер обратно на свой веб-сервер, JWT будет:

• гарантия, что маркер был сгенерирован на сервере, а не кто-то другой злонамеренно.
• Гарантия токена по-прежнему действительна (с точки зрения времени).
• Гарантия, что токен не был подделан.
• Позволяет просматривать ранее кодированные данные токена (ID пользователя и т. Д.).

Я надеюсь, что это помогает =)

Answer 2

Что вы делаете несколько безопасным.

Я бы назвал вашу соль, но как ключ - вы генерируете хеш-ключ. Убедитесь, что вы создаете ключ с достаточной энтропией. Я бы рекомендовал силу 128 бит, сгенерированных CSPRNG.

Некоторые ключевые хэши, созданные таким образом, уязвимы для атаки длины. То есть, если злоумышленник сгенерировал токен проверки для foo@example.com, тогда они смогут обработать хэш для foo@example.com.example.org. Это связано с тем, что вывод хэш-алгоритма также предает его состояние. Чтобы уменьшить это, вы можете использовать HMAC algorithm.

Ваш текущий подход также имеет ограничение на то, что адрес электронной почты всегда имеет один и тот же токен. Если истечет срок действия адреса электронной почты (скажем, Боб Смит с электронным адресом bobs@example.org уволен с работы в «Пример организации», он узнает код подтверждения, который получит следующий Боб С., когда он начнет работать в «Пример организации»). Является ли это какой-либо риск для вашего приложения, вам решать. Чтобы смягчить это, вместо этого вы можете использовать JWTs, что позволит вам указать дату истечения срока действия в токен, который может быть проверен. Алгоритм HS256 JWT также использует HMAC, также решая эту проблему.

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

UID Вы имеете в виду UUID?

Remember that:

цель в [UUID] должна быть глобально уникальными, чтобы не быть неопределяемыми.

и

[UUID,] предназначены для уникальности, а не для обеспечения безопасности.

Вам будет лучше генерировать 128-разрядный токен на лету, используя безопасный источник энтропии (скажем, другой CSPRNG). Вы можете захотеть использовать эти (без соли) на стороне сервера, используя SHA-256, чтобы предотвратить любую уязвимость утечки данных от значения, которое злоумышленник может проверить на любой адрес электронной почты.