The problem with looking at recommendations for number of iterations to run is that of age, I would think. Consider, that 200k recommendation is upwards of 3 years old now. This is one of the reasons it is really good to store the number of iterations used in what you store off, so that you have a good migration plan to increase the count later without having the user change their password. (Though, I suppose this is really a fringe benefit. Password change policies probably hit often enough to not require this.)
I do think using a "session" to get users through with a basic auth token sounds straight forward and easy enough. I suppose it is bad in that you are down to discipline to make sure nothing else is put "in session." So long as you make your sessions expire rather quickly, it basically is a caching system for authenticated clients. With the bonus of not worrying about the plain text passwords spilling to a disk store somewhere. Right? -josh On Fri, Nov 8, 2013 at 8:49 AM, Danilo Reinert <[email protected]>wrote: > 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. >>> >> >> >
