Подходит ли UUID.randomUUID () для использования в качестве одноразового пароля?
Какпредыдущий обсуждалсяПисьма с подтверждением должны иметь уникальный (практически) не угадываемый код - по сутиодноразовый пароль- в ссылке для подтверждения.
Документы UUID.randomUUID () сказать:
The UUID is generated using a cryptographically strong pseudo random number generator.
Означает ли это, что генератор случайных чисел UUID в правильно реализованной JVM подходит для использования в качестве уникального (практически) не угадываемого OTP?
Ответы на вопрос(8)
что это должно быть подходящим, поскольку оно генерируется случайным образом, а не из какого-либо конкретного ввода (т. Е. Вы не вводите его с именем пользователя или чем-то в этом роде), поэтому множественные вызовы этого кода будут давать разные результаты. В нем говорится, что это 128-битный ключ, поэтому он достаточно длинный, чтобы его невозможно было сломать.
Затем вы собираетесь использовать этот ключ для шифрования значения или вы собираетесь использовать его в качестве фактического пароля? Независимо от этого вам потребуется повторно интерпретировать клавишу в формате, который может быть введен с клавиатуры. Например, выполните преобразование Base64 или Hex или каким-либо образом отобразите значения в буквенно-цифровые значения, в противном случае пользователь будет пытаться ввести байтовые значения, которых нет на клавиатуре.
что злоумышленник не должен уметь угадывать или прогнозировать значение. Как вы можете видеть, чтобы найти правильный код для вашей ссылки подтверждения, UUID длиной 128 битов дает 2 ^ 128 различных возможных кодов, а именно 340,282,366,920,938,463,463,374,607,431,768,211,456 возможных кодов, которые можно попробовать. Я думаю, что ваша ссылка для подтверждения не для запуска ядерного оружия, верно? Злоумышленнику достаточно сложно угадать. Это безопасно.
-- Обновить --
Если вы не доверяетеcryptographically strong Предоставляется генератор случайных чисел, вы можете поместить несколько непредсказуемых параметров с кодом UUID и хэшировать их. Например,
код = SHA1 (UUID, идентификатор процесса, идентификатор потока, номер порта локального подключения, температура процессора)
Это делает его еще сложнее прогнозировать.
java.util.Random может использоваться для получения 128 бит данных, но это не означает, что это что-то вроде безопасности.java.util.Random сUUID.randomUUID()RFC который определяет UUID и который связан с документами API, вы увидите, что не все биты UUID на самом деле случайны («вариант» и «версия» не случайны). поэтому UUID типа 4 (тот тип, который вы намереваетесь использовать), если он реализован правильно, должен иметь 122 бита (безопасной, для этой реализации) случайной информации из общего размера 128 бит.
так что да, он будет работать так же, как и 122-битное случайное число из «безопасного» генератор.but более короткое значение может содержать достаточное количество случайности и может быть проще для пользователя (может быть, я единственный старомодный человек, который все еще читает электронную почту в терминале, но URL-адреса подтверждения, которые переносятся через строки, раздражают ....).
то он непредсказуем и может быть использован.
Но проблема, к которой вы идете, будет потрачена впустую, если вы отправляете электронные письма с подтверждением в незашифрованном виде - если у злоумышленника есть возможность прогнозировать результаты ГСЧ из вашей системы, то есть вероятность, что они также могут перехватывать электронные письма.
UUID также являются длинными строками (128 бит, а затем обычно Base64 (22 символа) или Base16 (32 символа)) - подумайте о том, насколько удобной будет ваша система. Лично я бы использовал CSRNG, чтобы выбрать 8 буквенно-цифровых символов в случайном порядке и вернуть их.
так как даже я реализовал то же самое для приложения, над которым я работаю. Более того, ссылка, которой вы поделились, говорит сам за себя.
No. СогласноUUID спецификация:
Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.
Кроме того, UUID имеют только 16 возможных символов (от 0 до F). Вы можете создать намного более компактный и явно безопасный случайный пароль, используяSecureRandom (спасибо @erickson).
import java.security.SecureRandom;
import java.math.BigInteger;
public final class PasswordGenerator {
private SecureRandom random = new SecureRandom();
public String nextPassword() {
return new BigInteger(130, random).toString(32);
}
}
java.util.UUID Это хорошо. Не так много, что нужно сказать.
Вот мое предложение:
Send the user a link with a huge password in it as the URL argument. When user clicks the link, write your backend so that it will determine whether or not the argument is correct and that the user is logged in. Invalidate the UUID 24 hours after it has been issued.Это займет некоторую работу, но это необходимо, если вы действительно хотите написать надежную и безопасную систему.