当前位置: 首页 > 面试题库 >

UUID.randomUUID()是否适合用作一次性密码?

公冶同
2023-03-14
问题内容

正如前面所讨论的,确认电子邮件应该有一个独特的,(几乎)未猜测的代码-
基本上是一个一次性密码 --in确认链接。

UUID.randomUUID()文档说:

使用加密强度高的伪随机数生成器生成UUID。

这是否意味着在正确实现的JVM中的UUID随机生成器适合用作唯一的(实际上)不可猜测的OTP?


问题答案:

否。 根据UUID规范:

不要以为UUID很难猜测;例如,它们不应用作安全功能(仅拥有所有权即可授予访问权限的标识符)。可预测的随机数源将加剧这种情况。

同样,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);
    }
}


 类似资料:
  • 正如前面所讨论的,确认电子邮件应该在确认链接中有一个唯一的(实际上)不可猜测的代码--基本上是一次性密码。 这是否意味着正确实现的JVM中的UUID随机生成器适合用作唯一的(实际上)不可猜测的OTP?

  • 区分度不高的字段不适合做索引,因为索引页是需要有开销的,需要存储的,不过这类字段可以做联合索引的一部分。

  • 我正试图通过服务提供者API在运行时由加载一个jar。然而,结果却是失败的。 以下是我所做的: null 我尝试了抽象类而不是我的SPI接口的接口,当我无法实现我的目标时,将它改回接口; 我已尝试获取资源并将我的作为输入参数传递,但没有工作; 我尝试了Apache实现的,但它也找不到适当的资源; 我的问题是如何通过从外部jar加载资源?SPI可能是一种解决方案吗?

  • 我有一个架构,我们有两个独立的应用程序。原始源是一个sql数据库。App1监听CDC表以跟踪对该数据库中表的更改,对这些更改进行规范化和序列化。它将这些序列化的消息发送到Kafka主题。App2监听该主题,将消息调整为不同的格式,并通过HTTP将调整后的消息发送到各自的目的地。 所以我们的流媒体架构看起来像: SQL(CDC事件)- 我们希望在失败的情况下添加错误处理,并且不能容忍重复事件、丢失事

  • Kafka根据制作者分配的分区将传入的消息分成多个分区。来自分区的消息随后被不同使用者组中的使用者消费。 这种体系结构使我对使用Kafka作为工作/任务队列保持警惕,因为我必须在生产时指定分区,这间接限制了哪些使用者可以在其上工作,因为一个分区只发送给一个使用者组中的一个使用者。我宁愿不要提前指定分区,这样任何一个可以接受该任务的使用者都可以这样做。有没有一种方法可以在Kafka体系结构中构造分区

  • 一次性密码密码是一种Vignere密码,包括以下功能 - 这是一个牢不可破的密码。 密钥与加密的消息长度完全相同。 密钥由随机符号组成。 顾名思义,密钥仅使用一次,并且从不再用于任何其他要加密的消息。 因此,加密消息将容易受到密码分析者的攻击。 用于一次性密码密码的密钥称为pad ,因为它印在纸垫上。 为什么它坚不可摧? 由于以下特点,关键是牢不可破的 - 关键是与给定的消息一样长。 密钥是真正随