未分類
15 11 月 2020

日常用到的 ak 和 sk 的正确使用方式是什么？

日常用到的 ak 和 sk 的正确使用方式是什么？

資深大佬 : dandankele 11

最近在开发一个系统，需要提供 openAPI 给外部系统使用，那么 API 肯定需要设计一些认证、鉴权的流程。根据以往使用的一些公有云 API 以及微信 API 等来看，大多数平台都会给使用者提供 ak 和 sk 来调用 API 。

这里的 ak/sk 可能有的也会设计为 appId/appSecret 之类的，像阿里云的是 accessKeyId 和 accessKeySecret 。

我目前的看到和理解的有这么几种：

  1. 不传输 secret，调用 API 时，只传递 ak 和必要的数据。像阿里云 API，sk 是用作对称加密并进行消息签名，但我比较好奇的是，都说非对称加密安全性要高一些，为啥阿里云却选择了对称加密？

  2. 传输 secret，像 OAuth2 授权，在去获取 code 时，ak 和 sk 都要传递过去，那传递过程中不怕被截获吗？

所以疑问是：sk 的作用到底是什么？是仅仅像帐号密码中的“密码”一样，在调用 API 时传递过去进行认证？还是用于对传输的数据进行消息签名，以便服务端判断是否有数据篡改？或者还有其他作用？

大佬有話說 (8)

  • 資深大佬 : boris93

    传输期间用 HTTPS 就不怕被截获了吧

  • 資深大佬 : boris93

    ak 和 sk 可以作为一个密钥对用来认证
    比如一种常见做法就是 ak + : + sk，然后把字符串 Base64，然后拿去做 HTTP Basic 认证

    签名我理解更偏向于防止伪造和重放请求，签名里的 sk 作为密钥别人不知道也不应该知道，签名里的时间戳则保证了请求的时效性

  • 資深大佬 : guyskk0x0

    个人看法：
    和系统安全等级有关，一般用 hmac 对消息签名可以达到鉴权+防篡改，消息内带时间戳可以校验有效期，整个流程不需要传输秘钥。公网流量套上 HTTPS 。

    安全性要求很高，可以做端到端 HTTPS 双向认证，也就是非对称加密。

  • 資深大佬 : sunsulei

    有的 sk 二次获取的时候是需要检验密码的。
    如果接口也传了个 sk，可能是为了进一步保证安全吧(如果 ak 泄漏的话)。

  • 資深大佬 : mrchi

    不传输 secret，调用 API 时，只传递 ak 和必要的数据。像阿里云 API，sk 是用作对称加密并进行消息签名，但我比较好奇的是，都说非对称加密安全性要高一些，为啥阿里云却选择了对称加密？
    —
    没用过阿里云的 API，通常用 ak 和 sk 做验证的 API，是只传 ak，用 sk 给消息体算签名（哈希算法），这样如果有中间人截获消息，没有 sk 没法算出正确的签名（哈希值），同时在消息体中包含时间戳防止重放攻击。

    传输 secret，像 OAuth2 授权，在去获取 code 时，ak 和 sk 都要传递过去，那传递过程中不怕被截获吗？
    —
    如果中间人能够截获请求和响应，不管在不在请求里传 sk，只要拿到响应里的 access_token 就万事大吉了。就有了用户身份。

    我的理解是，前者的响应是资源，保护的是用户身份。后者的响应就是用户身份，所以传不传的无所谓。

  • 資深大佬 : eason1874

    ak 相当于账号，可以公开，一般直接透传； sk 相当于密码，要严格保密，一般只作为计算签名的参数。

    个别场景可能允许 sk 透传，但这个场景一定是发生在服务端，比如 OAuth2 获取 Access Token 就透传 sk 。你说的获取 Authorization Code 环节发生在客户端，那时不传 sk 只传 ak 。

    非对称加密效率低，主要用途是在不可信的网络环境中建立双方可信的通信来传递密钥，传递密钥之后一般还是用回对称加密来传递信息的，比如 HTTPS 就是这样。

    开发者跟开放平台之间用不着在不可信的环境中传递密钥，所以直接用对称加密就行了。

  • 資深大佬 : nieyujiang

    阿里云的 sk 可以拿来计算签名的，只要有 ak 和签名就行了

  • 資深大佬 : xuanbg

    ak 是 key，sk 其实是 value 。调用者用 sk 加密数据，并把 ak 一起传过去。服务端用 ak 查询对应的 sk 解密数据。就是这样