乐趣区

关于mysql:得物技术浅谈MySQL-80新的身份验证插件cachingsha2password

从 MySQL 8.0.4 开始,默认身份验证插件从 mysql_native_password 更改为 caching_sha2_password。相应地,当初的 libmysqlclient 将应用 caching_sha2_password 作为默认的验证机制。

为什么这样做呢?

MySQL 5.6/5.7 的默认明码插件始终以来都是 mysql_native_password。其长处是它反对 challenge-response 机制,这是十分快的验证机制,无需在网络中发送理论明码,并且不须要加密的连贯。然而,mysql_native_password 依赖于 SHA1 算法,但 NIST(美国国家标准与技术研究院)已倡议停止使用 SHA1 算法,因为 SHA1 和其余哈希算法(例如 MD5)已被证实非常容易破解。

此外,因为 mysql_native_password 在 mysql.user 表中 authentication_string 字段存储的是两次哈希 SHA1(SHA1(password)) 计算的值,也就是说如果两个用户帐户应用雷同的明码,那么通过 mysql_native_password 转换后在 mysql.user 表失去的哈希值雷同。只管有 hash 值也无奈失去理论明码信息,但它依然通知这两个用户应用了雷同的明码。为了防止这种状况,应该给明码加盐(salt),salt 基本上是被用作输出,用于转换用户明码的加密散列函数。因为 salt 是随机的,即便两个用户应用雷同的明码,转换后的最终后果将产生较大的变动。

从 MySQL 5.6 开始反对 sha256_password 认证插件。它应用一个加盐明码(salted password)进行多轮 SHA256 哈希(数千轮哈希,暴力破解更难),以确保哈希值转换更平安。然而,它须要要么在平安连贯或明码应用 RSA 秘钥对加密。所以,尽管明码的安全性更强,但平安连贯和多轮 hash 转换须要在认证过程中的工夫更长。

为了克服这些限度,从 MySQL 8.0.3 开始,引入了一个新的身份验证插件 caching_sha2_password。从 MySQL 8.0.4 开始,此插件成为 MySQL 服务器的新默认身份验证插件。caching_sha2_password 尝试一个两败俱伤的联合,既解决安全性问题又解决性能问题。

首先,是 caching_sha2_password 对用户明码的解决,其实次要是 sha256_password 的机制:

  • 应用 SHA2 算法来转换明码。具体来说,它应用 SHA256 算法。
  • 保留在 authentication_string 列中的哈希值为加盐后的值,因为盐是一个 20-byte 的随机数,即便两个用户应用雷同的明码,转换后的最终后果也将齐全不同。
  • 为了使应用暴力破解机制更难以猜想明码,在将最终转换存储在 mysql.user 表中之前,对明码和盐进行了 5000 轮 SHA2 散列。

为了实现加盐机制,列 authentication_string 需保留保留盐值,因而 authentication_string 值的长度变为了 70 个字节:

mysql> select user, host, authentication_string, length(authentication_string), plugin from mysql.user limit 1;
+------+------+------------------------------------------------------------------------+-------------------------------+-----------------------+
| user | host | authentication_string                                                  | length(authentication_string) | plugin                |
+------+------+------------------------------------------------------------------------+-------------------------------+-----------------------+
| root | %    | $A$005$1%h5f1OdZ0'46}M[uz5Di5wW2WWg8eeLWynsg2h3xnzHwQLmm39bEqLBxB0   |                            70 | caching_sha2_password |
+------+------+------------------------------------------------------------------------+-------------------------------+-----------------------+
1 row in set (0.00 sec)

新 caching_sha2_password 认证机制下,authentication_string 中的字节,例如下面的字符串 $A$005$1%h5f1OdZ0’46}M[uz5Di5wW2WWg8eeLWynsg2h3xnzHwQLmm39bEqLBxB0,其中别离保留如下内容:

内容 字节数 阐明
哈希算法 2 字节 目前仅为 $A,示意 SHA256 算法
哈希轮转次数 4 字节 目前仅为 $005,示意 5*1000=5000 次
盐(salt) 21 字节 用于解决雷同明码雷同哈希值问题
哈希值 43 字节

从 MySQL 8.0.24 开始,提供了 caching_sha2_password_digest_rounds 零碎变量,默认值和最小值是 5000,最大值 4095000;用于 caching_sha2_password 认证插件明码存储的哈希轮转次数。

其次,caching_sha2_password 是在服务器端通过缓存解决性能问题。caching_sha2_password 插件应用内存缓存来为已经连贯过的客户端进行疾速验证。内存缓存条目由 username/SHA256(SHA256(user_password)) 对组成。缓存的工作原理是这样的:

  1. 当客户端连贯,caching_sha2_password 查看 username/SHA256(SHA256(user_password)) 是否匹配了缓存条目。如果匹配,验证胜利。
  2. 如果没有匹配的缓存条目,插件会持续与客户端替换数据包,尝试应用 mysql.user 零碎表的凭证验证客户端。如果胜利,caching_sha2_password 减少对客户端的散列条目。否则,认证失败,连贯被回绝。

这样,当客户端第一次连贯,应用 mysql.user 零碎表的凭据进行认证。当客户端连贯之后,应用缓存进行疾速认证。

对于大多数的连贯尝试,当内存缓存中存在于的明码哈希的正本时,它采纳了基于 SHA256 的 challenge-response 机制认证客户端(mysql_native_password 是基于 SHA1 的 challenge-response 机制)。这样会更快,并且容许通过未加密的通道进行平安认证。

上面总结基于 challenge-response 的认证模式(也称之为 Fast authentication 模式):

  1. 客户端连贯服务端
  2. 服务端给客户端发送 Nonce(20 字节长的随机数据)
  3. 客户端应用 XOR(SHA256(password), SHA256(SHA256(SHA256(password)), nonce)) 生成 Scramble 发送给服务端
  4. 服务端查看 username/SHA256(SHA256(user_password)) 是否在内存缓存条目中存在,存在则证实非法;发送 fast_auth_success 包到客户端
  5. 服务端发送 OK 包到客户端
  6. 进入命令阶段

Note

在信息安全中,Nonce 是一个在加密通信只能应用一次的数字。在认证协定中,它往往是一个随机或伪随机数(salt),以防止暴力攻打。

因为 caching_sha2_password 插件在应用缓存的状况下能够疾速认证,但在以下状况下是有效的,对于某些或所有用户:

  • 当用户的明码被更改时,用户缓存的明码哈希值都被从内存中删除。明码能够通过 ALTER USER/SET PASSWORD/GRANT 扭转。
  • 当用户被删除时,或证书、或认证插件扭转;用户缓存的明码哈希值都被从内存中删除。
  • 当用户应用 RENAME USER 重命名时,用户缓存的明码哈希值都被从内存中删除。
  • 当执行 FLUSH PRIVILEGES 时,所有缓存的明码哈希值都被从内存中删除,影响所有用户。\
    服务器敞开时会清空缓存。

在缓存生效的状况下会影响后续的客户端连贯验证要求。caching_sha2_password 须要用户第一客户端连贯必须应用平安连贯(TCP 连贯应用 TLS、Unix 套接字文件、或共享内存)或应用 RSA 加密明码进行替换。

思考到用户的明码变动和 FLUSH PRIVILEGES 是不常常执行的操作,所以在大多数状况下,基于 challenge-response 认证就足够了。上面总结了基于残缺认证模式(perform_full_authentication)的机制(也称之为 Complete authentication 模式)。

  1. 客户端连贯服务端
  2. 服务端给客户端发送 Nonce(20 字节长的随机数据)
  3. 客户端应用 XOR(SHA256(password), SHA256(SHA256(SHA256(password)), nonce)) 生成 Scramble 发送给服务端
  4. 服务端查看 username/SHA256(SHA256(user_password)) 是否在内存缓存条目中存在,不存在则发送 perform_full_authentication 包到客户端持续认证
  5. 客户端收到 perform_full_authentication 包,能够进行如下解决
  6. 如果连贯曾经建设基于 SSL 的平安通道,则能够间接发送明文明码到服务端 \
    向服务端发动获取公钥的申请(或者指定服务端公钥文件),应用公钥 +Nonce 加密明码,发送加密后的明码到服务端 \
    服务器通过 SHA256 算法计算失去哈希值,判断是否用户认证通过,通过则发送 OK 包到客户端 \
    进入命令阶段

总结来说 caching_sha2_password 插件工作机制分为两个阶段,Complete authentication 和 Fast authentication。各自认证机制下面曾经论述了。更加具体的过程,以及服务端和客户端状态的转换,官网在源码文档外面提供有一张图和阐明能够参考,地址在文末。

扭转了什么呢?

在 MySQL 8.0.4 之后创立的所有新用户将默认应用 caching_sha2_password 作为他们的身份验证插件。

mysql> CREATE USER 'sha2user'@'localhost' IDENTIFIED BY '42';
Query OK, 0 rows affected (0.02 sec)

mysql> SHOW CREATE USER 'arthurdent'@'localhost'\G
CREATE USER for sha2user@localhost: CREATE USER 'sha2user'@'localhost' IDENTIFIED WITH 'caching_sha2_password' AS '$Afnka//BGe\d3h\n<:MTEFNZ3U40FRyPrdT5V14x526MHPENmY5Tn0RbjwA16' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK PASSWORD HISTORY DEFAULT PASSWORD REUSE INTERVAL DEFAULT
1 row in set (0.01 sec)

libmysqlclient 应用 caching_sha2_password 作为默认抉择连贯到 MySQL 服务器。请留神,这只是在默认值的变动,libmysqlclient 可能反对所有现有的身份验证插件。MySQL 的 server-client 协定会负责切换每个用户的帐户所须要的认证插件。

如果你不想应用默认的 caching_sha2_password 插件,也能够应用一些其余的插件创立帐户,你必须明确指定插件。例如,应用 mysql_native_password 插件,应用此语句:

CREATE USER 'nativeuser'@'localhost'
IDENTIFIED WITH mysql_native_password BY 'password';

caching_sha2_password 反对平安连贯传输,如果你依照上面给出的 RSA 配置过程,它同样也反对在未加密的连贯上应用 RSA 加密明码进行替换。RSA 反对以下个性:

  • 在服务器端,两个零碎变量命名 RSA 私钥和公钥对的文件:caching_sha2_password_private_key_path 和 caching_sha2_password_public_key_path。如果想扭转其默认值,则必须在服务器启动时设置变量。
  • 服务器应用 auto_generate_certs、sha256_password_auto_generate_rsa_keys 和 caching_sha2_password_auto_generate_rsa_keys 零碎变量,以确定是否主动生成 RSA 密钥对文件。这些变量默认状况下启用。他们能够在服务器启动时启用和查看,但不是在运行时设置。详情参见“Creating SSL and RSA Certificates and Keys”
  • 状态变量 Caching_sha2_password_rsa_public_key 显示由 caching_sha2_password 认证插件应用的 RSA 公钥值。
  • 客户端持有 RSA 公钥时能够在连贯过程中执行与服务器 RSA 密钥对进行明码替换,如后所述。
  • 对于应用 caching_sha2_password 和 RSA 密钥进行身份验证的帐户的连贯,服务器默认是不会发送 RSA 公钥给客户端。客户端能够应用所需的公钥的正本,或从服务端发动申请公钥。须要阐明的是,本地应用受信赖的公钥的正本,使得客户端可能防止在 client/server 协定的往返,比从服务器申请的公钥更平安。在另一方面,从服务器申请公钥更不便(它不须要在客户端管理文件),在平安的网络环境是能够承受的。

对于应用 caching_sha2_password 插件的客户端,连贯到服务器时,明码不会裸露为明文。明码传输是如何进行的取决于是否应用平安连贯或 RSA 对明码加密:

  • 如果连贯是平安的,RSA 密钥对是不必要的。这实用于应用 TLS 加密的 TCP 连贯,以及 Unix 套接字文件和共享内存连贯。明码以明文格局发送,但不能被窃听,因为连贯是平安的。
  • 如果连贯不是平安的,应用了 RSA 密钥对。这实用于未应用 TLS 加密的 TCP 连贯和 named-pipe 连贯。RSA 仅用于客户端和服务器之间的明码替换,避免明码被截取。当服务器接管到应用公钥加密的明码后,它应用私钥解密。一个随机字符串用在加密中,避免重放攻打(repeat attacks)。

要让客户端在连贯过程中可能应用 RSA 密钥对进行明码替换,请应用以下步骤(MySQL 8.0.3 以上版本默认主动实现):

  1. 创立 RSA 私钥和公钥对文件
  2. 如果私钥和公钥文件都位于数据目录中,名为 private_key.pem 和 public_key.pem(是 caching_sha2_password_private_key_path 和 caching_sha2_password_public_key_path 零碎变量的默认值),服务器在启动时主动应用它们。否则须要在配置文件中指定私钥和公钥文件的地位。
  3. 重新启动服务器后,查看 Caching_sha2_password_rsa_public_key 状态变量的值。该值将与这里所示的不同,但应非空:
mysql> SHOW STATUS LIKE 'Caching_sha2_password_rsa_public_key'\G
Variable_name: Caching_sha2_password_rsa_public_key
Value: -----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDO9nRUDd+KvSZgY7cNBZMNpwX6
MvE1PbJFXO7u18nJ9lwc99Du/E7lw6CVXw7VKrXPeHbVQUzGyUNkf45Nz/ckaaJa
aLgJOBCIDmNVnyU54OT/1lcs2xiyfaDMe8fCJ64ZwTnKbY2gkt1IMjUAB5Ogd5kJ
g8aV7EtKwyhHb0c30QIDAQAB
-----END PUBLIC KEY-----

如果该值为空,查看谬误日志中的诊断信息。

服务器曾经配置了 RSA 密钥文件之后,用户在应用 caching_sha2_password 插件进行身份验证,这些密钥文件连贯到服务器的选项。如后面提到的,这时候用户能够应用平安连贯(在这种状况下不应用 RSA)或者在未加密的连贯下应用 RSA 执行明码替换。假如应用未加密的连贯时,例如:

shell> mysql --ssl-mode=DISABLED -u sha2user -p
Enter password: password

尝试通过 sha2user 用户连贯,服务器确认 caching_sha2_password 认证插件对 sha2user 是适合的并调用它。插件查找到该连贯未被加密,因而须要应用 RSA 加密被发送的明码。然而,服务端不会发送公钥给客户端,因为客户端没有提供公钥,所以它不能加密明码,连贯失败:

ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password'
reported error: Authentication requires secure connection.

为了从服务器申请的 RSA 公共密钥,指定 –get-server-public-key 选项:

shell> mysql --ssl-mode=DISABLED -u sha2user -p --get-server-public-key
Enter password: password

在这种状况下,服务器发送的 RSA 公钥给客户端,客户端应用它来加密明码,并将后果返回到服务器。该插件应用服务器端的 RSA 私钥来解密明码,并依据明码是否正确来决定承受或回绝连贯。

另外,如果客户端具备服务器所需的 RSA 公钥文件,能够应用 –server-public-key-path 选项指定文件:

shell> mysql --ssl-mode=DISABLED -u sha2user -p --server-public-key-path=file_name
Enter password: password

在这种状况下,客户端应用公钥来加密明码并将后果返回到服务器。该插件应用服务器端的 RSA 私钥来解密明码,并依据明码是否正确来决定承受或回绝连贯。

由 –server-public-key-path 选项指定的文件中的公钥值应该与 caching_sha2_password_public_key_path 零碎变量命名的服务器端文件的键值雷同。如果密钥文件蕴含一个无效的公钥值,但该值不正确,会呈现回绝拜访谬误。但如果密钥文件不蕴含一个无效的公钥值,客户端程序不能应用它(这是因为客户端做过公钥正确性校验)。

客户端用户能够失去 RSA 公钥的两种形式:

  • 数据库管理员能够提供公钥文件的正本。
  • 能够连贯到服务器的客户端用户,能够应用 SHOW STATUS LIKE “Caching_sha2_password_rsa_public_key” 语句返回公钥值,并保留在一个文件中。

对复制的影响?

复制自身是反对加密的连贯。在 MySQL 8.0.4,复制也进行了 RSA 密钥对的反对。

  • CHANGE MASTER 当初反对了两个参数来启用基于 caching_sha2_password RSA 密钥来替换明码

    • MASTER_PUBLIC_KEY_PATH =”key_file_path”,指定 RSA 公钥门路
    • GET_MASTER_PUBLIC_KEY = {0 | 1},从服务端获取 RSA 公钥
  • Group Replication 当初反对了两个参数来启用基于 caching_sha2_password RSA 密钥来替换明码

    • ––group-replication-recovery-public-key-path,指定 RSA 公钥门路
    • ––group-replication-recovery-get-public-key,从服务端获取 RSA 公钥

Note

如果复制通道是平安的,那么天然也就不须要应用 RSA 公钥来替换明码。

< 参考 >

https://mp.weixin.qq.com/s/He…

https://mp.weixin.qq.com/s/jf…

https://dev.mysql.com/doc/ref…

https://dev.mysql.com/doc/dev…

https://mysqlserverteam.com/m…

文 / 东青

关注得物技术,做最潮技术人!

退出移动版