// Get a 32 character salt like '69Mt6nexL1rsjWnu011S53MpB/WmT4Vl'
$passwordSalt = Security::generateBase64Salt();
$user = new User();
$user->setUsername($_POST['username']);
// $_POST['password'] comes in as a 128 character string
// Client side javascript is used to sha512 the string before sending it over POST
// see http://pajhome.org.uk/crypt/md5/
// This prevents novice eavesdroppers from capturing the raw password in plaintext
$user->setPassword(
hash('sha512',$passwordSalt.$_POST['password'])
);
$user->setPasswordSalt($passwordSalt);
$user->save();
这是特定密码的数据库条目：
密码：
69a78a7586a111b8a567b2d4f42f93f01fb59d337f7fa3c35949a66b246095778c1fa01ff4026abace476091e1e9a183bbdec1c31b12ce3f786921895c98cf6f
盐：
69Mt6nexL1rsjWnu011S53MpB / WmT4Vl
问题：
>这个算法有继承缺陷吗？
>将盐存储在与salt密码哈希相同的数据库和表中是否可以？
>如果表中有几十万用户,是否会有一个128字符的大密码导致登录性能问题(大小为几秒)？
>这些数据可以反转以生成原始密码吗？
为了娱乐：
如果您能使用salt和salt密码哈希向我提供原始密码,我将PayPal为5美元.
它不受彩虹攻击(由于随机盐). Sha512是一个相当新的算法,但目前没有已知的碰撞,所以它可能非常安全.存储密码的方式很好.检查过程也很重要(速率限制暴力攻击)并锁定服务器免受可能试图访问数据库的其他角度的攻击.如果攻击者能够访问数据库,他可能会很快提取出简单的密码,但任何复杂的密码都可能超出简单的暴力攻击(即使他可以直接访问哈希).
是否可以将salt存储在与salt密码哈希相同的数据库和表中？
如果你想能够验证密码(我假设你想要),你几乎必须将它们存储在一起.腌制密码的主要原因是消除彩虹攻击的可能性.通常,这些数据甚至与散列密码存储在同一列中,使用符号将它们分开.
如果表中有几十万用户,那么拥有一个128字符的大密码会导致登录性能问题(数秒级)吗？
基准测试密码需要多长时间(以秒为单位)(哈希(‘sha512’,$salt.$password_attempt)).找到该数字的倒数,这可能接近每cpu核心每秒可以处理的密码尝试次数.
这些数据可以反转以生成原始密码吗？
是的,但这需要很多努力,因为你使用随机盐,彩虹表将不再工作,并且sha512需要相当数量的cpu来运行并且没有已知的冲突.如果密码相当简单,可能会猜到.如果你担心扭转哈希值,那么对密码的复杂性设置一个低限可能是一个好主意(根据字典检查它,它是否包含上/下/数字/符号).
