关于java:存储用户密码应该使用什么加密算法

编程开发中，像用户登录注册这种性能很常见，那么对于用户明码解决，咱们该抉择什么样的加密算法呢？在这种场景下，算法须要满足上面两个条件：

算法需不可逆，这样能力无效避免明码泄露。
算法需绝对慢，能够动静调整计算成本，迟缓是应答暴力破解无效形式。

目前来看有这么几个算法 PBKDF2、BCrypt 和 SCrypt 能够满足。咱们先看下旧的明码加密形式。

过来明码加密罕用 MD5 或者 SHA。MD5 是晚期设计的加密哈希，它生成哈希速度很快，随着计算机能力的加强，呈现了被破解的状况，所以又有了一些长度增大的哈希函数，如：SHA-1，SHA-256 等。上面是它们的一些比拟：

MD5：速度快生成短哈希（16 字节）。意外碰撞的概率约为：$1.47 \times 10^{-29} $。
SHA1：比 md5 慢 20%，生成的哈希比 MD5 长一点（20 字节）。意外碰撞的概率约为：$1 \times 10^{-45} $。
SHA256：最慢，通常比 md5 慢 60%，并且生成的哈希长（32 字节）。意外碰撞的概率约为：$4.3 \times 10^{-60} $。

为了确保安全你可能会抉择目前长度最长的哈希 SHA-512，但硬件能力在加强，或者有一天又会发现新的破绽，钻研人员又推出较新的版本，新版本的长度也会越来越长，而且他们也可能会公布底层算法，所以咱们应该另外寻找更适合的算法。

明码平安，除了要抉择足够牢靠的加密算法外，输出数据的强度也要晋升，因为明码是人设置的，其字符长度组合强度不可能统一，如果间接进行哈希存储往往会晋升爆破的概率，这时咱们须要加盐。

加盐是密码学中常常提到的概念，其实就是随机数据。上面是一个 java 中生成盐的例子：

    public static byte[] generateSalt() {SecureRandom random = new SecureRandom();
        byte[] salt = new byte[16];
        random.nextBytes(salt);
        return salt;
    }

SHA-512 加盐哈希明码

    public static String sha512(String rawPassword, byte[] salt) {
        try {MessageDigest md = MessageDigest.getInstance("SHA-512");
            // 加点盐
            md.update(salt);
            return Hex.encodeHexString(md.digest(rawPassword.getBytes(StandardCharsets.UTF_8)));
        } catch (GeneralSecurityException ex) {throw new IllegalStateException("Could not create hash", ex);
        }
    }

PBKDF1和 PBKDF2 是一个 密钥派生函数，其作用就是依据指定的明码短语生成加密密钥。之前在常见加密算法提到过。它尽管不是加密哈希函数，但它依然实用明码存储场景，因为它有足够的安全性，PBKDF2 函数计算如下：

$$
DK = PBKDF2(PRF, Password, Salt, Iterations, HashWidth)
$$

$PRF $ 是伪随机函数两个参数，输入固定的长度（例如，HMAC）；
$Password $ 是生成派生密钥的主明码；
$Salt $ 是加密盐；
$Iterations $ 是迭代次数，次数越多；
$HashWidth $ 是派生密钥的长度；
$DK $ 是生成的派生密钥。

PRF（HMAC）大抵迭代过程，第一次时将 Password 作为密钥和 Salt 传入，而后再将输入后果作为输出反复实现前面迭代。

HMAC：基于哈希的音讯认证码，能够应用共享密钥提供身份验证。比方 HMAC-SHA256，输出须要认证的音讯和密钥进行计算，而后输入 sha256 的哈希值。

PBKDF2 不同于 MD 和 SHA 哈希函数，它通过减少迭代次数晋升了破解难度，并且还能够依据状况进行配置，这使得它具备滑动计算成本。

对于 MD5 和 SHA，攻击者每秒能够猜想数十亿个明码。而应用 PBKDF2，攻击者每秒只能进行几千次猜想（或更少，取决于配置），所以它实用于抗击暴力攻打。

2021 年，OWASP 倡议对 PBKDF2-HMAC-SHA256 应用 310000 次迭代，对 PBKDF2-HMAC-SHA512 应用 120000 次迭代

    public static String pbkdf2Encode(String rawPassword, byte[] salt) {
        try {
            int iterations = 310000;
            int hashWidth = 256;
            PBEKeySpec spec = new PBEKeySpec(rawPassword.toCharArray(), salt, iterations, hashWidth);
            SecretKeyFactory skf = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
            return Base64.getEncoder().encodeToString(skf.generateSecret(spec).getEncoded());
        } catch (GeneralSecurityException ex) {throw new IllegalStateException("Could not create hash", ex);
        }
    }

bcrypt 是基于 eksblowfish 算法设计的 加密哈希函数 ，它最大的特点是：能够动静调整 工作因子（迭代次数）来调整计算速度，因而就算当前计算机能力一直减少，它依然能够抵制暴力攻打。

对于 eksblowfish 算法，它是采纳分组加密模式，并且反对动静设定密钥计算成本（迭代次数）。算法的具体介绍可查看上面文章：

https://www.usenix.org/legacy…

bcrypt 函数输出的明码字符串不超过 72 个字节、蕴含算法标识符、一个计算成本和一个 16 字节（128 位）的盐值。通过输出计算失去 24 字节（192 位）哈希，最终输入格局如下：

$2a$12$DQoa2eT/aXFPgIoGwfllHuj4wEA3F71WWT7E/Trez331HGDUSRvXi
\__/\/ \____________________/\_____________________________/
Alg Cost      Salt                        Hash

$2a$ : bcrypt 算法标识符或叫版本；
12: 工作因子 (2^12 示意 4096 次迭代)
DQoa2eT/aXFPgIoGwfllHu: base64 的盐值；
j4wEA3F71WWT7E/Trez331HGDUSRvXi: 计算后的 Base64 哈希值（24 字节）。

bcrypt 版本

$2a$ : 规定哈希字符串必须是 UTF-8 编码，必须蕴含空终止符。
$2y$ : 该版本为修复 2011 年 6 月 PHP 在 bcrypt 实现中的一个谬误。
$2b$ : 该版本为修复 2014 年 2 月 OpenBSD 在 bcrypt 实现中的一个谬误。

2014 年 2 月在 OpenBSD 的 bcrypt 实现中发现，它应用一个无符号的 8 位值来保留明码的长度。对于长度超过 255 字节的明码，明码将在 72 或长度模 256 中的较小者处被截断，而不是被截断为 72 字节。例如：260 字节的明码将被截断为 4 个字节，而不是截断为 72 个字节。

bcrypt 关键在于设定适合的工作因子，现实的工作因子没有特定的法令，次要还是取决于服务器的性能和应用程序上的用户数量，个别在 安全性 和利用性能 之间衡量设定。

如果你的因子设置比拟高，尽管能够保障攻击者难以破解哈希，然而登录验证也会变慢，重大影响用户体验，而且也可能被攻击者通过大量登录尝试耗尽服务器的 CPU 来执行拒绝服务攻打。一般来说计算哈希的工夫不应该超过一秒。

咱们应用 spring security BCryptPasswordEncoder 看下不同因子下产生哈希的工夫，我电脑配置如下：

处理器：2.2 GHz 四核 Intel Core i7
内存：16 GB 1600 MHz DDR3
显卡：Intel Iris Pro 1536 MB

Map<Integer, BCryptPasswordEncoder> encoderMap = new LinkedHashMap<>();
        for (int i = 8; i <= 21; i++) {encoderMap.put(i, new BCryptPasswordEncoder(i));
        }
        String plainTextPassword = "huhdfJ*!4";
        for (int i : encoderMap.keySet()) {BCryptPasswordEncoder encoder = encoderMap.get(i);
            long start = System.currentTimeMillis();
            encoder.encode(plainTextPassword);
            long end = System.currentTimeMillis();
            System.out.println(String.format("bcrypt | cost: %d, time : %dms", i, end - start));
        }

bcrypt | cost: 8, time : 39ms
bcrypt | cost: 9, time : 45ms
bcrypt | cost: 10, time : 89ms
bcrypt | cost: 11, time : 195ms
bcrypt | cost: 12, time : 376ms
bcrypt | cost: 13, time : 720ms
bcrypt | cost: 14, time : 1430ms
bcrypt | cost: 15, time : 2809ms
bcrypt | cost: 16, time : 5351ms
bcrypt | cost: 17, time : 10737ms
bcrypt | cost: 18, time : 21417ms
bcrypt | cost: 19, time : 43789ms
bcrypt | cost: 20, time : 88723ms
bcrypt | cost: 21, time : 176704ms

拟合失去以下公式：

$$
10.3064 \cdot e^{0.696464 x}
$$

BCryptPasswordEncoder 因子范畴在 4-31，默认是 10，咱们依据公式推导一下 31 时须要多长时间。

    /**
     * @param strength the log rounds to use, between 4 and 31
     */
    public BCryptPasswordEncoder(int strength) {this(strength, null);
    }

$$
10.3064 \cdot e^{0.696464(31)} = 24529665567.08815
$$

工作因子 31 时大略须要 284 天，所以咱们晓得应用 bcrypt 能够很容易的扩大哈希计算过程以适应更快的硬件，为咱们留出很大的回旋余地，以避免攻击者从将来的技术改良中受害。

SCrypt 比下面提到的算法进去较晚，是 Colin Percival 于 2009 年 3 月创立的基于明码的密钥派生函数。对于该算法咱们须要明确上面两点：

该算法专门设计用于通过须要大量内存来执行大规模自定义硬件攻打，老本昂扬。
它属于密钥派生函数和下面提到 PBKDF2 属于同一类别。

Spring security 也实现该算法 SCryptPasswordEncoder，输出参数如下：

CpuCost：算法的 cpu 老本。必须是大于 1 的 2 的幂。默认以后为 16,384 或 2^14)
MemoryCost：算法的内存老本。默认以后为 8。
Parallelization：算法的并行化以后默认为 1。请留神，该实现以后不利用并行化。
KeyLength：算法的密钥长度。以后默认值为 32。
SaltLength：盐长度。以后默认值为 64。

不过也有人提到，并不倡议在生产零碎中应用它来存储明码，他的论断是首先 SCrypt 设计目标是密钥派生函数而不是加密哈希，另外它实现上也并不那么完满。具体可查看上面文章。

https://blog.ircmaxell.com/20…

我会举荐应用 bcrypt。为什么是 bcrypt 呢？

明码存储这种场景下，将明码哈希解决是最好的形式，第一它自身就是加密哈希函数，其次依照摩尔定律的定义，集成系统上每平方英寸的晶体管数量大概每 18 个月翻一番。在 2 年内，咱们能够减少它的工作因子以适应任何变动。

当然这并不是说其它算法不够平安，你依然能够抉择其它算法。倡议优先应用 bcrypt，其次是 密钥派生类 （PBKDF2 和 SCrypt），最初是 哈希 + 盐（SHA256（salt））。

关于java:存储用户密码应该使用什么加密算法

概述

旧的加密

加盐操作

PBKDF2

Bcrypt

简介

构造

实际

SCrypt

论断