Хэш в URL-адресе и его сравнение строк зависит от времени атаки в php?
Я немного проверяю безопасность моей системы электронной почты для сброса пароля. Это стандартно, используя ссылку на электронную почту, как это:
example.com/password-reset?code=Ik5S7eubvs79nxFCNx04Vdn5RNfb%2BUJRhC0khoHtuHU%3D
Этот код url-кодирует к хешу bcrypt, который сопоставляется с хешем, сгенерированным в базе данных при запросе сброса пароля (и по истечении времени ожидания 24 часа).
Я полагаю, что этот подход довольно стандартен, однако, читая эту статью на эту тему: https://blog.jcoglan.com/2012/06/09/why-you-should-never-use-hash-functions-for-message-authentication/, автор упоминает, что есть временная атака, подразумеваемая при выполнении обычного ==
сравнение по двум строкам, в теории, что любое такое сравнение будет оптимизировано для проверки символ за символом и отклонения на основе первого несовпадающего символа. Это позволит злоумышленнику "пройти" грубую силу, пробираясь сквозь веревку, чтобы в итоге создать матч. Это на самом деле проблема безопасности в php, хотя?
Я предполагаю, что с задержкой в сети и высокой скоростью операции == в php такая временная атака практически невозможна на тривиально коротких строках, потому что она всегда будет маскироваться случайным шумом в то время, когда материал захватывает сеть. Очевидно, что для моего случая исправление короткое (сравните хэши хешей или что-то ужасное в этом роде), но мне интересно, если это действительно прагматическая проблема, за которой я должен следить.
1 ответ
Я думаю, что синхронизированное семя - плохой выбор, даже если ваши хэши недолговечны и привязаны к конкретным пользователям. Вы должны предположить, что ваш исходный код скомпрометирован (даже если это не так). Я бы использовал openssl_random_pseudo_bytes() вместо этого. Вы также должны ограничить возможность пользователя запрашивать сброс пароля (например, не более нескольких раз в день / неделю / и т. Д.)