目前据说MD5部分不安全.考虑到这一点,我想知道用于密码保护的机制.
这个问题,"双重哈希"密码是否比仅仅哈希一次更安全? 建议多次散列可能是一个好主意,而如何实现单个文件的密码保护?建议使用盐.
我正在使用PHP.我想要一个安全快速的密码加密系统.散列密码一百万次可能更安全,但也更慢.如何在速度和安全性之间取得良好的平衡?另外,我更喜欢结果具有恒定数量的字符.
另外,我应该在数据库中存储两个字段(例如,一个使用MD5,另一个使用SHA)?它会使它更安全或更不安全吗?
如果我不够清楚,我想知道使用哪种散列函数以及如何选择好的盐以便拥有安全和快速的密码保护机制.
相关问题并不完全涵盖我的问题:
PHP中的SHA和MD5有什么区别
简单密码加密
存储密钥的安全方法,asp.net的密码
如何在Tomcat 5.5中实现salted密码
Coda Hale的文章"如何安全地存储密码"声称:
bcrypt内置了盐来防止彩虹表攻击.
他引用了这篇论文,其中说在OpenBSD的实现中bcrypt:
OpenBSD从arcfour(arc4random(3))密钥流生成128位bcrypt salt,并使用内核从设备时序收集的随机数据进行种子处理.
我不明白这是如何工作的.在我的盐概念中:
当我使用带有bcrypt的Devise(一个Rails登录管理器)时,数据库中没有salt列,所以我很困惑.如果盐是随机的并且没有存储在任何地方,我们如何可靠地重复散列过程?
简而言之,bcrypt如何内置盐?
我正在看哈希算法,但找不到答案.
谢谢..
更新:
我想澄清一点,我理解散列和加密之间的区别.是什么促使我这样问这个问题的是这篇文章,作者将bcrypt称为"自适应散列"
由于bcrypt基于Blowfish,因此我认为Blowfish是一种哈希算法.如果它的答案已经指出加密,那么在我看来它应该不会在本文中占有一席之地.更糟糕的是,他总结说bcrypt是最好的.现在让我感到困惑的是phpass类(我相信用于密码哈希)使用bcrypt(即河豚,即加密).根据这些新信息,你们告诉我(河豚是加密),这个类听起来不对.我错过了什么吗?
.NET框架附带了6种不同的散列算法:
每个功能都有不同的表现; MD5是最快的,RIPEMD是最慢的.
MD5的优势在于它适用于内置的Guid类型; 它是3型UUID的基础.SHA-1哈希是类型5 UUID的基础.这使得它们非常易于识别.
然而,MD5易受碰撞攻击,SHA-1也容易受到攻击,但程度较轻.
我真的很想回答的具体问题是:
MD5不值得信任吗?在正常情况下,当您使用没有恶意意图的MD5算法且没有任何第三方有任何恶意意图时,您会期望任何冲突(意味着两个任意byte []产生相同的哈希)
RIPEMD比SHA1好多少?(如果它更好)它的计算速度要慢5倍,但散列大小与SHA1相同.
散列文件名(或其他短字符串)时获得非恶意冲突的几率是多少?(例如,2个具有相同MD5哈希值的随机文件名)(使用MD5/SHA1/SHA2xx)一般来说,非恶意冲突的几率是多少?
这是我使用的基准:
static void TimeAction(string description, int iterations, Action func) {
var watch = new Stopwatch();
watch.Start();
for (int i = 0; i < iterations; i++) {
func();
}
watch.Stop();
Console.Write(description);
Console.WriteLine(" Time Elapsed {0} ms", watch.ElapsedMilliseconds);
}
static byte[] GetRandomBytes(int count) {
var bytes = new byte[count];
(new Random()).NextBytes(bytes);
return bytes;
}
static void …Run Code Online (Sandbox Code Playgroud) 在工作中,我们有两种相互竞争的盐理论.我工作的产品使用类似用户名或电话号码来加密哈希值.基本上每个用户都有不同的东西,但我们可以随时使用.另一个产品为每个用户随机生成一个salt,并在每次用户更改密码时更改.然后在数据库中加密盐.
My question is if the second approach is really necessary? I can understand from a purely theoretical perspective that it is more secure than the first approach, but what about from a practicality point of view. Right now to authenticate a user, the salt must be unencrypted and applied to the login information.
在考虑之后,我只是没有从这种方法中看到真正的安全性收益.将盐从帐户更改为帐户,即使攻击者知道如何快速确定每个帐户的内容,仍然会使某人尝试强制执行散列算法变得非常困难.这是基于密码足够强的假设.(显然,找到一组密码的正确哈希值,它们都是两位数,比找到8位密码的正确哈希值要容易得多).我的逻辑是不正确的,还是我缺少的东西?
编辑:好的,所以这就是为什么我认为加密盐真的没有意义.(lemme知道我是否在正确的轨道上).
对于以下说明,我们假设密码总是8个字符,盐是5,所有密码都由小写字母组成(它只是使数学更容易).
Having a different salt for each entry means that I can't use the same rainbow table (actually technically I could if I …
在数据库中存储密码的首选方法/数据类型是什么(最好是SQL Server 2005).我在几个应用程序中一直使用的方法是首先使用.NET加密库,然后将它们作为二进制文件存储在数据库中(16).这是首选方法还是我应该使用不同的数据类型或分配比16更多的空间?
我继承了一个Web应用程序,我刚刚在SQL Server数据库中以纯文本形式存储了超过300,000个用户名/密码.我意识到这是一件非常糟糕的事情.
知道我必须更新登录和密码更新过程以加密/解密,并且对系统其余部分的影响最小,您会建议从数据库中删除纯文本密码的最佳方法是什么?
任何帮助表示赞赏.
编辑:对不起,如果我不清楚,我打算问你的加密/哈希密码的程序,而不是特定的加密/散列方法.
我应该只是:
我想我的关注更多来自于大量的用户,所以我想确保我正确地做到这一点.
我正在编写一个小桌面应用程序,它应该能够加密数据文件并用密码保护它(即必须输入正确的密码才能解密).我希望加密数据文件是自包含和可移植的,因此必须将身份验证嵌入到文件中(或者我假设).
我有一个看似可行的策略,看起来很合理,基于我所知道的(这可能只是危险),但我不知道它是否真的是一个好的设计.那么告诉我:这是疯了吗?有更好/最好的方法吗?
基本上我是从实现网站密码的常用方法推断出来的(当你没有使用OpenID时),即在你的数据库中存储用户密码的(盐渍)哈希,而不是保存实际的密码.但由于我使用散列用户密码作为对称加密密钥,因此我无法使用相同的值进行身份验证.所以我再次哈希,基本上把它当作另一个密码处理,并将双重哈希值保存在数据文件中.这样,我可以将文件带到另一台PC,只需输入我的密码即可解密.
那么这个设计是合理安全的,还是绝望的天真,或介于两者之间?谢谢!
编辑:澄清和后续问题re:盐.
我认为盐必须保密才有用,但你的答案和链接暗示情况并非如此.例如,由erickson(下面)链接的这个规范说:
因此,这里定义的基于密码的密钥推导是密码,盐和迭代计数的函数,其中后两个量不需要保密.
这是否意味着我可以将盐值存储在与散列键相同的位置/文件中,并且仍然比在散列时根本不使用盐时更安全?这是如何运作的?
更多上下文:加密文件不是为了与他人共享或解密,它实际上是单用户数据.但是我想将它部署在我无法完全控制的计算机上的共享环境中(例如在工作中),并且能够通过简单地复制文件来迁移/移动数据(所以我可以在家里,在不同的地方使用它工作站等).
我一直在写2个cookie,1个包含用户ID,第2个包含密码的SH1哈希的1/2(盐渍).它的工作方式是不言而喻的.
我意识到我并没有以最安全的方式做到这一点.这是一个更好的方法吗?最好使用单个身份验证cookie.
还有,使用"难以计算哈希"是否有意义?我的意思是,使用bcrypt,或者用漩涡对每个项目进行散列10,000次,使其成为(相对)慢的散列函数(200 ms vs小于1 ms只是简单的SHA1)?我的意思是,如果有人违反了你的数据库并获得了哈希......那么还有什么需要保护,因为你的所有数据都在同一个数据库中(除非你有某种分散设置,我不这样做).
security ×7
hash ×6
passwords ×6
encryption ×5
cryptography ×3
php ×2
.net ×1
bcrypt ×1
brute-force ×1
c# ×1
cryptographic-hash-function ×1
database ×1
internals ×1
login ×1
protection ×1
sql-server ×1