在Web应用中，只要涉及认证、支付回调、接口签名或文件命名，几乎都绕不开随机数的生成。Ruby标准库提供的rand方法用梅森旋转算法产生伪随机数，速度快但结果可以被预测，一旦用它来生成会话令牌或者重置密码链接，攻击者就有可能推算出其他用户的令牌。SecureRandom正是为了解决这个问题而存在，它基于操作系统提供的密码学安全随机源（Linux下的/dev/urandom，Windows下的CryptGenRandom或BCryptGenRandom），生成的结果无法被反向推算。本文将围绕SecureRandom的三类典型应用：会话令牌、Nonce和UUID展开，结合代码示例说明每种场景的正确用法。
一、SecureRandom的底层原理与常用方法
SecureRandom是Ruby标准库的一部分，使用时只需要require 'securerandom'（Ruby 3.x中已自动加载，但显式声明更保险）。它的核心特点是所有随机性都来自操作系统内核维护的熵池，而不是用户态的PRNG算法。Linux内核通过收集键盘中断、磁盘I/O时间戳、鼠标移动等物理事件的不确定性来填充熵池，/dev/urandom则基于这些熵通过ChaCha20等密码学算法输出随机流，保证输出在统计上和密码学上都无法与真随机区分。
正因为如此，SecureRandom的几个方法都值得逐一了解。hex(n)生成2n个字符的十六进制字符串，每个字符携带4位熵；base64(n)生成约4n/3个字符的Base64串；urlsafe_base64(n)把Base64中的加号和斜线替换成连字符和下划线，可以直接放进URL而不需要转义；uuid生成符合RFC 4122版本4规范的UUID字符串；random_number(n)则生成密码学安全的随机整数。下面这段代码展示了各方法的输出形式：
require 'securerandom' SecureRandom.hex(16) # => "5f3a9b7c2d1e4f8a9b0c1d2e3f4a5b6c" SecureRandom.base64(16) # => "X5o0tI0YKCBTL6cPKe3C9A==" SecureRandom.urlsafe_base64(16) # => "X5o0tI0YKCBTL6cPKe3C9A" SecureRandom.uuid # => "8c1f7d3e-2a4b-4c5d-9e6f-1a2b3c4d5e6f" SecureRandom.random_number(1_000_000) # => 482913（0到999999之间的随机整数）
需要注意的是参数的含义：传入的数字是字节数而不是字符串长度。比如hex(16)实际生成32个字符，对应128位熵。安全强度由熵的位数决定，128位通常被视为现代密码学的最低标准，生成会话令牌时建议不低于32字节也就是256位。
二、生成安全的会话令牌与API密钥
会话令牌（Session Token）和API密钥是SecureRandom最常见的用武之地。以一个简单的会话管理为例，用户登录成功后服务端生成一个不可预测的令牌，存入数据库或Redis，同时以Cookie形式下发给客户端。后续请求中客户端携带令牌，服务端据此识别用户身份。整个机制的安全性完全建立在令牌不可猜测这一前提上，这正是SecureRandom的价值所在。
require 'securerandom'
require 'digest'
class Session
def self.create(user_id)
token = SecureRandom.urlsafe_base64(32) # 256位熵，URL安全
# 数据库中只存储哈希值，令牌泄露数据库也不至于全军覆没
token_hash = Digest::SHA256.hexdigest(token)
REDIS.setex("session:#{token_hash}", 3600 * 24, user_id.to_s)
token
end
def self.resolve(token)
token_hash = Digest::SHA256.hexdigest(token)
user_id = REDIS.get("session:#{token_hash}")
user_id&&user_id.to_i
end
end上面的实现有两个细节值得注意。第一，选择urlsafe_base64而不是hex，是因为在同样的熵强度下Base64编码的字符串更短，32字节的熵用hex表示要64个字符，Base64只要43个左右，方便放进Cookie和URL。第二，数据库中存储的是令牌的SHA256哈希而不是原文，这样即使数据库被拖库，攻击者拿到的也只是哈希值，无法反推出有效令牌直接冒充用户，这是目前业界推崇的做法。
常见的错误写法包括：用rand.to_s(36)拼接生成令牌、用Time.now.to_i加用户ID做令牌、或者用SecureRandom.hex(4)这种只带32位熵的短令牌。前两种结果完全可预测，第三种熵值不足，暴力枚举空间只有约40亿，在自动化工具面前不堪一击。生成API密钥时的思路与令牌一致，只是密钥通常生命周期更长，建议加上前缀方便识别用途，例如"sk_" + SecureRandom.hex(24)。
三、Nonce防重放与UUID标识的实践
Nonce（Number used once）指一次性随机值，主要用于防止重放攻击和跨站请求伪造。典型场景是开放API的签名验证：客户端在每个请求中附带一个随机Nonce和时间戳，服务端验证签名通过后把Nonce记入缓存并设置过期时间，如果同一Nonce再次出现就判定为重放请求并拒绝。生成Nonce的代码非常简单，关键在于配套的去重逻辑：
require 'securerandom'
class NonceChecker
TTL = 300 # Nonce有效期5分钟，超过时间戳的请求直接拒绝
def self.valid?(nonce, timestamp)
return false if (Time.now.to_i - timestamp).abs > TTL
# setnx是原子操作，返回true说明该Nonce首次出现
REDIS.setnx("nonce:#{nonce}", 1).tap do |first|
REDIS.expire("nonce:#{nonce}", TTL)
return first
end
end
end
nonce = SecureRandom.hex(16)
timestamp = Time.now.to_i这里用Redis的setnx保证判断与写入的原子性，避免并发请求绕过检查。Nonce本身用hex(16)就足够，128位随机值在5分钟的窗口内碰撞概率可以忽略不计。如果系统对时钟敏感，还要注意客户端与服务端的时间同步问题，必要时放宽时间戳容差或引入服务器下发的时间因子。
UUID方面，SecureRandom.uuid生成的是版本4（随机型）UUID，包含122位随机熵。它广泛用作数据库主键、分布式系统中的对象标识、文件命名等。相比自增ID，UUID可以在客户端独立生成而不依赖数据库，天然适合分布式写入；缺点是无序导致B树索引页分裂较多、占用16字节存储。如果用PostgreSQL，可以考虑用uuid列类型存储二进制形式而不是存36位字符串。另外Rails从5.0开始支持在迁移中直接写t.uuid :identifier, default: 'gen_random_uuid()'，不过当应用侧需要提前拿到ID时，用SecureRandom生成仍是首选。还有一个容易忽略的坑：SecureRandom.uuid的结果中版本位和变体位是固定的4和8、9、a、b，所以它不是完全随机的128位，不要把它当作加密密钥使用。
四、生产环境的最佳实践与总结
把SecureRandom用对，还需要注意几个工程细节。首先是异常处理：SecureRandom.hex等方法在熵源不可用时可能抛出NotImplementedError或RuntimeError，虽然现代系统几乎不会发生，但在启动自检或初始化阶段捕获一下更稳妥。其次是不要复用令牌，每个会话、每次密码重置、每张回调单据都应该生成全新的随机值，绝不能基于旧值做简单变换。再次是日志脱敏，令牌、API密钥、Nonce都不应该原样写进日志，否则日志系统会成为新的泄露点。
# 启动时自检熵源可用性，尽早暴露问题
begin
SecureRandom.hex(16)
puts "SecureRandom 可用，熵源正常"
rescue NotImplementedError => e
abort "当前平台不支持 SecureRandom：#{e.message}"
end
# 封装统一的令牌生成器，统一长度与格式
module TokenGenerator
SESSION_TOKEN_BYTES = 32
def self.session_token
SecureRandom.urlsafe_base64(SESSION_TOKEN_BYTES)
end
def self.api_key
"sk_#{SecureRandom.hex(24)}"
end
def self.nonce
SecureRandom.hex(16)
end
end总结起来，选择SecureRandom方法的思路可以简化为：需要放进URL或Cookie的令牌用urlsafe_base64(32)，需要可读的十六进制串（API签名、加密盐值）用hex，需要全局唯一标识用uuid，需要随机整数用random_number。记住一条底线：任何参与安全决策的随机值都必须来自密码学安全的随机源，rand、Array#sample、时间戳拼接这些便捷手段只适合非安全场景。理解SecureRandom的原理边界，才能在认证、签名、防重放这些关键链路上做到真正可靠。
Ruby SecureRandom会话令牌UUID生成修改时间：2026-09-07 08:06:42