谈谈系统密码存储策略

最近IT界很火的一则新闻是华住的数据库泄露问题,身边很多人在讨论数据库安全的问题,大家经常说提升密码复杂度、加密等,但是很多人并不知道在开发的时候,用户的密码怎么处理,或者说,处理的并不恰当,这篇文章主要介绍在系统设计的过程中,我们的密码究竟应该怎么处理才最大限度的保证安全。

密码加密的重要性?

还是从脱库说起,数据库被人拉走了,最可怕的是什么?个人手机、身份证、地址??这些是很重要,但是,其实个人隐私数据,获取的难度不是很大,而且不容易直接对一个人造成巨大的伤害,但是,密码被人知道了,就是很可怕的事情。因为,大部分人不同的系统都是共用密码。这个错误比较低级,但是很常见,所以,密码,是被脱库后最容易被人利用。所以,密码是必须加密的,不把用户密码加密的系统和公司,都该判刑。

密码管理的入门要求

密码管理产品级别的需求,大家都能看到的是,提升密码的复杂度和管理策略,一般包括:

  • 密码加密保存,并且是不可逆的。
  • 密码更长更复杂。如:密码长度大于8位,必须是大小写字母和数字的组合。
  • 定期修改密码策略。
  • 登录输入密码错误多次,需要输入验证码,甚至是锁定账户。
    以上都是一些基础,但是非常有效的方案,这些产品设计不是我们讨论的重点,我们重点说说具体的实现。
    在技术上,�实际密码我们是怎么存储的呢?
String password=MD5("明文")

对用户的输入进行MD5加密后,就直接保存在数据库,可能15年前这还是比较安全的存储方式,但是现在,MD5已经不再安全,越是简单的密码,被撞库获取到原文的可能性非常的高,所以直接使用MD5加密后保存密码,显然已经是非常不安全的方式了。

密码+salt

前文说道,密码太短,显然已经不安全了,那么为了提升负责度,就会强制把用户的密码变得更加复杂,于是,就产生了密码加salt的方案。salt肯定是需要一个比较的复杂的字符串,长度可以长一点。而且最好是,每个用户的salt是不一样的。以前的数据库结构是:

ID 用户名 密码
1 user1 34234sdfse2342dggs234s
2 user2 d34desf3432sdf23423sdf

那么比较安全的方式应该是:

ID 用户名 密码 salt
1 user1 sdf452342sdfsd23234sdf 982934&7934708hHG12&%&()()()IUHUHGggifiknsdf
2 user2 234df3234sdf234asfddsd &&8uhhhkKHKl9(7KBKH&……)adksjknklasdlfkjkkkkk
String password=SHA1("明文"+salt);

这里,我们用了相对而言撞库难度比较大的SHA1的加密方式来取代MD5加密,这样基本就是一个比较安全的密码了,即使数据被脱库了,撞库也很基本不可能破解出明文。

但是,这样就真的安全了吗?不一定,我们还少了传输加密以及客户端加密。

客户端和传输加密

首先我们说说传输加密,其实,这个现在已经有很标准的解决方案——https,这里我们就不多说了。
我们主要所属说说客户端加密:
可能大家觉得有了传输加密了,实际客户端加密也不太重要,显然不是,这里有个很重要的场景就容易出现风险:

  • 日志。大家的系统都会统一记录日志,针对密码这类敏感的信息,如果记录了日志,而且大家记录的都是用户输入的明文,这样非常危险。
  • 内网劫持。如果数据还没有到公网,在内网就被劫持了,有可能暴露明文的密码。

所以,客户端加密也是很有必要的。现在的前端技术都是支持MD5加密,所以我们就在前端对用户的数据进行了MD5加密。
客户端代码:

var password=md5("明文");
String password=SHA1("客户端MD5加密后的支付"+salt);

实际,这样最终存在数据库的,就是一个做了双重加密的支付。网络传输和日志记录的就是单次加密的字符,整体的安全度就非常高了。

总结

这样,一个好的密码体系应该就是这样了:

  • 客户端MD5针对用户输入的明文加密后提交到服务端。
  • 服务端根据用户生成一个复杂的随机salt。
  • 根据随机salt和接收到的密码,sha1加密,生成密码保存到数据库。

这是一篇非常基础的文章,但是却被很多的开发和产品忽略,风险总在一念之间。安全永远是一个相对的概念,我们只能提升破解安全的成本,无法做到绝对的安全。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,039评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,223评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,916评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,009评论 1 291
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,030评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,011评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,934评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,754评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,202评论 1 309
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,433评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,590评论 1 346
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,321评论 5 342
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,917评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,568评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,738评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,583评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,482评论 2 352