随机数在软件系统里无处不在：会话令牌、密码重置链接、验证码、API密钥、加密盐值，全都依赖随机数的不可预测性。然而很多开发者图方便，直接使用语言内置的普通随机函数，比如Math.random()或rand()，这类函数追求的是速度和统计均匀性，而不是不可预测性。CSPRNG（Cryptographically Secure Pseudo-Random Number Generator，密码学安全伪随机数生成器）专门针对安全场景设计，理解它和普通随机数生成器的区别，是写出安全代码的基本功。
普通PRNG与CSPRNG的本质区别
普通伪随机数生成器（PRNG）的核心是一个确定性算法：给定相同的种子，输出的序列完全一致。以广泛使用的梅森旋转算法（Mersenne Twister）为例，它统计性能优秀、速度快，被Python的random模块、PHP的mt_rand函数等大量采用。但它的内部状态一旦泄露，所有输出都可以被完整复现。更严重的是，研究表明只需观察梅森旋转算法的624个连续32位输出，就能完全恢复其19937位的内部状态，之后既能预测未来输出，也能回推历史输出。
CSPRNG在设计目标上完全不同。它必须满足两个严格的密码学性质：一是抗预测性，即攻击者即使获得任意数量的输出，在计算上也无法以显著高于随机的概率预测下一个输出；二是抗回溯性，即使攻击者某一时刻拿到了生成器的完整内部状态，也无法推出此前的输出序列。为实现这两点，CSPRNG通常会引入密码学原语，比如分组密码、单向哈希函数或消息认证码，并对状态更新做单向化处理。
换一个角度看：普通PRNG解决的是模拟、抽奖、洗牌这类对统计分布有要求但不在乎可预测性的问题；CSPRNG解决的是输出本身就是秘密的问题。混淆这两者的用途，是安全漏洞的常见源头。举例来说，某网站用rand()生成密码重置令牌，攻击者可以先注册账号收集若干令牌，反推出种子后，就能枚举出任意用户的重置链接，实现账号接管。
操作系统层面的熵源与实现机制
应用程序层面的CSPRNG，其随机性最终来自操作系统内核。Linux内核维护一个熵池，通过收集键盘敲击时间间隔、鼠标移动、磁盘IO中断、网卡到达时间等物理事件的不确定性来积累熵。应用层可以通过两个字符设备获取随机数：/dev/random和/dev/urandom。前者在熵不足时会阻塞等待，后者则始终立即返回。Linux内核从4.8版本开始重构了随机数子系统，/dev/urandom的安全性已经得到密码学界的充分认可，日常开发应优先使用它，而/dev/random的阻塞行为反而可能被利用发起拒绝服务攻击。
现代Linux还提供了更推荐的接口：getrandom()系统调用。它解决了/dev/urandom在系统启动早期熵池尚未初始化时就绪的问题，在熵池就绪前会阻塞，之后就不再阻塞，语义上更加安全清晰。看一个C语言的调用示例：
#include <sys/random.h>
#include <stdio.h>
int main() {
unsigned char token[16];
// 从内核CSPRNG获取128位随机数
ssize_t n = getrandom(token, sizeof(token), 0);
if (n != sizeof(token)) {
perror("getrandom failed");
return 1;
}
// 将随机字节转为十六进制字符串用于令牌
for (int i = 0; i < 16; i++) {
printf("%02x", token[i]);
}
printf("\n");
return 0;
}
Windows系统对应的API是BCryptGenRandom（较新的推荐方式）或早期的CryptGenRandom，macOS和iOS上则是SecRandomCopyBytes。这些接口背后都是操作系统经过严格审计的CSPRNG实现，开发者直接使用即可，不要尝试自己设计算法。值得强调的是，虚拟机和容器环境中熵可能相对匮乏，现代内核通过种子文件在重启间延续熵状态，主流云镜像也都做了适配，但在极早期的启动脚本中调用随机数接口仍需留意阻塞可能。
主流语言中CSPRNG的正确用法
几乎所有主流语言都内置了CSPRNG接口，关键是选对函数。下面分别给出PHP、Java、Python的正确示例。先看PHP，正确做法是使用random_bytes和random_int：
<?php // 生成32字节的安全随机数并转为十六进制，适合做API密钥 $key = bin2hex(random_bytes(32)); echo $key . PHP_EOL; // 在指定范围内生成安全随机整数，适合做验证码 $code = random_int(100000, 999999); echo $code . PHP_EOL; // 常见错误示范，千万别用于安全场景： // $weak = mt_rand(100000, 999999); // 可被预测 // $weak = uniqid(); // 基于时间戳，几乎无随机性 // $weak = md5(uniqid()); // 换汤不换药，依然可预测
再看Java。java.util.Random使用48位种子的线性同余生成器，可预测性极强，安全场景必须使用SecureRandom：
import java.security.SecureRandom;
import java.util.Base64;
public class TokenGenerator {
public static void main(String[] args) {
SecureRandom secureRandom = new SecureRandom();
byte[] bytes = new byte[32];
secureRandom.nextBytes(bytes);
String token = Base64.getUrlEncoder().withoutPadding()
.encodeToString(bytes);
System.out.println(token);
}
}
Python的random模块基于梅森旋转，只适合普通用途；安全场景应使用secrets模块，它在Python 3.6后成为官方推荐：
import secrets # 生成适合令牌的随机URL安全字符串 token = secrets.token_urlsafe(32) print(token) # 在序列中安全地随机选择一个元素 charset = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789" code = "".join(secrets.choice(charset) for _ in range(8)) print(code)
JavaScript开发中要区分环境：浏览器里应使用crypto.getRandomValues，Node.js中应使用内建模块的crypto.randomBytes，而Math.random()在两个环境中都不是密码学安全的。无论哪种语言，共同的原则是：函数名或文档中明确提到cryptographic、secure、random secure之类的字样才可信。
常见误用场景与规避建议
第一个高频错误是用时间戳或其哈希值充当随机数。uniqid()、md5(time())这类写法至今仍在不少遗留代码中出现。时间戳的取值空间极小，攻击者只要知道令牌大致生成时间，暴力枚举几分钟内就能命中。同理，以用户ID、用户名加盐哈希来生成令牌也是不安全的，因为这些输入对攻击者来说完全可知。
第二个错误是随机数长度不足或编码不当。生成会话ID或API密钥时，原始熵至少应有128位，也就是16字节以上，实践中常用32字节。另一个细节是进制转换：如果直接用mt_rand(0, 15)拼十六进制字符，实际每个字符只携带4位熵且底层可预测；而random_bytes转十六进制，每个字符携带货真价实的4位安全熵。此外，把随机字节直接塞进URL或日志时记得使用Base64的URL安全变体或十六进制编码，避免特殊字符造成解析问题。
第三个错误是自己播种。有些开发者喜欢给随机数生成器手动设置种子，比如用当前时间，认为这样可控。对CSPRNG而言，手动播种只会降低安全性——操作系统内核维护的熵池和播种策略远比应用层拍脑袋选的种子可靠。除非你在做可复现的科学模拟，否则永远不要自己给CSPRNG设置种子。最后一点建议：对随机令牌类接口，增加代码评审检查项，凡是出现rand、Math.random、uuid v1这类关键词用于安全上下文的，一律视为潜在漏洞处理。UUID的场景也顺带说明一下：版本4的UUID内部使用的是CSPRNG，可以用作标识符，但格式上仅122位熵且带固定版本位，直接当高强度密钥不如random_bytes(32)来得干净利落。