Zcash RPC 认证与 rpcauth 凭据生成基于 rpcuser.py 构建多用户安全登录【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcashZcash 节点的 JSON-RPC 接口默认需要认证后才能调用rpcauth是官方推荐的凭据方案它允许为每个登录用户单独生成用户名 盐 HMAC-SHA256 哈希三元组明文密码只出现在生成瞬间配置文件中永不落盘。本文以 share/rpcuser/README.md 与配套工具 share/rpcuser/rpcuser.py 为主线讲解凭据生成、zcash.conf配置、服务端校验原理与多用户管理读完即可为本地或远程 Zcash 节点配置一套可审计、可撤销的多用户 RPC 登录体系。RPC 认证背景为什么需要 rpcauthZcash 的 JSON-RPC 服务由 src/httprpc.cpp 实现通过 HTTP Basic Authentication 校验调用者身份。历史上节点只支持在配置文件中同时声明rpcuser与rpcpassword这对单用户凭据但从 src/httprpc.cpp 的InitRPCAuthentication()可以看出这套方案正被逐步淘汰未设置rpcpassword时节点会调用GenerateAuthCookie生成随机认证 cookie见 src/rpc/protocol.cpp并把__cookie__:base64写入数据目录下的.cookie文件客户端据此自动登录仍在使用rpcuser/rpcpassword时节点会打印弃用警告并明确提示请参见 share/rpcuser 获取 rpcauth 认证的生成方式rpcauth则是替代二者的多用户方案-rpcauthuserpw格式为USERNAME:SALT$HASH且该选项可以重复指定多次见 src/init.cpp 的参数帮助文本。因此rpcauth的定位是在配置文件中只保存不可逆的哈希值而不是明文口令。即使配置文件泄露攻击者也无法直接得到可用密码。rpcuser.py官方凭据生成工具share/rpcuser/README.md 对该工具的描述只有两行——Create an RPC user login credential创建 RPC 用户登录凭据用法为./rpcuser.py username但背后的实现细节相当值得展开。通读 share/rpcuser/rpcuser.py 的完整源码其工作流程可分为四步随机盐借助SystemRandom底层即os.urandom()生成 16 字节随机序列再格式化为 32 位十六进制字符串作为 salt随机密码用os.urandom(32)生成 32 字节随机数据经base64.urlsafe_b64encode编码得到密码因此密码是 43 个字符左右的 URL 安全 Base64 串具备约 256 bit 熵HMAC-SHA256 摘要以 salt 为密钥、以密码为消息计算hmac.new(salt, password, sha256)的十六进制摘要脚本兼容 Python 2 与 Python 3Python 3 下会切换为SHA256字符串形式的 digestmod 参数输出打印追加到zcash.conf的完整行以及一次性明文密码。实际输出形如String to be appended to zcash.conf: rpcauthalice:9f2d3e1a7b4c5d6e0f1a2b3c4d5e6f7a$8a9b... Your password: kX3vQpLmWnRzTuYwZbAcDeFgHiJkLmNoPqRsTuVwXyZ其中rpcauth之后依次是用户名、十六进制盐、$分隔符和 64 位十六进制 HMAC 摘要。明文密码只在终端里出现一次请立即安全保存之后无论重启节点还是重新生成配置都无法再从哈希反推出它。实战生成凭据并配置 zcash.conf单用户配置在仓库根目录下直接执行脚本即可脚本 shebang 声明为 Python 2但兼容 Python 3也可显式用python3调用python3 share/rpcuser/rpcuser.py alice将输出的rpcauthalice:...一行追加到节点的zcash.conf配置文件例如# zcash.conf server1 rpcbind127.0.0.1 rpcauthalice:9f2d3e1a7b4c5d6e0f1a2b3c4d5e6f7a$8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8随后启动zcashd。客户端调用时使用生成时打印的明文密码构造 Basic Auth 头curl --user alice:kX3vQpLmWnRzTuYwZbAcDeFgHiJkLmNoPqRsTuVwXyZ \ --data-binary {jsonrpc:1.0,id:curltest,method:getblockchaininfo,params:[]} \ -H content-type: text/plain; \ http://127.0.0.1:8232/多用户配置由于-rpcauth选项可以指定多次多个用户只需在配置文件中并列多行rpcauthalice:9f2d3e1a7b4c5d6e0f1a2b3c4d5e6f7a$8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8 rpcauthbob:c4f7a91e2b3d5e6f0a1b2c3d4e5f6a7b$1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f这样alice与bob各自持有独立密码可分别发放与吊销无需为每个用户重启节点时重写全局凭据。服务端校验原理从 HTTP 头到 HMAC 重算rpcauth的校验逻辑集中在 src/httprpc.cpp调用链清晰可循HTTPReq_JSONRPC只接受 POST 请求src/httprpc.cpp随后读取authorization请求头缺失或校验失败时返回401并附带WWW-Authenticate响应头RPCAuthorized解析 Basic Auth 头要求前缀为Basic对剩余部分做 Base64 解码还原出用户名:密码先与单用户凭据strRPCUserColonPass即rpcuser:rpcpassword做TimingResistantEqual常量时间比较不匹配则进入multiUserAuthorized遍历配置中所有-rpcauth条目src/httprpc.cpp按:与$分割为用户名、盐、哈希三个字段字段数不为 3 视为格式错误并跳过用TimingResistantEqual比较用户名用CHMAC_SHA256(salt, password)重新计算摘要对应 src/crypto/hmac_sha256.h 的 HMAC-SHA256 实现再与配置中的哈希做常量时间比较任一用户匹配即放行。值得注意的是C 端重算 HMAC 的方式与rpcuser.py完全对称脚本以 salt 为密钥、密码为消息生成摘要服务端同样以 salt 作为密钥写入CHMAC_SHA256构造函数以明文密码作为消息写入Write()。这种只存哈希、验证时重算的设计保证了配置文件里永远没有明文口令。同时该路径还内置了针对暴力破解的缓解手段src/httprpc.cpp认证失败时先记录一条ThreadRPCServer incorrect password attempt from IP日志再MilliSleep(250)强制停顿 250 毫秒后才返回 401从源码注释看这是为了阻止暴力破解如果这导致 DoS说明用户本就不该暴露 RPC 端口。客户端的认证回退cookie 与 rpcauth 的配合值得补充的是rpcauth与 cookie 认证并非互斥。在 src/bitcoin-cli.cpp 中zcash-cli的逻辑是若配置了rpcpassword则使用rpcuser:rpcpassword否则回退到读取节点数据目录下的.cookie文件完成认证对应服务端的GenerateAuthCookie/GetAuthCookie见 src/rpc/protocol.cpp。因此存在两种典型组合本机自动化场景节点不配置任何rpcuser/rpcpassword由随机 cookie 自动完成认证最省事且密钥不落配置多用户/远程管理场景为每个运维人员分别生成rpcauth条目密码各自保管可单独吊销。这两种机制可同时生效——服务端的RPCAuthorized会先尝试 cookie/单用户凭据再落入rpcauth多用户分支。测试验证multi_rpc.py 如何覆盖多用户认证仓库内置的 RPC 测试 qa/rpc-tests/multi_rpc.py 是对rpcauth行为的直接验证。该测试在setup_chain阶段向zcash.conf追加两条rpcauth用户rt与rt2每条均含 32 位十六进制盐与 64 位十六进制哈希例如rpcauthrt:93648e835a54c573682c2eb19f882535$7681e9c5b74bdd85e78166031d2058e1069b3ed7ed967c93fc63abba06f31144随后用http.client构造 HTTP 请求断言用rt 正确密码调用getbestblockhash返回非 401认证通过错误用户名rtwrongrt的密码返回 401正确用户名 篡改过的密码返回 401第二个用户rt2用其独立密码同样认证通过。这组用例覆盖了多用户并存、用户名校验、密码校验三个关键分支可直接作为理解rpcauth语义的活文档也可作为回归测试在修改认证逻辑后运行。安全实践要点盐的价值每个用户的 salt 由os.urandom()生成且互不相同即使两个用户密码相同配置中的哈希也不相同同时避免了彩虹表攻击密码熵32 字节随机密码约 256 bit 熵配合 250ms 失败延时离线字典与在线爆破的可行性都极低哈希不可逆配置文件泄露不等于密码泄露但持有哈希的攻击者仍可对该用户发起在线认证尝试因此配置文件权限仍需收紧吊销用户多用户模式下从zcash.conf删除对应rpcauth行并重启节点即可完成单个用户的凭据吊销不影响其他用户传输加密Basic Auth 中密码仅做 Base64 编码而非加密跨网络调用务必叠加 TLS如rpcbind结合反向代理或 SSH 隧道避免凭据在链路上被截获。小结rpcauth是 Zcash RPC 认证体系中多用户 不落盘明文的关键组件而 share/rpcuser/rpcuser.py 则是官方提供的配套生成器。理解其输出格式用户名:盐$哈希、服务端multiUserAuthorized的 HMAC 重算校验src/httprpc.cpp以及 qa/rpc-tests/multi_rpc.py 的测试语义即可在本地节点、多运维协作乃至自动化监控场景中安全地配置与管理 Zcash 节点的 JSON-RPC 访问凭据。【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Zcash RPC 认证与 rpcauth 凭据生成：基于 rpcuser.py 构建多用户安全登录
Zcash RPC 认证与 rpcauth 凭据生成基于 rpcuser.py 构建多用户安全登录【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcashZcash 节点的 JSON-RPC 接口默认需要认证后才能调用rpcauth是官方推荐的凭据方案它允许为每个登录用户单独生成用户名 盐 HMAC-SHA256 哈希三元组明文密码只出现在生成瞬间配置文件中永不落盘。本文以 share/rpcuser/README.md 与配套工具 share/rpcuser/rpcuser.py 为主线讲解凭据生成、zcash.conf配置、服务端校验原理与多用户管理读完即可为本地或远程 Zcash 节点配置一套可审计、可撤销的多用户 RPC 登录体系。RPC 认证背景为什么需要 rpcauthZcash 的 JSON-RPC 服务由 src/httprpc.cpp 实现通过 HTTP Basic Authentication 校验调用者身份。历史上节点只支持在配置文件中同时声明rpcuser与rpcpassword这对单用户凭据但从 src/httprpc.cpp 的InitRPCAuthentication()可以看出这套方案正被逐步淘汰未设置rpcpassword时节点会调用GenerateAuthCookie生成随机认证 cookie见 src/rpc/protocol.cpp并把__cookie__:base64写入数据目录下的.cookie文件客户端据此自动登录仍在使用rpcuser/rpcpassword时节点会打印弃用警告并明确提示请参见 share/rpcuser 获取 rpcauth 认证的生成方式rpcauth则是替代二者的多用户方案-rpcauthuserpw格式为USERNAME:SALT$HASH且该选项可以重复指定多次见 src/init.cpp 的参数帮助文本。因此rpcauth的定位是在配置文件中只保存不可逆的哈希值而不是明文口令。即使配置文件泄露攻击者也无法直接得到可用密码。rpcuser.py官方凭据生成工具share/rpcuser/README.md 对该工具的描述只有两行——Create an RPC user login credential创建 RPC 用户登录凭据用法为./rpcuser.py username但背后的实现细节相当值得展开。通读 share/rpcuser/rpcuser.py 的完整源码其工作流程可分为四步随机盐借助SystemRandom底层即os.urandom()生成 16 字节随机序列再格式化为 32 位十六进制字符串作为 salt随机密码用os.urandom(32)生成 32 字节随机数据经base64.urlsafe_b64encode编码得到密码因此密码是 43 个字符左右的 URL 安全 Base64 串具备约 256 bit 熵HMAC-SHA256 摘要以 salt 为密钥、以密码为消息计算hmac.new(salt, password, sha256)的十六进制摘要脚本兼容 Python 2 与 Python 3Python 3 下会切换为SHA256字符串形式的 digestmod 参数输出打印追加到zcash.conf的完整行以及一次性明文密码。实际输出形如String to be appended to zcash.conf: rpcauthalice:9f2d3e1a7b4c5d6e0f1a2b3c4d5e6f7a$8a9b... Your password: kX3vQpLmWnRzTuYwZbAcDeFgHiJkLmNoPqRsTuVwXyZ其中rpcauth之后依次是用户名、十六进制盐、$分隔符和 64 位十六进制 HMAC 摘要。明文密码只在终端里出现一次请立即安全保存之后无论重启节点还是重新生成配置都无法再从哈希反推出它。实战生成凭据并配置 zcash.conf单用户配置在仓库根目录下直接执行脚本即可脚本 shebang 声明为 Python 2但兼容 Python 3也可显式用python3调用python3 share/rpcuser/rpcuser.py alice将输出的rpcauthalice:...一行追加到节点的zcash.conf配置文件例如# zcash.conf server1 rpcbind127.0.0.1 rpcauthalice:9f2d3e1a7b4c5d6e0f1a2b3c4d5e6f7a$8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8随后启动zcashd。客户端调用时使用生成时打印的明文密码构造 Basic Auth 头curl --user alice:kX3vQpLmWnRzTuYwZbAcDeFgHiJkLmNoPqRsTuVwXyZ \ --data-binary {jsonrpc:1.0,id:curltest,method:getblockchaininfo,params:[]} \ -H content-type: text/plain; \ http://127.0.0.1:8232/多用户配置由于-rpcauth选项可以指定多次多个用户只需在配置文件中并列多行rpcauthalice:9f2d3e1a7b4c5d6e0f1a2b3c4d5e6f7a$8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8 rpcauthbob:c4f7a91e2b3d5e6f0a1b2c3d4e5f6a7b$1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f这样alice与bob各自持有独立密码可分别发放与吊销无需为每个用户重启节点时重写全局凭据。服务端校验原理从 HTTP 头到 HMAC 重算rpcauth的校验逻辑集中在 src/httprpc.cpp调用链清晰可循HTTPReq_JSONRPC只接受 POST 请求src/httprpc.cpp随后读取authorization请求头缺失或校验失败时返回401并附带WWW-Authenticate响应头RPCAuthorized解析 Basic Auth 头要求前缀为Basic对剩余部分做 Base64 解码还原出用户名:密码先与单用户凭据strRPCUserColonPass即rpcuser:rpcpassword做TimingResistantEqual常量时间比较不匹配则进入multiUserAuthorized遍历配置中所有-rpcauth条目src/httprpc.cpp按:与$分割为用户名、盐、哈希三个字段字段数不为 3 视为格式错误并跳过用TimingResistantEqual比较用户名用CHMAC_SHA256(salt, password)重新计算摘要对应 src/crypto/hmac_sha256.h 的 HMAC-SHA256 实现再与配置中的哈希做常量时间比较任一用户匹配即放行。值得注意的是C 端重算 HMAC 的方式与rpcuser.py完全对称脚本以 salt 为密钥、密码为消息生成摘要服务端同样以 salt 作为密钥写入CHMAC_SHA256构造函数以明文密码作为消息写入Write()。这种只存哈希、验证时重算的设计保证了配置文件里永远没有明文口令。同时该路径还内置了针对暴力破解的缓解手段src/httprpc.cpp认证失败时先记录一条ThreadRPCServer incorrect password attempt from IP日志再MilliSleep(250)强制停顿 250 毫秒后才返回 401从源码注释看这是为了阻止暴力破解如果这导致 DoS说明用户本就不该暴露 RPC 端口。客户端的认证回退cookie 与 rpcauth 的配合值得补充的是rpcauth与 cookie 认证并非互斥。在 src/bitcoin-cli.cpp 中zcash-cli的逻辑是若配置了rpcpassword则使用rpcuser:rpcpassword否则回退到读取节点数据目录下的.cookie文件完成认证对应服务端的GenerateAuthCookie/GetAuthCookie见 src/rpc/protocol.cpp。因此存在两种典型组合本机自动化场景节点不配置任何rpcuser/rpcpassword由随机 cookie 自动完成认证最省事且密钥不落配置多用户/远程管理场景为每个运维人员分别生成rpcauth条目密码各自保管可单独吊销。这两种机制可同时生效——服务端的RPCAuthorized会先尝试 cookie/单用户凭据再落入rpcauth多用户分支。测试验证multi_rpc.py 如何覆盖多用户认证仓库内置的 RPC 测试 qa/rpc-tests/multi_rpc.py 是对rpcauth行为的直接验证。该测试在setup_chain阶段向zcash.conf追加两条rpcauth用户rt与rt2每条均含 32 位十六进制盐与 64 位十六进制哈希例如rpcauthrt:93648e835a54c573682c2eb19f882535$7681e9c5b74bdd85e78166031d2058e1069b3ed7ed967c93fc63abba06f31144随后用http.client构造 HTTP 请求断言用rt 正确密码调用getbestblockhash返回非 401认证通过错误用户名rtwrongrt的密码返回 401正确用户名 篡改过的密码返回 401第二个用户rt2用其独立密码同样认证通过。这组用例覆盖了多用户并存、用户名校验、密码校验三个关键分支可直接作为理解rpcauth语义的活文档也可作为回归测试在修改认证逻辑后运行。安全实践要点盐的价值每个用户的 salt 由os.urandom()生成且互不相同即使两个用户密码相同配置中的哈希也不相同同时避免了彩虹表攻击密码熵32 字节随机密码约 256 bit 熵配合 250ms 失败延时离线字典与在线爆破的可行性都极低哈希不可逆配置文件泄露不等于密码泄露但持有哈希的攻击者仍可对该用户发起在线认证尝试因此配置文件权限仍需收紧吊销用户多用户模式下从zcash.conf删除对应rpcauth行并重启节点即可完成单个用户的凭据吊销不影响其他用户传输加密Basic Auth 中密码仅做 Base64 编码而非加密跨网络调用务必叠加 TLS如rpcbind结合反向代理或 SSH 隧道避免凭据在链路上被截获。小结rpcauth是 Zcash RPC 认证体系中多用户 不落盘明文的关键组件而 share/rpcuser/rpcuser.py 则是官方提供的配套生成器。理解其输出格式用户名:盐$哈希、服务端multiUserAuthorized的 HMAC 重算校验src/httprpc.cpp以及 qa/rpc-tests/multi_rpc.py 的测试语义即可在本地节点、多运维协作乃至自动化监控场景中安全地配置与管理 Zcash 节点的 JSON-RPC 访问凭据。【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考