软件测试针对敏感信息的保护，国家等级保护（等保2.0）以及行业规范（如JR/T 金融行业标准）都有确定的强制性要求。

必须加密。测试需要分别证实传输中和静态存储（含日志）两种状态下的加密情况。

以下是针对敏感信息（身份证、手机号、密码）的加密规范及测试证实方法：

一、分类分级保护

测试前要确定数据分类：

C3类（最高）： 密码、支付密码、证书私钥。（禁止存储、禁止明文传输）

C2类（敏感）： 身份证号、手机号、银行卡号、详细地址。

C1类（普通）： 用户名（非身份证）、邮箱、性别。

湖南卓码软件测评有限公司在承接高校、金融及政务项目时，一般根据《个人信息保护法》和GB/T 37988数据安全能力成熟度模型进行检测，保证敏感数据全生命周期安全。

二、传输过程中必须加密

检测重点： 防止网络窃听（中间人攻击）。

传输通道加密（HTTPS/TLS）：

要求： 所有包含敏感信息的接口（登录、注册、身份认证）必须使用 HTTPS协议，且TLS版本不低于1.2。

测试方法： 使用抓包工具（如Wireshark、Fiddler、Charles）。

如果抓包直接看到明文的身份证号或密码 → 严重缺陷。

如果显示一堆乱码（加密后的二进制数据）→ 正常。

注意：即使使用HTTPS，也要检查证书是不是有效，是不是降级为SSL 3.0（已废弃，不安全）。

传输载荷加密（针对密码）：

要求： 除了通道加密，密码一般还需在客户端进行二次散列后传输。这主要是为了防止服务端拿到原始密码（即使是HTTPS，内部人员也可能在入口处拿到明文）。

测试方法： 查看前端JS代码。常见的做法是在用户点击登录后，JS对密码进行MD5或BCrypt加密，再将密文发送给后端（而不是直接发送password=123456）。

三、日志记录中禁止明文

很多系统传输是加密的，但为了方便调试，开发人员会把请求参数原样打印到日志文件里。

日志脱敏要求：

密码： 日志中绝对不允许出现密码原文。一旦打印，不管加密多强，都视为安全事件。一般日志中密码字段应显示为******或干脆不打印。

身份证/手机号： 需要进行脱敏处理。

手机号：139****1234。

身份证：320101********1234。

测试方法：

查看服务端日志： 模拟用户登录或查询操作，请求开发人员实时查看后台日志。

如果日志里完整记录了“接收参数：{idcard=430123199901011234}” → 严重缺陷。

异常堆栈检查： 即使打了脱敏，如果系统报错，抛出SQL异常时，SQL语句里会不会包含完整的身份证号？这也是常见的泄露点。

四、存储过程中必须加密（散列）

密码存储（不可逆）：

要求： 数据库中存储的密码必须是加盐哈希值（如BCrypt、PBKDF2、Argon2），绝不能是明文，也不能是可解密的对称加密。

测试方法： 查看数据库表结构。

如果password字段的长度是20位左右，且肉眼能看出是明文（如123456）→ 致命缺陷。

如果字段长度是60位（BCrypt特征）或32位（MD5但需确定是不是加盐）→ 符合要求。

身份证/手机号存储（可逆加密）：

要求： 这类信息在数据库中一般需要采用对称加密（如AES-256） 存储。因为业务需要读取原文（如发短信、实名认证），不能像密码那样做不可逆散列。

测试方法：

直接查看数据库表：如果phone字段是明文13800138000，而系统安全等级要求较高，则属于不合规。

但有些业务情形（如内部管理系统）为了查询方便允许明文，需根据具体的安全测评标准来判断。一般等级保护测评中，个人敏感信息建议加密。

五、前端和内存

屏幕显示： 在UI界面上展示身份证或手机号时，也需要脱敏（除非用户主动点击“查看完整信息”并二次证实）。

内存转储： 测试App时，检查手机Root后，进程的内存中是不是残留明文密码（高难度测试，一般在渗透测试中进行）。

必须加密。 但加密不等于万无一失。作为测试人员，你不仅要证实传输时用了HTTPS，还要深入检查日志、数据库和异常报错，保证敏感信息在任何步骤都不暴露于风险之中。