That is why I was saying to just generate some passwords that are less hashed, I'm pretty much just guessing at the moment. :) However, if you reduce the iterations down to 1 for a quick test, you'll know that is indeed where the CPU is spending its time.
To elaborate a little, my understanding is that the credentials for a user are the $shiro1...$ items. When it gets those, it knows it has to do a hash from the plaintext the user sent to validate against the credentials. What I don't know, but would be more than willing to help with, is how one would make it so that on a non-cached query, it gets the $shiro1..$ item and performs a full check against what is stored and *then* caches the plaintext. That is, the trick seems to be that you would only want to cache *after* a successful authentication. And, of course, there is a large chance I'm just flat out wrong here, and you are supposed to do this a different way. :) On Thu, Nov 7, 2013 at 2:45 PM, saadmufti <[email protected]> wrote: > This sounds promising, definitely caching would be kind of pointless if it > were still doing the full 500000 iterations of a hash before every hash > lookup. But I am lost on two points: > > a) does the default IniRealm class return plaintext or obfuscated > authentication info > b) how does the caching mechanism decide whether to do the full hashing on > the incoming tokens before looking up in the cache > > Any idea? > > ---- > Saad > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579342.html > Sent from the Shiro User mailing list archive at Nabble.com. >
