Подходит ли UUID.randomUUID () для использования в качестве одноразового пароля?

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

Документы UUID.randomUUID () сказать:

The UUID is generated using a cryptographically strong pseudo random number generator.

Означает ли это, что генератор случайных чисел UUID в правильно реализованной JVM подходит для использования в качестве уникального (практически) не угадываемого OTP?

 steve cook25 авг. 2017 г., 09:06
Также смотрите обсуждение здесь:security.stackexchange.com/questions/890/…
 erickson14 июн. 2012 г., 07:09
Вы можете быть заинтересованы вmy answer to another question, что даст вам больше безопасности с меньшим количеством цифр ... если это имеет значение.

Ответы на вопрос(8)

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

Затем вы собираетесь использовать этот ключ для шифрования значения или вы собираетесь использовать его в качестве фактического пароля? Независимо от этого вам потребуется повторно интерпретировать клавишу в формате, который может быть введен с клавиатуры. Например, выполните преобразование Base64 или Hex или каким-либо образом отобразите значения в буквенно-цифровые значения, в противном случае пользователь будет пытаться ввести байтовые значения, которых нет на клавиатуре.

 cqcallaw14 июн. 2012 г., 06:21
Я планирую встроить код подтверждения в URL-адрес подтверждения, который получатель электронной почты нажимает для подтверждения. Нет необходимости вводить пользователя ...

что злоумышленник не должен уметь угадывать или прогнозировать значение. Как вы можете видеть, чтобы найти правильный код для вашей ссылки подтверждения, UUID длиной 128 битов дает 2 ^ 128 различных возможных кодов, а именно 340,282,366,920,938,463,463,374,607,431,768,211,456 возможных кодов, которые можно попробовать. Я думаю, что ваша ссылка для подтверждения не для запуска ядерного оружия, верно? Злоумышленнику достаточно сложно угадать. Это безопасно.

-- Обновить --

Если вы не доверяетеcryptographically strong Предоставляется генератор случайных чисел, вы можете поместить несколько непредсказуемых параметров с кодом UUID и хэшировать их. Например,

код = SHA1 (UUID, идентификатор процесса, идентификатор потока, номер порта локального подключения, температура процессора)

Это делает его еще сложнее прогнозировать.

 14 июн. 2012 г., 05:25
Только количество сгенерированных битов не делает его непредсказуемым.java.util.Random может использоваться для получения 128 бит данных, но это не означает, что это что-то вроде безопасности.
 14 июн. 2012 г., 06:02
docs.oracle.com/javase/6/docs/api/java/security/… & quot; Криптографически сильное случайное число минимально соответствует тестам статистического генератора случайных чисел, указанным в FIPS 140-2, Требования безопасности для криптографических модулей, раздел 4.9.1. Кроме того, SecureRandom должен производить недетерминированный вывод. Поэтому любой начальный материал, передаваемый объекту SecureRandom, должен быть непредсказуемым, а все выходные последовательности SecureRandom должны быть криптографически стойкими, как описано в RFC 1750: Рекомендации по случайности для безопасности. & Quot;
 14 июн. 2012 г., 05:36
В наши дни люди нападают на зарабатывание денег, а у вас ограниченный бюджет. Ничего не сломано. Так насколько это должно быть безопасно? Суть безопасности в том, сколько они стоят, чтобы ее сломать, и какую выгоду они могут получить? Если это код для ссылки подтверждения на обычном веб-сайте, то это достаточно безопасно. Если это код для ядерного оружия, то я бы так не сказал. Для меня определение защищенного - это стоимость его взлома & gt; & gt; Ожидаемый доход. Если его сломать слишком дорого, и вы можете получить небольшой доход, разбив его, тогда это безопасно.
 14 июн. 2012 г., 05:58
Есть тема про randomUUIDstackoverflow.com/questions/2513573/…
 14 июн. 2012 г., 05:56
@LouisWasserman Вы не можете сравнитьjava.util.Random сUUID.randomUUID()

RFC который определяет UUID и который связан с документами API, вы увидите, что не все биты UUID на самом деле случайны («вариант» и «версия» не случайны). поэтому UUID типа 4 (тот тип, который вы намереваетесь использовать), если он реализован правильно, должен иметь 122 бита (безопасной, для этой реализации) случайной информации из общего размера 128 бит.

так что да, он будет работать так же, как и 122-битное случайное число из «безопасного» генератор.but более короткое значение может содержать достаточное количество случайности и может быть проще для пользователя (может быть, я единственный старомодный человек, который все еще читает электронную почту в терминале, но URL-адреса подтверждения, которые переносятся через строки, раздражают ....).

 06 авг. 2018 г., 10:00
На самом деле дело здесь не в том, что говорит стандарт UUID, а в том, насколько безопасна реализация Java UUID на практике. Итак, насколько безопасен Java RNG для UUID?
 24 нояб. 2014 г., 18:47
На самом деле RFC явно предостерегает от использования UUID в качестве маркеров безопасности: «Не думайте, что UUID трудно угадать; их не следует использовать, например, в качестве средств защиты (идентификаторов, чье простое владение предоставляет доступ) & quot; Сгенерированный UUID4with a secure RNG будет почти невозможно догадаться, но стандарт явно разрешает небезопасные ГСЧ (!).tools.ietf.org/html/rfc4122#section-6   (Извиняюсь за возрождение очень старого комментария, но безопасность - это забота каждого.)
 cqcallaw14 июн. 2012 г., 06:25
Другие дали аналогичные ответы, но это, казалось, было наиболее полным и информативным. Благодарю.

то он непредсказуем и может быть использован.

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

UUID также являются длинными строками (128 бит, а затем обычно Base64 (22 символа) или Base16 (32 символа)) - подумайте о том, насколько удобной будет ваша система. Лично я бы использовал CSRNG, чтобы выбрать 8 буквенно-цифровых символов в случайном порядке и вернуть их.

 cqcallaw14 июн. 2012 г., 06:25
Я не думаю, что возможность предсказать результаты RNG предполагает возможности перехвата электронной почты - это просто означает, что RNG плохо реализован :) Кроме того, я не слишком обеспокоен длиной, потому что я ожидаю встраивания кода в подтверждение URL, который необходимо посетить, чтобы завершить подтверждение.

так как даже я реализовал то же самое для приложения, над которым я работаю. Более того, ссылка, которой вы поделились, говорит сам за себя.

что java.util.UUID должно быть хорошо. Вы можете найти больше информации от этогостатья:

Решение Вопроса

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);
    }
}
 25 мар. 2017 г., 23:21
Я все еще рекомендовал бы использовать крипто-библиотеку явно.
 25 мар. 2017 г., 18:12
UUID spec! = Реализация Java. В то время как спецификация не требует, чтобы UUID был безопасным, реализация Java фактически обеспечивает 122 бита безопасной случайности. Смотрите такжеstackoverflow.com/a/7532965/47528
 26 мар. 2017 г., 13:35
Да, определенно ;-) Когда дело доходит до безопасности, лучше быть осторожным и откровенным. Вы не будете использовать UUID.randomUUID () для систем военного уровня. Но если вопрос таков: «Вводит ли я дыру в безопасности, используя UUID.randomUUID () для токенов»? тогда ответ - нет.
 16 июн. 2017 г., 17:40
Этот ответ в его нынешнем виде - просто дезинформация. В то время как приемлемо сказать, что «UUID», как правило, не следует доверять как OTP, » заявление о том, что Java не следует доверять, фактически неверно. Кроме того, без конкретной рекомендации для альтернативного генератора OTP этот ответ является наиболее бесполезным.
 17 июн. 2017 г., 06:06
Спасибо за ответ. Отредактировано, чтобы включить решение.

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.

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

 cqcallaw14 июн. 2012 г., 06:28
Ваше предложение - мое точное намерение, за исключением того, что я намерен аннулировать UUID, как только URL-адрес подтверждения будет пройден и подтверждение будет завершено.
 06 февр. 2019 г., 16:41
@cqcallaw, что если пользователь никогда не заходит на URL? Я всегда аннулирую такие ключи после 1-го использования или через пару часов, что бы ни произошло 1-го.

Ваш ответ на вопрос