一个可实践的「Hash加盐」技术方案

举报
feichaiyu 发表于 2019/10/15 08:42:25 2019/10/15
【摘要】 在《如何安全存储口令?了解下Hash加盐的原理》这篇文章中,从原理、用途、特点等方面讲解了安全存储口令的一种方案,这就是Hash加盐,为了更好的理解,这篇文章从实战的角度,设计一个可实践的技术方案。以企业邮箱应用来说,企业用户(每个用户有一个 email 地址)、企业管理员、客服人员、销售人员都有一个登录口令;这些用户可以通过 IMAP、POP、SMTP、WEB(包括 webmail、客服管...

在《如何安全存储口令?了解下Hash加盐的原理》这篇文章中,从原理、用途、特点等方面讲解了安全存储口令的一种方案,这就是Hash加盐,为了更好的理解,这篇文章从实战的角度,设计一个可实践的技术方案。

以企业邮箱应用来说,企业用户(每个用户有一个 email 地址)、企业管理员、客服人员、销售人员都有一个登录口令;这些用户可以通过 IMAP、POP、SMTP、WEB(包括 webmail、客服管理平台、销售管理平台、企业管理平台)登录校验口令。

Hash加盐虽然不是口令保护最好的技术手段,但如果实施得当,也是比较安全的,除了Hash加盐算法,基本的解决方案是:

  • 存储分离

  • 授权分层

要达到的最终目的:即使口令系统的某个部分,或者全部被攻击了,攻击者也很难反解出明文口令。

那么如何设计呢?先上一张图,然后基于这张图细细道来。

2.1.png

1:首先口令存储(库)和Salt存储(库)是物理分割的,也就是说不能是同一个库,不同的库也不能在一台物理机器上,为什么要这么做呢?比如口令库被脱库了,但Salt库没有泄漏,那么也很难破解出口令明文。

同时不同角色的口令(比如用户口令、企业管理员口令...)最好也是物理分离的;但这些角色的Salt可以在一个库中,毕竟把系统搞的太复杂也比较难维护。

必须注意的是口令、Salt库一定不能和其他库混在一起,从DBA的角度看,口令、Salt库安全级别显然更高,尤其加上主辅同步,这些库存储的地方设备越少越好,减少泄漏的风险。

2:那么Salt如何设计呢?

几个原则:

  • 不可预测,不可重复,每个口令的Salt独立。

  • Salt 的长度尽量和 Hash 算法的长度一致。

关于如何得到 Salt,后面的伪代码会说明。

3:Salt 加密

Salt看上去好像是加密的,但必须指出的是,Hash运算不是加密算法,Salt值仍然是明文的。那么将Salt值加密后再存储的时候,是否更安全呢?

为了加密Salt,不管是对称加密算法,还是非对称加密算法,都需要密钥(称为 Salt 密钥),这个密钥的存储是非常重要的,如果泄漏了,加密基本上也是无用的。

对Salt加密还可以使用 HMAC 算法,即在 Hash 的时候,同时对Salt和Salt 密钥进行 Hash 运算。

看上去这二种Salt加密算法都能满足需求(也同样面临Salt 密钥的管理问题),那么应该采用哪一种呢?

建议采用加密算法保护Salt,因为可以定时修改Salt密钥,当然在修改的时候,必须重新计算Salt的加密值,并更新到存储中(比如 Mysql)。

而如果采用 HMAC 算法,因为它无法反解出明文的Salt值,自然无法重置Salt加密值。

如果担心 Salt 密钥因为泄漏而存在安全风险,可以定时修改Salt密钥。

4:以邮箱应用来说,应用层服务很多,开发语言也很多,如果每个服务都独自校验口令,那么风险显然很大,而且从历史经验来看,口令泄漏的风险都来源于此。

那么由统一的 API 层注册、校验口令显然非常重要,从安全、可扩展的角度看,统一的 API 封装非常重要,从运维、开发的角度看,API 的管理也很重要:

  • 比如放在单独的集群中,开发者不能有权限登录。

  • 口令和Salt的库只能授权给 API 集群,比如通过 Mysql 的IP 限制。

  • 或者 API 只能提供内网服务。

一切的一切,都是为了隔离。

在 API 层上,如果 Salt 是加密的,为了注册、校验口令,必须能够访问Salt密钥,千万不能在代码中硬编码Salt密钥,如果没有专门的硬件保护Salt密钥,那么本质上只要API机器被攻破,这个Salt密钥也就相当于明文了。为了减轻风险,可以定时修改salt密钥。

5:接下来,WEB、SMTP 访问必须具备授权机制,比如 SMTP 服务显然不能访问企业管理员的口令,通过可分配权限的机制限制应用层对 API 的访问。

这样的好处除了权限控制,假想下,如果 WEB 层的服务器被攻击了,它也很难攻击 API 集群,至少很难攻破 API 集群服务器,当然它可以通过模拟的手段,从 WEB 层发起攻击。

至于 WEB、SMTP 如何与 API 通信,如何更安全,有很多技术解决方案,比如 HTTPS,或者动态的 token,但如果应用层机器被暴力攻破了,这些防护手段也是没用的。

从上面的描述,可以看出,这是基本的三层应用架构,其实技术之间都是互通的,接下去简单用伪代码描述下如何注册、校验口令。

注册口令:

屏幕快照 2019-10-15 上午8.36.42.png

校验口令:

屏幕快照 2019-10-15 上午8.36.53.png


欢迎关注我的书《深入浅出HTTPS:从原理到实战》,如果觉得写的还可以,欢迎在豆 瓣做个评论




本文转载自异步社区。

文链接:https://www.epubit.com/articleDetails?id=Ne2bc959e-e273-42b5-80d4-173f8b50aadc

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。