Re:Enough with the Salts: Updates on Secure Password Schemes
by emn13 on Wednesday April 01, 2015 @05:22PM
(#9307005)
Yeah - brute forcing is really only a relevant attack if the number of possibilities is fairly limited (even with a really fast hash). Scrypt output is likely to be effectively random (if salted) - and without salt, you'd need to build an expensive (but potentially feasible) rainbow table of possible scrypt output.
[ Parent
| on HN ]
Re:Enough with the Salts: Updates on Secure Password Schemes
by ademarre on Wednesday April 01, 2015 @06:00PM
(#9307245)
> you'd need to build an expensive (but potentially feasible) rainbow table of possible scrypt output
I don't think that's feasible. "Expensive" is an understatement. To compute the rainbow table you need to do the work of actually calculating the scrypt output for each password, even though you don't have to store it. The space is just too big, therefore the time cost.
Re:Enough with the Salts: Updates on Secure Password Schemes
by emn13 on Wednesday April 01, 2015 @06:46PM
(#9307509)
It's a question of size - clearly a rainbow table of 1 is feasible. I'm guessing a rainbow table of a million won't be too expensive either, and with a million common passwords, you'd likely crack something.
But yeah, it's not likely to be a major threat. In any case, salting makes it irrelevant.
Re:Enough with the Salts: Updates on Secure Password Schemes
by ademarre on Wednesday April 01, 2015 @07:04PM
(#9307603)
Is scrypt even implemented without a salt? If not, then it doesn't matter. And if so, why?
Re:Enough with the Salts: Updates on Secure Password Schemes
by emn13 on Thursday April 02, 2015 @03:01AM
(#9309033)
Good point - it is implemented with a salt! However, the way that's done depends on the implemetation. The underlying KDF doesn't require nor generate a salt, so if you're implementing it client side, you'd need to ensure salting works.