I also recommend you reevaluate your configured iterations. Bcrypt is about finding the perfect balance between security and performance. 200k is a initial shot recommended in this article<http://www.stormpath.com/blog/strong-password-hashing-apache-shiro>. For me, 100k was giving me a satisfactory performance, with a way better security than conventional encrypt algorithms.
Any thoughts on this topic, I'm interested on listening. -- D. Reinert On Fri, Nov 8, 2013 at 10:43 AM, Danilo Reinert <[email protected]>wrote: > Saad, you're right. Shiro caches AuthenticationInfo having the credentials > hashed. Then it is required hashing (over configured iterations) the token > sent via request in order to match with the hashed AuthenticationInfo. > > I can't say to you right now if this approach is right or wrong. But it > seems that the hashing phase is required in a stateless application, after > all, it would not be secure. > > -- > D. Reinert > > > On Fri, Nov 8, 2013 at 10:16 AM, saadmufti <[email protected]> wrote: > >> Hmm, I stepped into the code after disabling sessions and enabling >> MemoryConstrainedCacheManager (also tried EhCacheManager), and it looked >> to >> me like the obfuscated authentication info was getting cached, so Shiro >> was >> still having to execute its hashing scheme with 500,000 iterations on the >> password in every incoming request. But you seem to be saying that with >> caching turned on, it should only need to do the hashing once (before the >> info was cached). That is not what I was seeing. In my case even after >> turning caching on all I was saving was the lookup of the stored >> authentication info, I wasn't saving anything on the computation of the >> obfuscated form of the incoming password. >> >> ---- >> Saad >> >> >> >> >> -- >> View this message in context: >> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579355.html >> Sent from the Shiro User mailing list archive at Nabble.com. >> > >
