跳转至

30 如何正确保存和传输敏感数据?

你好,我是朱晔。

今天,我们从安全角度来聊聊用户名、密码、身份证等敏感信息,应该怎么保存和传输。同时,你还可以进一步复习加密算法中的散列、对称加密和非对称加密算法,以及HTTPS等相关知识。

应该怎样保存用户密码?

最敏感的数据恐怕就是用户的密码了。黑客一旦窃取了用户密码,或许就可以登录进用户的账号,消耗其资产、发布不良信息等;更可怕的是,有些用户至始至终都是使用一套密码,密码一旦泄露,就可以被黑客用来登录全网。

为了防止密码泄露,最重要的原则是不要保存用户密码。你可能会觉得很好笑,不保存用户密码,之后用户登录的时候怎么验证?其实,我指的是不保存原始密码,这样即使拖库也不会泄露用户密码。

我经常会听到大家说,不要明文保存用户密码,应该把密码通过MD5加密后保存。这的确是一个正确的方向,但这个说法并不准确。

首先,MD5其实不是真正的加密算法。所谓加密算法,是可以使用密钥把明文加密为密文,随后还可以使用密钥解密出明文,是双向的。

而MD5是散列、哈希算法或者摘要算法。不管多长的数据,使用MD5运算后得到的都是固定长度的摘要信息或指纹信息,无法再解密为原始数据。所以,MD5是单向的。最重要的是,仅仅使用MD5对密码进行摘要,并不安全

比如,使用如下代码在保持用户信息时,对密码进行了MD5计算:

UserData userData = new UserData();
userData.setId(1L);
userData.setName(name);
//密码字段使用MD5哈希后保存
userData.setPassword(DigestUtils.md5Hex(password));
return userRepository.save(userData);

通过输出,可以看到密码是32位的MD5:

"password": "325a2cc052914ceeb8c19016c091d2ac"

到某MD5破解网站上输入这个MD5,不到1秒就得到了原始密码:

其实你可以想一下,虽然MD5不可解密,但是我们可以构建一个超大的数据库,把所有20位以内的数字和字母组合的密码全部计算一遍MD5存进去,需要解密的时候搜索一下MD5就可以得到原始值了。这就是字典表。

目前,有些MD5解密网站使用的是彩虹表,是一种使用时间空间平衡的技术,即可以使用更大的空间来降低破解时间,也可以使用更长的破解时间来换取更小的空间。

此外,你可能会觉得多次MD5比较安全,其实并不是这样。比如,如下代码使用两次MD5进行摘要:

userData.setPassword(DigestUtils.md5Hex(DigestUtils.md5Hex( password)));

得到下面的MD5:

"password": "ebbca84993fe002bac3a54e90d677d09"

也可以破解出密码,并且破解网站还告知我们这是两次MD5算法:

所以直接保存MD5后的密码是不安全的。一些同学可能会说,还需要加盐。是的,但是加盐如果不当,还是非常不安全,比较重要的有两点。

第一,不能在代码中写死盐,且盐需要有一定的长度,比如这样:

userData.setPassword(DigestUtils.md5Hex("salt" + password));

得到了如下MD5:

"password": "58b1d63ed8492f609993895d6ba6b93a"

对于这样一串MD5,虽然破解网站上找不到原始密码,但是黑客可以自己注册一个账号,使用一个简单的密码,比如1:

"password": "55f312f84e7785aa1efa552acbf251db"

然后,再去破解网站试一下这个MD5,就可以得到原始密码是salt,也就知道了盐值是salt:

其实,知道盐是什么没什么关系,关键的是我们是在代码里写死了盐,并且盐很短、所有用户都是这个盐。这么做有三个问题:

  • 因为盐太短、太简单了,如果用户原始密码也很简单,那么整个拼起来的密码也很短,这样一般的MD5破解网站都可以直接解密这个MD5,除去盐就知道原始密码了。
  • 相同的盐,意味着使用相同密码的用户MD5值是一样的,知道了一个用户的密码就可能知道了多个。
  • 我们也可以使用这个盐来构建一张彩虹表,虽然会花不少代价,但是一旦构建完成,所有人的密码都可以被破解。

所以,最好是每一个密码都有独立的盐,并且盐要长一点,比如超过20位

第二,虽然说每个人的盐最好不同,但我也不建议将一部分用户数据作为盐。比如,使用用户名作为盐:

userData.setPassword(DigestUtils.md5Hex(name + password));

如果世界上所有的系统都是按照这个方案来保存密码,那么root、admin这样的用户使用再复杂的密码也总有一天会被破解,因为黑客们完全可以针对这些常用用户名来做彩虹表。所以,盐最好是随机的值,并且是全球唯一的,意味着全球不可能有现成的彩虹表给你用。

正确的做法是,使用全球唯一的、和用户无关的、足够长的随机值作为盐。比如,可以使用UUID作为盐,把盐一起保存到数据库中:

userData.setSalt(UUID.randomUUID().toString());
userData.setPassword(DigestUtils.md5Hex(userData.getSalt() + password));

并且每次用户修改密码的时候都重新计算盐,重新保存新的密码。你可能会问,盐保存在数据库中,那被拖库了不是就可以看到了吗?难道不应该加密保存吗?

在我看来,盐没有必要加密保存。盐的作用是,防止通过彩虹表快速实现密码“解密”,如果用户的盐都是唯一的,那么生成一次彩虹表只可能拿到一个用户的密码,这样黑客的动力会小很多。

更好的做法是,不要使用像MD5这样快速的摘要算法,而是使用慢一点的算法。比如Spring Security已经废弃了MessageDigestPasswordEncoder,推荐使用BCryptPasswordEncoder,也就是BCrypt来进行密码哈希。BCrypt是为保存密码设计的算法,相比MD5要慢很多。

写段代码来测试一下MD5,以及使用不同代价因子的BCrypt,看看哈希一次密码的耗时。

private static BCryptPasswordEncoder passwordEncoder = new BCryptPasswordEncoder();

@GetMapping("performance")
public void performance() {
    StopWatch stopWatch = new StopWatch();
    String password = "Abcd1234";
    stopWatch.start("MD5");
    //MD5
    DigestUtils.md5Hex(password);
    stopWatch.stop();
    stopWatch.start("BCrypt(10)");
    //代价因子为10的BCrypt
    String hash1 = BCrypt.gensalt(10);
    BCrypt.hashpw(password, hash1);
    System.out.println(hash1);
    stopWatch.stop();
    stopWatch.start("BCrypt(12)");
    //代价因子为12的BCrypt
    String hash2 = BCrypt.gensalt(12);
    BCrypt.hashpw(password, hash2);
    System.out.println(hash2);
    stopWatch.stop();
    stopWatch.start("BCrypt(14)");
    //代价因子为14的BCrypt
    String hash3 = BCrypt.gensalt(14);
    BCrypt.hashpw(password, hash3);
    System.out.println(hash3);
    stopWatch.stop();
    log.info("{}", stopWatch.prettyPrint());
}

可以看到,MD5只需要0.8毫秒,而三次BCrypt哈希(代价因子分别设置为10、12和14)耗时分别是82毫秒、312毫秒和1.2秒:

也就是说,如果制作8位密码长度的MD5彩虹表需要5个月,那么对于BCrypt来说,可能就需要几十年,大部分黑客应该都没有这个耐心。

我们写一段代码观察下,BCryptPasswordEncoder生成的密码哈希的规律:

@GetMapping("better")
public UserData better(@RequestParam(value = "name", defaultValue = "zhuye") String name, @RequestParam(value = "password", defaultValue = "Abcd1234") String password) {
    UserData userData = new UserData();
    userData.setId(1L);
    userData.setName(name);
    //保存哈希后的密码
    userData.setPassword(passwordEncoder.encode(password));
    userRepository.save(userData);
    //判断密码是否匹配
    log.info("match ? {}", passwordEncoder.matches(password, userData.getPassword()));
    return userData;
}

我们可以发现三点规律。

第一,我们调用encode、matches方法进行哈希、做密码比对的时候,不需要传入盐。BCrypt把盐作为了算法的一部分,强制我们遵循安全保存密码的最佳实践。

第二,生成的盐和哈希后的密码拼在了一起:$是字段分隔符,其中第一个$后的2a代表算法版本,第二个$后的10是代价因子(默认是10,代表2的10次方次哈希),第三个$后的22个字符是盐,再后面是摘要。所以说,我们不需要使用单独的数据库字段来保存盐。

"password": "$2a$10$wPWdQwfQO2lMxqSIb6iCROXv7lKnQq5XdMO96iCYCj7boK9pk6QPC"
//格式为:$<ver>$<cost>$<salt><digest>

第三,代价因子的值越大,BCrypt哈希的耗时越久。因此,对于代价因子的值,更建议的实践是,根据用户的忍耐程度和硬件,设置一个尽可能大的值。

最后,我们需要注意的是,虽然黑客已经很难通过彩虹表来破解密码了,但是仍然有可能暴力破解密码,也就是对于同一个用户名使用常见的密码逐一尝试登录。因此,除了做好密码哈希保存的工作外,我们还要建设一套完善的安全防御机制,在感知到暴力破解危害的时候,开启短信验证、图形验证码、账号暂时锁定等防御机制来抵御暴力破解。

应该怎么保存姓名和身份证?

我们把姓名和身份证,叫做二要素。

现在互联网非常发达,很多服务都可以在网上办理,很多网站仅仅依靠二要素来确认你是谁。所以,二要素是比较敏感的数据,如果在数据库中明文保存,那么数据库被攻破后,黑客就可能拿到大量的二要素信息。如果这些二要素被用来申请贷款等,后果不堪设想。

之前我们提到的单向散列算法,显然不适合用来加密保存二要素,因为数据无法解密。这个时候,我们需要选择真正的加密算法。可供选择的算法,包括对称加密和非对称加密算法两类。

对称加密算法,是使用相同的密钥进行加密和解密。使用对称加密算法来加密双方的通信的话,双方需要先约定一个密钥,加密方才能加密,接收方才能解密。如果密钥在发送的时候被窃取,那么加密就是白忙一场。因此,这种加密方式的特点是,加密速度比较快,但是密钥传输分发有泄露风险。

非对称加密算法,或者叫公钥密码算法。公钥密码是由一对密钥对构成的,使用公钥或者说加密密钥来加密,使用私钥或者说解密密钥来解密,公钥可以任意公开,私钥不能公开。使用非对称加密的话,通信双方可以仅分享公钥用于加密,加密后的数据没有私钥无法解密。因此,这种加密方式的特点是,加密速度比较慢,但是解决了密钥的配送分发安全问题。

但是,对于保存敏感信息的场景来说,加密和解密都是我们的服务端程序,不太需要考虑密钥的分发安全性,也就是说使用非对称加密算法没有太大的意义。在这里,我们使用对称加密算法来加密数据。

接下来,我就重点与你说说对称加密算法。对称加密常用的加密算法,有DES、3DES和AES。

虽然,现在仍有许多老项目使用了DES算法,但我不推荐使用。在1999年的DES挑战赛3中,DES密码破解耗时不到一天,而现在DES密码破解更快,使用DES来加密数据非常不安全。因此,在业务代码中要避免使用DES加密

而3DES算法,是使用不同的密钥进行三次DES串联调用,虽然解决了DES不够安全的问题,但是比AES慢,也不太推荐。

AES是当前公认的比较安全,兼顾性能的对称加密算法。不过严格来说,AES并不是实际的算法名称,而是算法标准。2000年,NIST选拔出Rijndael算法作为AES的标准。

AES有一个重要的特点就是分组加密体制,一次只能处理128位的明文,然后生成128位的密文。如果要加密很长的明文,那么就需要迭代处理,而迭代方式就叫做模式。网上很多使用AES来加密的代码,使用的是最简单的ECB模式(也叫电子密码本模式),其基本结构如下:

可以看到,这种结构有两个风险:明文和密文是一一对应的,如果明文中有重复的分组,那么密文中可以观察到重复,掌握密文的规律;因为每一个分组是独立加密和解密的 ,如果密文分组的顺序,也可以反过来操纵明文,那么就可以实现不解密密文的情况下,来修改明文。

我们写一段代码来测试下。在下面的代码中,我们使用ECB模式测试:

  • 加密一段包含16个字符的字符串,得到密文A;然后把这段字符串复制一份成为一个32个字符的字符串,再进行加密得到密文B。我们验证下密文B是不是重复了一遍的密文A。
  • 模拟银行转账的场景,假设整个数据由发送方账号、接收方账号、金额三个字段构成。我们尝试改变密文中数据的顺序来操纵明文。
private static final String KEY = "secretkey1234567"; //密钥
//测试ECB模式
@GetMapping("ecb")
public void ecb() throws Exception {
    Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding");
    test(cipher, null);
}
//获取加密秘钥帮助方法
private static SecretKeySpec setKey(String secret) {
    return new SecretKeySpec(secret.getBytes(), "AES");
}
//测试逻辑
private static void test(Cipher cipher, AlgorithmParameterSpec parameterSpec) throws Exception {
    //初始化Cipher
    cipher.init(Cipher.ENCRYPT_MODE, setKey(KEY), parameterSpec);
    //加密测试文本
    System.out.println("一次:" + Hex.encodeHexString(cipher.doFinal("abcdefghijklmnop".getBytes())));
    //加密重复一次的测试文本
    System.out.println("两次:" + Hex.encodeHexString(cipher.doFinal("abcdefghijklmnopabcdefghijklmnop".getBytes())));
    //下面测试是否可以通过操纵密文来操纵明文    
    //发送方账号
    byte[] sender = "1000000000012345".getBytes();
    //接收方账号
    byte[] receiver = "1000000000034567".getBytes();
    //转账金额
    byte[] money = "0000000010000000".getBytes();
    //加密发送方账号
    System.out.println("发送方账号:" + Hex.encodeHexString(cipher.doFinal(sender)));
    //加密接收方账号
    System.out.println("接收方账号:" + Hex.encodeHexString(cipher.doFinal(receiver)));
    //加密金额
    System.out.println("金额:" + Hex.encodeHexString(cipher.doFinal(money)));
    //加密完整的转账信息
    byte[] result = cipher.doFinal(ByteUtils.concatAll(sender, receiver, money));
    System.out.println("完整数据:" + Hex.encodeHexString(result));
    //用于操纵密文的临时字节数组
    byte[] hack = new byte[result.length];
    //把密文前两段交换
    System.arraycopy(result, 16, hack, 0, 16);
    System.arraycopy(result, 0, hack, 16, 16);
    System.arraycopy(result, 32, hack, 32, 16);
    cipher.init(Cipher.DECRYPT_MODE, setKey(KEY), parameterSpec);
    //尝试解密
    System.out.println("原始明文:" + new String(ByteUtils.concatAll(sender, receiver, money)));
    System.out.println("操纵密文:" + new String(cipher.doFinal(hack)));
}

输出如下:

可以看到:

  • 两个相同明文分组产生的密文,就是两个相同的密文分组叠在一起。
  • 在不知道密钥的情况下,我们操纵密文实现了对明文数据的修改,对调了发送方账号和接收方账号。

所以说,ECB模式虽然简单,但是不安全,不推荐使用。我们再看一下另一种常用的加密模式,CBC模式。

CBC模式,在解密或解密之前引入了XOR运算,第一个分组使用外部提供的初始化向量IV,从第二个分组开始使用前一个分组的数据,这样即使明文是一样的,加密后的密文也是不同的,并且分组的顺序不能任意调换。这就解决了ECB模式的缺陷:

我们把之前的代码修改为CBC模式,再次进行测试:

 private static final String initVector = "abcdefghijklmnop"; //初始化向量

@GetMapping("cbc")
public void cbc() throws Exception {
    Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding");
    IvParameterSpec iv = new IvParameterSpec(initVector.getBytes("UTF-8"));
    test(cipher, iv);
}

可以看到,相同的明文字符串复制一遍得到的密文并不是重复两个密文分组,并且调换密文分组的顺序无法操纵明文:

其实,除了ECB模式和CBC模式外,AES算法还有CFB、OFB、CTR模式,你可以参考这里了解它们的区别。《实用密码学》一书比较推荐的是CBC和CTR模式。还需要注意的是,ECB和CBC模式还需要设置合适的填充模式,才能处理超过一个分组的数据。

对于敏感数据保存,除了选择AES+合适模式进行加密外,我还推荐以下几个实践:

  • 不要在代码中写死一个固定的密钥和初始化向量,最好和之前提到的盐一样,是唯一、独立并且每次都变化的。
  • 推荐使用独立的加密服务来管控密钥、做加密操作,千万不要把密钥和密文存在一个数据库,加密服务需要设置非常高的管控标准。
  • 数据库中不能保存明文的敏感信息,但可以保存脱敏的信息。普通查询的时候,直接查脱敏信息即可。

接下来,我们按照这个策略完成相关代码实现。

第一步,对于用户姓名和身份证,我们分别保存三个信息,脱敏后的明文、密文和加密ID。加密服务加密后返回密文和加密ID,随后使用加密ID来请求加密服务进行解密:

@Data
@Entity
public class UserData {
    @Id
    private Long id;
    private String idcard;//脱敏的身份证
    private Long idcardCipherId;//身份证加密ID
    private String idcardCipherText;//身份证密文
    private String name;//脱敏的姓名
    private Long nameCipherId;//姓名加密ID
    private String nameCipherText;//姓名密文
}

第二步,加密服务数据表保存加密ID、初始化向量和密钥。加密服务表中没有密文,实现了密文和密钥分离保存:

@Data
@Entity
public class CipherData {
    @Id
    @GeneratedValue(strategy = AUTO)
    private Long id;
    private String iv;//初始化向量
    private String secureKey;//密钥
}

第三步,加密服务使用GCM模式( Galois/Counter Mode)的AES-256对称加密算法,也就是AES-256-GCM。

这是一种AEAD(Authenticated Encryption with Associated Data)认证加密算法,除了能实现普通加密算法提供的保密性之外,还能实现可认证性和密文完整性,是目前最推荐的AES模式。

使用类似GCM的AEAD算法进行加解密,除了需要提供初始化向量和密钥之外,还可以提供一个AAD(附加认证数据,additional authenticated data),用于验证未包含在明文中的附加信息,解密时不使用加密时的AAD将解密失败。其实,GCM模式的内部使用的就是CTR模式,只不过还使用了GMAC签名算法,对密文进行签名实现完整性校验。

接下来,我们实现基于AES-256-GCM的加密服务,包含下面的主要逻辑:

  • 加密时允许外部传入一个AAD用于认证,加密服务每次都会使用新生成的随机值作为密钥和初始化向量。
  • 在加密后,加密服务密钥和初始化向量保存到数据库中,返回加密ID作为本次加密的标识。
  • 应用解密时,需要提供加密ID、密文和加密时的AAD来解密。加密服务使用加密ID,从数据库查询出密钥和初始化向量。

这段逻辑的实现代码比较长,我加了详细注释方便你仔细阅读:

@Service
public class CipherService {
    //密钥长度
    public static final int AES_KEY_SIZE = 256;
    //初始化向量长度
    public static final int GCM_IV_LENGTH = 12;
    //GCM身份认证Tag长度
    public static final int GCM_TAG_LENGTH = 16;
    @Autowired
    private CipherRepository cipherRepository;

    //内部加密方法
    public static byte[] doEncrypt(byte[] plaintext, SecretKey key, byte[] iv, byte[] aad) throws Exception {
        //加密算法
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        //Key规范
        SecretKeySpec keySpec = new SecretKeySpec(key.getEncoded(), "AES");
        //GCM参数规范
        GCMParameterSpec gcmParameterSpec = new GCMParameterSpec(GCM_TAG_LENGTH * 8, iv);
        //加密模式
        cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmParameterSpec);
        //设置aad
        if (aad != null)
            cipher.updateAAD(aad);
        //加密
        byte[] cipherText = cipher.doFinal(plaintext);
        return cipherText;
    }

    //内部解密方法
    public static String doDecrypt(byte[] cipherText, SecretKey key, byte[] iv, byte[] aad) throws Exception {
        //加密算法
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        //Key规范
        SecretKeySpec keySpec = new SecretKeySpec(key.getEncoded(), "AES");
        //GCM参数规范
        GCMParameterSpec gcmParameterSpec = new GCMParameterSpec(GCM_TAG_LENGTH * 8, iv);
        //解密模式
        cipher.init(Cipher.DECRYPT_MODE, keySpec, gcmParameterSpec);
        //设置aad
        if (aad != null)
            cipher.updateAAD(aad);
        //解密
        byte[] decryptedText = cipher.doFinal(cipherText);
        return new String(decryptedText);
    }

    //加密入口
    public CipherResult encrypt(String data, String aad) throws Exception {
        //加密结果
        CipherResult encryptResult = new CipherResult();
        //密钥生成器
        KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
        //生成密钥
        keyGenerator.init(AES_KEY_SIZE);
        SecretKey key = keyGenerator.generateKey();
        //IV数据
        byte[] iv = new byte[GCM_IV_LENGTH];
        //随机生成IV
        SecureRandom random = new SecureRandom();
        random.nextBytes(iv);
        //处理aad
        byte[] aaddata = null;
        if (!StringUtils.isEmpty(aad))
            aaddata = aad.getBytes();
        //获得密文
        encryptResult.setCipherText(Base64.getEncoder().encodeToString(doEncrypt(data.getBytes(), key, iv, aaddata)));
        //加密上下文数据
        CipherData cipherData = new CipherData();
        //保存IV
        cipherData.setIv(Base64.getEncoder().encodeToString(iv));
        //保存密钥
        cipherData.setSecureKey(Base64.getEncoder().encodeToString(key.getEncoded()));
        cipherRepository.save(cipherData);
        //返回本地加密ID
        encryptResult.setId(cipherData.getId());
        return encryptResult;
    }

    //解密入口
    public String decrypt(long cipherId, String cipherText, String aad) throws Exception {
        //使用加密ID找到加密上下文数据
        CipherData cipherData = cipherRepository.findById(cipherId).orElseThrow(() -> new IllegalArgumentException("invlaid cipherId"));
        //加载密钥
        byte[] decodedKey = Base64.getDecoder().decode(cipherData.getSecureKey());
        //初始化密钥
        SecretKey originalKey = new SecretKeySpec(decodedKey, 0, decodedKey.length, "AES");
        //加载IV
        byte[] decodedIv = Base64.getDecoder().decode(cipherData.getIv());
        //处理aad
        byte[] aaddata = null;
        if (!StringUtils.isEmpty(aad))
            aaddata = aad.getBytes();
        //解密
        return doDecrypt(Base64.getDecoder().decode(cipherText.getBytes()), originalKey, decodedIv, aaddata);
    }
}

第四步,分别实现加密和解密接口用于测试。

我们可以让用户选择,如果需要保护二要素的话,就自己输入一个查询密码作为AAD。系统需要读取用户敏感信息的时候,还需要用户提供这个密码,否则无法解密。这样一来,即使黑客拿到了用户数据库的密文、加密服务的密钥和IV,也会因为缺少AAD无法解密:

@Autowired
private CipherService cipherService;


//加密
@GetMapping("right")
public UserData right(@RequestParam(value = "name", defaultValue = "朱晔") String name,
                      @RequestParam(value = "idcard", defaultValue = "300000000000001234") String idCard,
                      @RequestParam(value = "aad", required = false)String aad) throws Exception {
    UserData userData = new UserData();
    userData.setId(1L);
    //脱敏姓名
    userData.setName(chineseName(name));
    //脱敏身份证
    userData.setIdcard(idCard(idCard));
    //加密姓名
    CipherResult cipherResultName = cipherService.encrypt(name,aad);
    userData.setNameCipherId(cipherResultName.getId());
    userData.setNameCipherText(cipherResultName.getCipherText());
    //加密身份证
    CipherResult cipherResultIdCard = cipherService.encrypt(idCard,aad);
    userData.setIdcardCipherId(cipherResultIdCard.getId());
    userData.setIdcardCipherText(cipherResultIdCard.getCipherText());
    return userRepository.save(userData);
}

//解密
@GetMapping("read")
public void read(@RequestParam(value = "aad", required = false)String aad) throws Exception {
    //查询用户信息
    UserData userData = userRepository.findById(1L).get();
    //使用AAD来解密姓名和身份证
    log.info("name : {} idcard : {}",
            cipherService.decrypt(userData.getNameCipherId(), userData.getNameCipherText(),aad),
            cipherService.decrypt(userData.getIdcardCipherId(), userData.getIdcardCipherText(),aad));

}
//脱敏身份证
private static String idCard(String idCard) {
    String num = StringUtils.right(idCard, 4);
    return StringUtils.leftPad(num, StringUtils.length(idCard), "*");
}
//脱敏姓名
public static String chineseName(String chineseName) {
    String name = StringUtils.left(chineseName, 1);
    return StringUtils.rightPad(name, StringUtils.length(chineseName), "*");

访问加密接口获得如下结果,可以看到数据库表中只有脱敏数据和密文:

{"id":1,"name":"朱*","idcard":"**************1234","idcardCipherId":26346,"idcardCipherText":"t/wIh1XTj00wJP1Lt3aGzSvn9GcqQWEwthN58KKU4KZ4Tw==","nameCipherId":26347,"nameCipherText":"+gHrk1mWmveBMVUo+CYon8Zjj9QAtw=="}

访问解密接口,可以看到解密成功了:

[21:46:00.079] [http-nio-45678-exec-6] [INFO ] [o.g.t.c.s.s.StoreIdCardController:102 ] - name : 朱晔 idcard : 300000000000001234

如果AAD输入不对,会得到如下异常:

javax.crypto.AEADBadTagException: Tag mismatch!
    at com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:578)
    at com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1116)
    at com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1053)
    at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853)
    at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
    at javax.crypto.Cipher.doFinal(Cipher.java:2164)

经过这样的设计,二要素就比较安全了。黑客要查询用户二要素的话,需要同时拿到密文、IV+密钥、AAD。而这三者可能由三方掌管,要全部拿到比较困难。

用一张图说清楚HTTPS

我们知道,HTTP协议传输数据使用的是明文。那在传输敏感信息的场景下,如果客户端和服务端中间有一个黑客作为中间人拦截请求,就可以窃听到这些数据,还可以修改客户端传过来的数据。这就是很大的安全隐患。

为解决这个安全隐患,有了HTTPS协议。HTTPS=SSL/TLS+HTTP,通过使用一系列加密算法来确保信息安全传输,以实现数据传输的机密性、完整性和权威性。

  • 机密性:使用非对称加密来加密密钥,然后使用密钥来加密数据,既安全又解决了非对称加密大量数据慢的问题。你可以做一个实验来测试两者的差距。
  • 完整性:使用散列算法对信息进行摘要,确保信息完整无法被中间人篡改。
  • 权威性:使用数字证书,来确保我们是在和合法的服务端通信。

可以看出,理解HTTPS的流程,将有助于我们理解各种加密算法的区别,以及证书的意义。此外,SSL/TLS还是混合加密系统的一个典范,如果你需要自己开发应用层数据加密系统,也可以参考它的流程。

那么,我们就来看看HTTPS TLS 1.2连接(RSA握手)的整个过程吧。

作为准备工作,网站管理员需要申请并安装CA证书到服务端。CA证书中包含非对称加密的公钥、网站域名等信息,密钥是服务端自己保存的,不会在任何地方公开。

建立HTTPS连接的过程,首先是TCP握手,然后是TLS握手的一系列工作,包括:

  1. 客户端告知服务端自己支持的密码套件(比如TLS_RSA_WITH_AES_256_GCM_SHA384,其中RSA是密钥交换的方式,AES_256_GCM是加密算法,SHA384是消息验证摘要算法),提供客户端随机数。
  2. 服务端应答选择的密码套件,提供服务端随机数。
  3. 服务端发送CA证书给客户端,客户端验证CA证书(后面详细说明)。
  4. 客户端生成PreMasterKey,并使用非对称加密+公钥加密PreMasterKey。
  5. 客户端把加密后的PreMasterKey传给服务端。
  6. 服务端使用非对称加密+私钥解密得到PreMasterKey,并使用PreMasterKey+两个随机数,生成MasterKey。
  7. 客户端也使用PreMasterKey+两个随机数生成MasterKey。
  8. 客户端告知服务端之后将进行加密传输。
  9. 客户端使用MasterKey配合对称加密算法,进行对称加密测试。
  10. 服务端也使用MasterKey配合对称加密算法,进行对称加密测试。

接下来,客户端和服务端的所有通信都是加密通信,并且数据通过签名确保无法篡改。你可能会问,客户端怎么验证CA证书呢?

其实,CA证书是一个证书链,你可以看一下上图的左边部分:

  • 从服务端拿到的CA证书是用户证书,我们需要通过证书中的签发人信息找到上级中间证书,再网上找到根证书。
  • 根证书只有为数不多的权威机构才能生成,一般预置在OS中,根本无法伪造。
  • 找到根证书后,提取其公钥来验证中间证书的签名,判断其权威性。
  • 最后再拿到中间证书的公钥,验证用户证书的签名。

这,就验证了用户证书的合法性,然后再校验其有效期、域名等信息进一步验证有效性。

总结一下,TLS通过巧妙的流程和算法搭配解决了传输安全问题:使用对称加密加密数据,使用非对称加密算法确保密钥无法被中间人解密;使用CA证书链认证,确保中间人无法伪造自己的证书和公钥。

如果网站涉及敏感数据的传输,必须使用HTTPS协议。作为用户,如果你看到网站不是HTTPS的或者看到无效证书警告,也不应该继续使用这个网站,以免敏感信息被泄露。

重点回顾

今天,我们一起学习了如何保存和传输敏感数据。我来带你回顾一下重点内容。

对于数据保存,你需要记住两点:

  • 用户密码不能加密保存,更不能明文保存,需要使用全球唯一的、具有一定长度的、随机的盐,配合单向散列算法保存。使用BCrypt算法,是一个比较好的实践。
  • 诸如姓名和身份证这种需要可逆解密查询的敏感信息,需要使用对称加密算法保存。我的建议是,把脱敏数据和密文保存在业务数据库,独立使用加密服务来做数据加解密;对称加密需要用到的密钥和初始化向量,可以和业务数据库分开保存。

对于数据传输,则务必通过SSL/TLS进行传输。对于用于客户端到服务端传输数据的HTTP,我们需要使用基于SSL/TLS的HTTPS。对于一些走TCP的RPC服务,同样可以使用SSL/TLS来确保传输安全。

最后,我要提醒你的是,如果不确定应该如何实现加解密方案或流程,可以咨询公司内部的安全专家,或是参考业界各大云厂商的方案,切勿自己想当然地去设计流程,甚至创造加密算法。

今天用到的代码,我都放在了GitHub上,你可以点击这个链接查看。

思考与讨论

  1. 虽然我们把用户名和密码脱敏加密保存在数据库中,但日志中可能还存在明文的敏感数据。你有什么思路在框架或中间件层面,对日志进行脱敏吗?
  2. 你知道HTTPS双向认证的目的是什么吗?流程上又有什么区别呢?

关于各种加密算法,你还遇到过什么坑吗?你又是如何保存敏感数据的呢?我是朱晔,欢迎在评论区与我留言分享你的想法,也欢迎你把今天的内容分享给你的朋友或同事,一起交流。

精选留言(15)
  • 大胖子呀、 👍(39) 💬(4)

    老师说不能直接对密码进行md5加密,那我心想可以加盐,老师又说盐不要写死,我又想可以用用户名作为盐,接着老师就又说不建议用用户名做盐,应该uuid生成,我就想那保存到数据库不也可以被黑客获取到吗?最后老师又说:有的同学可能又要问了…… 可恶啊,这些都在你的计算当中啊!

    2020-05-26

  • 那时刻 👍(15) 💬(1)

    1.关于日志脱敏,可以在日志处理模块里通过正则表达式对于敏感词比如username匹配后,做模糊字符输出到日志里。 2.https双向认证指的是服务器额外校验客户端证书,方便控制某个接口是否允许客户端访问,用于第三方服务调用。流程上多了客户端提交自己证书和服务器校验证书等步骤。 小伙伴们讨论的云平台使用的secretid和secrestkey。云平台更推荐使用临时的IAM来替代吧。

    2020-05-26

  • 👽 👍(6) 💬(4)

    敏感数据的话,其实还有一个: 就是第三方的一些验证数据。类似于阿里云的Id和key。 我未进行加密保存在配置文件中,并且还将其上传在了GitHub上,按理说,如果Github泄露了,任何人都可以调用我的资源了。因为是透支额度设置的很低,而且余额只有10¥,所以未作安全处理。因为最坏的结果,也就是把我余额全用完。 1,如果需要涉及到加密,我会考虑到分开存储: 可能ID存数据库,Key存本地文件。(鸡蛋分在多个篮子里存放,脱库或者服务器被黑,也只有一部分数据泄露,依然无法使用我的服务) 2,然后加密存放,因为调用服务需要读取,所以必须是可逆的加密算法。增加破译的成本。 3,定期监控,出问题及时发现。

    2020-05-26

  • 旅途 👍(5) 💬(3)

    老师 密码使用对称加密或非对称加密不行吗 使用自己的算法进行加密 别人也破解不了

    2020-05-26

  • Joker 👍(3) 💬(1)

    关于彩虹表的解释在这里:https://www.zhihu.com/question/19790488,简单想象成一个黑盒吧,你传进加密后的密码,就能得到解密后的密码。但是构造这黑盒的过程就比较麻烦了。但是如果密文都是根据一个字符串根据特定的规则得到的字符串,哪怕是根据用户信息来构造一个盐,那么就有很大的概率出现,构造了一个彩虹表就把整个数据库的密码给解密了的情况。构造彩虹表的过程虽然麻烦,却是一劳永逸的,那么就要想一个不那么一劳永逸的方法,所以就出现了每次都用一个随机盐的方式。 因为如果是固定的盐的话,那么黑客得到一套数据库之后,只要构造一套彩虹表就能得到结果了。如果每次的盐都不同,那么黑客就要每次都根据密文和盐构造一套彩虹表。 我就是这么理解的,不知道是否正确。密码学真的难。

    2020-05-28

  • J.Smile 👍(3) 💬(1)

    记得一次面试,别人问我https的原理,其实我是理解的,但是记不住这个过程,怎么办?😂

    2020-05-27

  • Geek 👍(2) 💬(2)

    老师好,保护用户二要素AAD在实际会用在哪些场景中,是否用户忘记了自己设置的AAD就没办法类似于重置密码的方式找回AAD了,也就没办法再解密信息?

    2020-05-31

  • 👽 👍(2) 💬(3)

    我的理解,没有绝对的安全。现有的一切加密安全措施,其实只是增加破解的难度罢了。真正的安全,还是需要验证码之类的动态验证。 我一直以来,理解的加密就分两种:可逆的,不可逆的。 可逆的:规定了一种规律,只要应用这种规律就可以逆推其原始值。我认为其实雪花算法就是可逆的加密算法。知道其运算规律,也可以逆推其创建时间。虽然明文中无法体现其创建时间。 不可逆的:自己的密码是12,加密后是3,已知了算法是所有数位之和,但是并无逆推出原始数值是111,003,03,102......等。 但是,无论可逆还是不可逆,破解也是寻找其规律罢了。加密其实本质也是,对结果附加运算过程。 原始密码 x+a-b*c?d = 密文x1,在足够多的数据样本的时候,我觉得还是可以逆推出原始数据。(解方程嘛。。。) 我觉得,现在的密码加密,维持个三五年之后,也会被轻易破解。 其实要是简单粗暴一点,就手机验证码登录,就已经基本OK了,大平台似乎也都是这么做的。类似于某里云。在一些不太重要的数据,就处理的可以适当放开一些。

    2020-05-26

  • Bill陈锋 👍(1) 💬(1)

    秘钥读mi4yue4 听着太难受了

    2023-09-02

  • 汝林外史 👍(1) 💬(1)

    老师,一般的http访问登录,是不是密码加密需要在客户端做,如果不加密传给服务端的话,那密码不就暴露出来,通过浏览器工具是不是就可以看到form提交的数据?

    2021-01-28

  • kacaric 👍(1) 💬(1)

    请问老师接口能否采用https双向认证保证接口安全,还需要在接口中额外增加签名字段吗?

    2020-06-13

  • 阿冲 👍(1) 💬(3)

    请问老师脱敏后的数据如何做SQL查询,这个条件怎么处理。比如身份证号和姓名字段?

    2020-06-10

  • 👍(0) 💬(1)

    ”数据库存一个哈希值,查询的话哈希后查询,需要展示的时候再解密“;老师,hash后查询是不是只能处理精确匹配的场景,而不能做模糊查询,而且有可能hash冲突查出来的结果不是想要的。

    2020-09-11

  • 牛年榴莲 👍(0) 💬(2)

    用户身份证号加密存储了,如果要根据身份证号查询的话,要使用密文,将明文转换至密文需要秘钥,可是在查询到这个用户之前,我也不知道秘钥是啥,这个怎么处理呢? 还有一种场景,一般网站中,用户的手机号是唯一的,如果也加密存储起来的话,怎么在用户注册的时候判断手机号是否已存在呢?

    2020-09-10

  • 握了个大蚂蚱 👍(4) 💬(0)

    规模巨大的隐私数据尤其公司搞国际化的业务,应该都会有一个全局的点来管理隐私数据,业务流转的时候都不需要流转明文,相当于拿个令牌流转,到需要置换,显示时,再去兑换,根据需要兑换不同等级的明文(匿名值,完整明文)。 hash的盐我们是初始化一个map里面放10000个盐,然后把字符串的char转为int再对10000取模得到这个字符串对应的盐。这样好处是盐具有复杂性而又保证hash算法的根本:相同铭文hash后得到相同hash,缺点是用在密码上的话可能会被看出相同密码的数据,需要再加一层处理

    2020-06-05