提高基于Web的登录的安全性

Question

现在我的登录系统如下:

1. 密码长度必须至少为8个字符,并且至少包含一个大写和小写字母,一个数字和一个符号.
2. 密码不能包含用户名作为其子字符串.
3. 用户名,salted +哈希(使用SHA2)密码存储在db上.
4. nonce(salt)对每个用户都是唯一的,并以用户名和密码的形式存储为明文.
5. 整个登录过程只能通过TLS进行

您如何评价以下措施的有效性以提高安全性？

1. 增加密码长度
2. 强制用户每X隔一段时间更改密码,新密码不能是Y以前的任何密码
3. 将随机数大小从32字节增加到64字节 (删除无用)
4. 使用AES加密salt,密钥仅供执行身份验证的应用程序使用
5. 多次重新密码密码
6. 在db上使用一个盐,它是一个较长的应用程序范围的盐+唯一用户盐的组合.

我不是很喜欢1和2,因为它会给用户带来不便.
当然,只有当攻击者破坏了db(例如:通过SQL注入)而不是应用程序所在的文件系统时,4和6才有效.

Answer 1

答案可能在某种程度上取决于网站,用户和攻击者的性质.例如,它是哪种网站可以将破解者定位到特定帐户(可能是"管理员"帐户),还是只是想要获得尽可能多的帐户？用户的技术程度如何以及他们保持自己帐户安全的动机如何？在不知道答案的情况下,我会假设他们不是技术性的而且没有动力.

可能有所作为的措施

5)多次重新密码.这可以显着减缓所有暴力攻击 - 哈希1000次,暴力攻击变慢1000次.

4)使用AES加密盐,密钥只能用于进行身份验证的应用程序如何才能使其仅供应用程序使用？它必须存储在某个地方,如果应用程序受到攻击,攻击者可以获得它.可能会有一些攻击直接针对数据库,这会产生影响,所以我不会称之为无用,但这可能不值得.如果您确实付出了努力,您也可以加密密码本身以及数据库中的任何其他敏感数据.

6)在db上使用一种盐,它是较长的应用程序范围的盐+唯一用户盐的组合.如果你只关心密码那么是,这将是一个更好的方法来实现与4)相同的结果,当然,它很容易实现.

措施无效

3)将随机数大小从32字节增加到64字节. 计算彩虹表对于任何盐都已经完全不切实际了,所以如果攻击者不知道盐,这只会产生影响.但是,如果他们可以获得哈希密码,他们也可以得到盐.

无效和恼人的措施

1)增加密码长度增加密码长度超过8将不会对蛮力时间产生实际影响.

2)强制用户更改我同意的密码,这将始终可以解决.事实上,它可能会使网站安全性降低,因为人们会在某处写下密码!

Answer 2

3 将随机数大小从 32 字节增加到 64 字节
4 使用 AES 加密盐，密钥仅可供执行身份验证的应用程序使用
5 多次重新哈希密码

这些步骤仅影响密码文件（数据库列）被盗且攻击者可见的情况。随机数只会击败预哈希（彩虹表），但这仍然是一件好事，应该保留。

（同样，假设您试图最大程度地减少受损数据库的影响。）加密随机数意味着攻击者有额外的暴力步骤，但您没有说明随机数的加密密钥存储在哪里。可以安全地假设，如果数据库受到损害，随机数将是明文或简单解密。因此，攻击者的努力再次对每个哈希进行暴力破解。

重新哈希只会使暴力攻击花费更长的时间，但可能不会更长，具体取决于您对潜在攻击者每秒的破解次数的假设。

无论您的密码组成要求如何，用户仍然可以创建符合规则的“更容易猜测”的密码，例如“P@ssw0rd”。因此，无论如何，对于某些用户群体来说，暴力破解很可能会成功。（我的意思是强调采取措施防止密码泄露。）

密码存储方案在防止泄露方面听起来相当不错。我会确保身份验证过程的其他部分也是安全的（限制登录尝试的速率、密码过期、SQL 注入对策、难以预测的会话令牌等），而不是过度设计这部分。