>密码必须至少为8个字符,并且至少包含一个大写和小写字母,数字和符号.
>密码不能包含用户名作为其子字符串.
>用户名,salted哈希(使用SHA2)存储在db上的密码.
> nonce(salt)对于每个用户是唯一的,并且以明文形式存储,以及用户名和密码.
>整个登录过程只能通过TLS进行
您如何评估以下措施的有效性来提高安全性？
>增加密码长度
>强制用户每X个时间段更改密码,新密码不能是以前任何一个以前的密码
>将随机数大小从32字节增加到64字节(删除为无用)
>使用AES加密盐,密钥仅适用于进行身份验证的应用程序
>重复密码多次
>使用盐,它是db上更长的应用范围的盐独特用户盐的组合.
我不喜欢1和2,因为它可能会给用户带来不便.
4和6当然只有当攻击者破坏了数据库(例如：通过sql注入)而不是应用程序所在的文件系统时才有效.
解决方法
3 Increase nonce size from 32 bytes to 64 bytes
4 Encrypt the salt using AES,with the key available only to the application doing authentication
5 Rehash the password multiple times
这些步骤仅影响密码文件(DB列)对攻击者被盗并可见的情况.这个随机数只能击败前面的哈希(彩虹表),但这还是一件好事,应该保留下来.
(再次,假设你试图最小化受影响的数据库的影响.)加密随机数意味着攻击者有一个额外的强力的步骤,但是你没有说明存储该随机数的加密密钥的位置.假设如果数据库受到威胁,那么这个随机数将是明文或简单的解密,这可能是安全的.所以,攻击者的努力再次是对每个散列的强力.
Rehashing只是使得暴力攻击需要更长时间,但可能不会更多,取决于您对潜在攻击者的裂缝/秒的假设.
无论您的密码组合要求如何,用户仍然可以创建符合规则的“更可猜测”密码,如“P @ ssw0rd”.所以,在任何情况下,暴力都有可能在一些用户群体中取得成功. (我的意思是强调采取措施来防止泄露密码.)
密码存储方案在防范披露方面听起来不错.我会确保认证过程的其他部分也是安全的(速率限制登录尝试,密码到期,sql注入对策,难以预测的会话令牌等),而不是过度设计这部分.
