I'm making an auth service so I've been looking for some good Java/Groovy implementations of password + salt hashing. I've found this article on crackstation along with a code example and decided to make it mine. First thing I noticed is SHA1 and only 1000 iterations so I changed those to SHA256 and 90510(still have to test the performance on the server and perhaps increase it to at least 100k).

One thing however kind of struck me. The result string is "[iterations]:[salt as hex]:[hash as hex]". Why are iterations added to the result? Wouldn't that be insecure? Wouldn't that be akin to giving away a piece of the key? Or am I just too paranoid.

I have removed it, but I'm wondering why is it there? What is the purpose of showing that? In case the default number of iterations changes? Should the number of iterations be randomized to a degree?

1 Answer 1


Much like the salt, the iteration count isn't expected to be kept secret from attackers. It does make the job of attackers slightly more difficult if they don't know the iteration count since that adds one piece of info they have to find elsewhere. But that generally isn't expected to be a hurdle that they are unable to overcome.

By storing the iteration value alongside the password you make it easier for the iteration count to be updated on the system while still supporting the existing passwords until they can be changed. Your password checking routine always knows the appropriate number of iterations to try when matching a password hash for each particular user. Otherwise you'd have to try to accommodate different past and current possible iteration counts within the password checking code.

Randomizing the number of iterations doesn't really add much value since attackers aren't limited to cracking tools with hardcoded iteration counts or using precomputed rainbow tables with a certain number of iterations.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .