云存储中的HTTP鉴权算法分析

新浪微博 QQ空间

基于Base64编码的HTTP Basic Authentication由于安全问题,已经不再广泛使用了。在云存储中,数据的安全性一直被广泛关注。亚马逊的AWS S3和Openstack Swift分别采取了不同的算法来对每一个HTTP请求进行鉴权。这里想对二者的鉴权过程作简单分析和总结。

一、AWS S3的HTTP请求鉴权流程

AWS采取的鉴权算法类似于HTTP基本认证。我们知道Base64只是对字符串进行了一个转换存储,是可以反向解析出源字符串的,因此基本认证中使用Base64编码处理过的用户名和密码可以被截获,一旦用户名和密码泄漏,黑客可以构造任何需要的请求进行数据窃取和改写。AWS采用的是签名认证的思想来解决这一问题,详细的过程参见:链接

signing-overview

基本原理:

1、客户端将请求中的通用信息(如:Bucket Name、Object Name、请求时间和请求方法名等)和SecretAccessKey(下文简称SK)进行SHA256哈希计算得到一个字符串;
2、最终在HTTP请求中传输的是该HASH值。其中AccessKey(下文简称AK)在请求中明文传输;
3、服务端拿到该请求后,首先提取出AK,然后根据AK到服务端的数据库中查询出开户时分配给该用户的SK;
4、服务端从请求中提取通用信息,配合查询得到的SK,使用同样签名计算过程计算一个签名,然后与请求中携带的签名进行比对,二者一致则认为该请求是合法请求,鉴权通过。否则返回403鉴权失败。

如果整个HTTP请求被截获,黑客虽然能得到该鉴权值,但是无法反解析出用户的SK,因为SHA是不可逆的哈希算法。因此最坏的情况:可以重复发送该请求(不修改请求中任一参数)到服务端,攻击范围有限。假设,黑客想使用该鉴权值伪造新的请求,那么修改请求中的通用信息,而签名值没有改变,最终鉴权也无法通过。

那么是不是黑客可以一直使用该鉴权发送该请求呢?也不是的,AWS S3拿到请求后会比对服务端的时间与请求中的时间的差值,如果该请求的发出时间比服务端的时间早15分钟,则认为该请求为非法请求。

从上面的过程来看,AWS的鉴权算法非常好的解决了密钥泄漏和每一个请求都能得到鉴权的问题。

二、再来看基于Keystone的Openstack Swift的HTTP请求鉴权流程

Keystone的原理比较简单,整个系统提供全局唯一的Keystone服务,客户端在发送HTTP请求之前,首先需要向Keystone申请一个Token(定长的字符串),该Token的有效期由Keystone服务端来指定。申请Token时,需要向Keystone提供用户名和密码,这里可以理解成AWS中的AK和SK,Keystone认证通过该用户之后,发放Token给客户端。之后客户端每次发送HTTP请求时都必须携带该Token,Swift拿到该Token和用户名信息后,也会像Keystone查询该Token是否有效。Token有效,则继续处理该业务,Token无效,则返回鉴权失败。具体的流程可以从如下序列图看出:

Openstack Swift与Keystone实现请求鉴权流程

这样的鉴权过程存在一些问题:

1、相比于AWS的鉴权,这里如果Token泄漏,会造成比较严重的后果,虽然Token有有效期,但是每次都需用用户名和密码去申请,频繁申请也有可能会造成密钥的泄漏;
2、每一次请求都需要Swift与Keystone之间作一次交互,性能可能存在问题。

事实上,Openstack就发生过多次Token永久有效的bug,导致数据被破坏。当然这样的架构也有其优点,Keystone可以在多个服务间共享,将鉴权逻辑集中管理,做到了服务级的重用,而AWS必须在每一个服务中解析和生成签名,只能做到模块或者代码级别的重用。

新浪微博 QQ空间

| 1 分2 分3 分4 分5 分 (5.00- 9票) Loading ... Loading ... | 这篇文章归档在:Amazon S3, Swift, 云计算/云存储, 存储技术, 算法数据结构 | 标签: , , , , , , , . | 永久链接:链接 | 评论(9) |

9 条评论

  1. gz_zhanghao
    评论于 八月 17, 2015 at 15:02:03 CST | 评论链接

    keystone里的token要拿账户密码去换。。。账户密码在传输过程中被黑客抓了不就完了?

  2. 匿名
    评论于 九月 5, 2014 at 17:00:18 CST | 评论链接

    带过去的username和token要是被人截获了,那不是在一段时间内都可以被他人使用。http带这两个值过去的时候有做什么保护措施吗?

    • 匿名
      评论于 九月 5, 2014 at 18:40:18 CST | 评论链接

      https咯?

      • 匿名
        评论于 十月 14, 2014 at 22:58:15 CST | 评论链接

        如果全程https,只需要每个用户给块令牌也能做吧。
        aws这里有2点不明白:
        1.通用信息是否包含普通接口请求参数
        2.既然sha不可逆,那么如何在第四步提取出通用信息

        • 童燕群
          评论于 十月 15, 2014 at 07:26:10 CST | 评论链接

          签名的基本原理是额外加一条头域,该头域是提取普通参数后sha哈希得到的。签名不是加密,可以查看本站另外一篇介绍这几个概念的文章。

          HTTPS只保证传输,用户名和密码还是有泄漏的可能。所以token有失效机制。

        • 匿名
          评论于 三月 22, 2017 at 15:45:07 CST | 评论链接
  3. 匿名
    评论于 九月 5, 2014 at 16:58:49 CST | 评论链接

    童总,搜索到你的文章了

    • 匿名
      评论于 九月 5, 2014 at 18:38:25 CST | 评论链接

      呃,看来小站知名度还不错啊 :)

  4. 评论于 二月 8, 2014 at 12:28:12 CST | 评论链接

    各个组件做什么都要和Keystone交互,性能压力很大。
    记得以前看过一篇评论就说他们做大规模部署,性能瓶颈就在Keystone上。

评论

邮箱地址不会被泄露, 标记为 * 的项目必填。

8 - 2 = *



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <img alt="" src="" class=""> <pre class=""> <q cite=""> <s> <strike> <strong>

返回顶部