针对密码泄漏事件,都有哪些相对安全的密码加密规则?

发布于 2022-08-24 00:29:08 字数 396 浏览 16 评论 0

对于 CSDN 明文存储密码并测漏一事,我实在无力吐槽。

传统的直接md5(password)弱爆了,密码字典一下子就查出来了。所以,希望大家能给我提供一些值得在今后开发中使用的密码加密规则。

我常用的方法是用户提交时,先用 JavaScript MD5 将密码在本地加密,提交到服务端,服务端取用户表中某个字段(比如注册时间)再加密一次md5(datetime+md5(password)),存储二次加密后的密码,自认为这样相对安全,但还是觉得有些许不妥,希望能指出。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(15

べ映画 2022-08-31 00:29:08

其实关于安全问题的讨论或者防御方法很多手册都写得非常好,真不知道现在的程序员有没有好好看过这些文字。

比如说php,已在md5的手册上给出了以下连接:http://cn2.php.net/manual/en/faq.pass...

我大概翻译一下要点:
1. md5, sha1, sha256都不适合用来做密码的加密,以上函数都是为了快速有效的验证而设计(我想是指验证文件等运用),所以使用现代的计算机技术,是完全有可能实现暴力破解的

2. 加密password最好是使用更复杂算法的方法比如crypt,并且使用“加盐值(salt)”,楼主所说的方法就是一种加盐法,也就是将原密码通过一些有规律的变化再加密。

3. 第三点解释什么是salt,上面已经解释了,使用了salt以后就算暴力破解了也不见得能立马能看出原密码来,必须知道变化的规律才行

后来我有注意到楼主在客户端用md5加过一次密,我的第一感觉是没什么用,因为客户端的js代码谁都看得见,知道加密的规则,所以这么做如果是防截取的话,感觉用处不是特别大,而且我直接使用截取到的加密后的密码直接传输到服务器端,服务器也看不出什么差别来。

对于传输层来说,还是老老实实用https靠谱点儿

醉南桥 2022-08-31 00:29:08

首先用明文保存用户密码非常不道德,而且做法很业余,万一被攻破用户要改的地方就多了。

应该说纯粹的md5哈希也已经非常不安全了,现在黑客们从各个站暴库而流传的地下猜解字典已经非常大了。所以国内对用户密码的处理普遍还处在一个非常初级的阶段,你只能寄希望于黑客别找上你。

现在国外比较流行的对密码的处理方法主要是在md5的基础上,加上一个随机的扰码(salt),这样你的密码哈希后的值也是随机的了,即便被别人拿到这个值,也无法还原出你真实的密码。在php上有很著名的phpass库(http://www.openwall.com/phpass/),目前wordpress就是使用的这种方法。

对纯哈希的研究,除了使用位数更大的hash以外(现在sha算法已经可以做到512位),还可以使用blowfish这种使用密码算子的算法。我记得看过一片文章介绍这种算法,因为它使用算子做计算,你可以根据自己服务器的运算速度,选择一个合适的算子组合,这样你可以控制它的运算时间,比如说在我的服务器上我需要0.5秒才能hash出结果,那如果别人拿这个hash值去做碰撞实验,基本上是不可能的结果,即便是用超级计算机也很慢了。不过这种算法的缺点就是太耗cpu了,一般网站没什么必要。

鼻尖触碰 2022-08-31 00:29:08

没有攻不破的盾, 再好的加密措施, 只是多加了几道门, 再者设计复杂的方法的话, 用户体验又不好.

让用户输入一个超强的密码 ( 如:必须带数字大小写字母加上特殊符号,并且不允许出现字典里面找得到的单词, 密码位数在 15 位以上 ), 最后只会导致, 用户找个地方把密码记录下来, 如记在小字条上然后放到钱包里面!

但是, 直接明文储存, 也太不负责任了, 挺愚蠢的做法!

简单但有效的加密措施为:
salt = 随机; // 加多些干扰因素
password = md5( md5(明文密码) + salt );

数据库存的是 password 和 salt ! 且每一次登录的时候重新更新 salt 和 password ;

旧街凉风 2022-08-31 00:29:08

此文应该能给你一些答案。 http://coolshell.cn/articles/2078.htm...

爱情眠于流年 2022-08-31 00:29:08

我的感觉这样已经够了:其实MD5算法本身已经够牛逼了,但是因为大家的密码都是一些常用的密码,所以就有了密码字典。现在你再加一个salt, 破解密码的难度又加大了。他需要做下面的事情:

1. 猜你的salt是哪个字段
2. 猜到你的salt是哪个字段之后,需要知道对应的字段的值(你这里的注册时间)
3. 即使知道这些也没办法用密码字典来查了。
4. 即使他知道了密码的最后加密值,那么也需要用下面的公式一个个来试了

MD5(salt + 所有可能的常用密码) =? 加密后的密码值

我感觉一般来说这种加密方式应该够了。

绿光 2022-08-31 00:29:08

MD5,sha都不是加密的手段,就算是加salt也好,我们应该使用bcrypt加密密码,请参考http://codahale.com/how-to-safely-sto...
上面有详细说明原因。

错爱 2022-08-31 00:29:08

其实对单个账号加随机salt已经可以了,至少拿到暴库无法批量得到所有用户密码。注意是针对单个账号的随机salt,单一salt一旦泄露也就无意义了。

虽然即使这样针对单个用户的破解仍然是可行的,但是对整个库的破解就成本太高了。

旧伤还要旧人安 2022-08-31 00:29:08
import hashlib
print hashlib.md5('user_password'+hashlib.md5('salt').hexdigest()).hexdigest()

破吧。

输什么也不输骨气 2022-08-31 00:29:08

我有个方法不知道可不可行!!!
先用 JavaScript MD5 将密码(为了提高安全也可以 “密码+用户名”)在本地加密,
然后通过JavaScript截取中间的20位提交到服务端,就算别人半路截取了,也只有其中的20位,
想推断出原始密码还是蛮有难度的!!!

其次就要判断这些数据是来自页面传递还是来自工具传递!!尽可能的增加安全性!!

少女净妖师 2022-08-31 00:29:08

单纯从密码学角度来讲。
MD5完全可以。
MD5的被攻破只不过是可以算出原值区间。
而且已有的MD5比较表无非就是算出一些常用值罢了。
非常用还无法破解。
SHA1就更安全些。
而且明文存储用户密码就是对用户的不负责。
将密码HASH之后。
可以保证网站无需记录用户密码。
即使密码库泄露。
也无法还原出用户密码。
还原出只是那些常用密码。
woaiXXX那种密码都是很难还原出来的。
而且就算知道HASH值。
依然无用。
以上仅从密码学观点出发。

神回复 2022-08-31 00:29:08

这次泄密事件首先反映的是应用程序或者说加密数据储存方由于这样那样的“理由”,安全保护不利所暴露的问题。明文保存显然是可悲而且可怕的措施,选取合适的非对称加密方式并储存加密结果仅用于比对是必须的。现在网上的md5暴库数据样本其实已经不小了,所以一般尽可能要对原始密码做变换后在做hash。
考虑到服务器性能问题,连续多次hash并不十分推荐(实际上按现有的暴库能力,两次合理的hash已经能非常有效地提升保密性能了)。
而hash之前使用基于用户的单一salt(比如用户名或者注册时间戳或者前面
Charlie Jade 提到的每次登陆更新的随机salt)对明文密码进行加盐混淆是相当有效的。
为减低冲撞,用特定字符串补齐长度至比如32位后再进行hash也是不错的主意。

少女的英雄梦 2022-08-31 00:29:08

两个方面的问题怎么加密?怎么存储?加密简单,肯定可以弄个不容易破解的,但是还要想想到时候用户登录的时候怎么验证的问题既怎么存储!

贵在坚持 2022-08-31 00:29:08

前端js加随机 salt进行MD5后传输,外加https(条件允许和根据实际场景),后端存储的时候再次加上随机salt后md5,基本能满足需求了。

笔落惊风雨 2022-08-31 00:29:08

月光博客也有一个方案:http://www.williamlong.info/archives/3224.html

倾城泪 2022-08-31 00:29:08

A=(ID+MD5(pwd)+mac+rand)
B=rsa(A)
C=ID+B+A(ID+MD5(pwd))

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文