On 6/6/11 12:52 AM, Les Hazlewood wrote:
> Hi Mária,
>
> Actually BCrypt isn't preferred/recommended:  Apache Shiro's default
> Hash implementations are as secure as BCrypt as long as you're using a
> reasonably secure hashing algorithm (e.g. SHA-256) and a sufficiently
> high number of iterations.  I covered this briefly in a blog article
> that may be of help:
> http://www.katasoft.com/blog/2011/04/04/strong-password-hashing-apache-shiro
>
> I really created SHIRO-290 as a placeholder, but I'm fairly certain
> it's not worth our time to implement it, given that Shiro Hashes are
> already as secure as BCrypt because we've always supported an
> iterations component.
>
> Also note that the jBCrypt [1] implementation that could have been
> used as a code seed does not appear to implement the Blowfish
> algorithm correctly.  I've read the Niels/Provos paper and viewed the
> jBCrypt source and noticed that the code does not match the math.  (I
> can't remember off of the top of my head but I believe the feistel
> transformation function was incorrect).
>
> Summary: There is no published evidence that BCrypt is more
> cryptographically secure than Shiro's recommended mechanism (e.g.
> SHA-256 or SHA-512 and a high # of iterations), so we probably don't
> need to go through the effort of implementing BCrypt as a new Hash
> implementation.

Thanks for the background and (for me at least) education on this. 
The performance engineer in me shudders at the implications of the
recommended strategy, though.  Your post is careful to point out the
need to tune for load, etc.; but slowing down logons via cpu
spinning is a terrible thing to do to web applications that
experience any kind of load.  I wonder if there is a way to have
just one of these two evils - either cpu drain or connection /
throughput drag.  IIUC the problem the slowing is trying to solve,
that could be accomplished by forcing some kind of time dependency
in the hashing algorithm itself without cpu drain.  Is that possible
somehow?

Phil
> [1] http://www.mindrot.org/projects/jBCrypt/
>
> HTH,
>

Reply via email to