shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Berry <tae...@gmail.com>
Subject Re: Shiro Auth On REST API Killing CPU
Date Thu, 07 Nov 2013 20:08:02 GMT
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 <saad.mufti@gmail.com> 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.
>

Mime
View raw message