You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by saadmufti <sa...@gmail.com> on 2013/11/07 19:42:23 UTC
Shiro Auth On REST API Killing CPU
Hi,
I'm running a REST API on a quad-core CPU box and when I turn on Shiro
authentication, the CPU's get maxed out pretty quickly. The main load is
calls to the API /v1/selection as can be seen in the [urls] section below.
Turn auth off and CPU utilization is very small. Reading through
documentation, I thought turning on authentication caching was the key, but
I have tried both the built in EhCacheManager and
MeoryConstrainedCacheManager but it hasn't made any difference. I would
appreciate any feedback, here is my shiro.ini file:
[main]
passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
;cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
iniRealm.credentialsMatcher = $passwordMatcher
iniRealm.authenticationCachingEnabled = true
; TODO - enable ssl filter for real deployment
ssl.enabled = false
[users]
admin =
$shiro1$SHA-256$500000$o51Hv+79zLxE02waEHUCAg==$AE6rpoSmI1DmI0KTL0EUt/vU0IkhXCh3l0/8hN5Epvc=,
admin
BeOn =
$shiro1$SHA-256$500000$yM3AZt2x3Ak0rKY+DGJSBA==$jqW+7W3wYd4LVcN9zFA5B40ElLsN/C1TKPXXH38SvRQ=,
BeOn_update, BeOn_read
[roles]
admin = *
aolupdate =
selection:aol:update,collection:aol:update,partition:aol:update,promotion:aol:update,algorithm:aol:update
aolread =
selection:aol:read,collection:aol:read,partition:aol:read,promotion:aol:read,algorithm:read,algorithm:aol:read
BeOn_update =
selection:BeOn:update,collection:BeOn:update,partition:BeOn:update,promotion:BeOn:update,algorithm:BeOn:update
BeOn_read =
selection:BeOn:read,collection:BeOn:read,partition:BeOn:read,promotion:BeOn:read,algorithm:read,algorithm:BeOn:read
[urls]
/v1/collection = ssl, noSessionCreation, authcBasic
/v1/collection/ = ssl, noSessionCreation, authcBasic
/v1/partition = ssl, noSessionCreation, authcBasic
/v1/partition/ = ssl, noSessionCreation, authcBasic
/v1/algorithm_config = ssl, noSessionCreation, authcBasic, rest[algorithm]
/v1/algorithm_config/* = ssl, noSessionCreation, authcBasic, rest[algorithm]
/v1/algorithm_config/*/ = ssl, noSessionCreation, authcBasic,
rest[algorithm]
/v1/algorithm_config/*/BeOn/** = ssl, noSessionCreation, authcBasic,
rest[algorithm:BeOn]
/v1/selection/BeOn/** = ssl, noSessionCreation, authcBasic,
rest[selection:BeOn]
/v1/collection/BeOn/** = ssl, noSessionCreation, authcBasic,
rest[collection:BeOn]
Thanks in advance for any help and/or insight.
----
Saad
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro Auth On REST API Killing CPU
Posted by Danilo Reinert <da...@gmail.com>.
Saad, after reading this (great!) article, I found the best alternative to
use API keys instead of username/password pairs.
>From the article:
"Best practices say to encrypt your passwords in the database to limit a
potential data breach. This increases overhead for each request when
authenticating a user. Unique API keys authentication skips the hashing
step and therefore speeds up your calls. If you want to know more about
storing passwords".
--
D. Reinert
On Fri, Nov 8, 2013 at 12:55 PM, saadmufti <sa...@gmail.com> wrote:
> I agree with Josh that sounds reasonable. And really, if the data and
> changes
> you're exposing via your API require more stringent security, you shouldn't
> be using HTTP-Basic as your auth scheme anyway. Probably something like
> OAuth or some custom signing scheme. See long discussion at
> http://www.stormpath.com/blog/secure-your-rest-api-right-way .
>
> Thanks for the enlightening discussion guys.
>
> ----
> Saad
>
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579359.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Shiro Auth On REST API Killing CPU
Posted by saadmufti <sa...@gmail.com>.
I agree with Josh that sounds reasonable. And really, if the data and changes
you're exposing via your API require more stringent security, you shouldn't
be using HTTP-Basic as your auth scheme anyway. Probably something like
OAuth or some custom signing scheme. See long discussion at
http://www.stormpath.com/blog/secure-your-rest-api-right-way .
Thanks for the enlightening discussion guys.
----
Saad
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579359.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro Auth On REST API Killing CPU
Posted by Josh Berry <ta...@gmail.com>.
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 <da...@gmail.com>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 <da...@gmail.com>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 <sa...@gmail.com> 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.
>>>
>>
>>
>
Re: Shiro Auth On REST API Killing CPU
Posted by Danilo Reinert <da...@gmail.com>.
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 <da...@gmail.com>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 <sa...@gmail.com> 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.
>>
>
>
Re: Shiro Auth On REST API Killing CPU
Posted by Danilo Reinert <da...@gmail.com>.
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 <sa...@gmail.com> 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.
>
Re: Shiro Auth On REST API Killing CPU
Posted by saadmufti <sa...@gmail.com>.
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.
Re: Shiro Auth On REST API Killing CPU
Posted by Danilo Reinert <da...@gmail.com>.
You can use Shiro's support to Cache for storing authentication and
authorization information. It can be enabled besides the use of session.
Using some CacheManager will prevent your application to execute the
authentication logic for every request.
I've developed the architecture of a JAX-RS project disabling Session and
enabling Cache and it worked just fine. I was using Bcrypt too and I had
configured for 100k iterations.
Shiro has a default implementation of CacheManager using EhCache,
EhCacheManager. I've used it.
You can find everything on Shiro's documentation about how to enable Cache
and how to disable Session.
--
D. Reinert
On Fri, Nov 8, 2013 at 12:57 AM, Josh Berry <ta...@gmail.com> wrote:
> Is there an easy way to do that outside of just enabling short lived
> sessions and not putting anything in them? (That is, only use them to
> store a validated user?)
>
>
> On Thu, Nov 7, 2013 at 9:30 PM, Jared Bunting <jared.bunting@peachjean.com
> > wrote:
>
>> I believe that the common way for REST APIs to address this is to use
>> short-lived auth tokens. This basically gives you the same thing as the
>> sessions without the "stateful" part of sessions.
>> On Nov 7, 2013 6:23 PM, "Josh Berry" <ta...@gmail.com> wrote:
>>
>>> One real quick suggestion, if you can, go ahead and enable sessions. I
>>> believe that gets you basically what you want. When the user is
>>> successfully authenticated, from that point on you will actually be relying
>>> on the session cookie instead of the authentication cookie. If the
>>> "session" is ever not found, you then create a new one and authenticate it.
>>>
>>> I realize this breaks the "stateless rest" backend, and I have far from
>>> thought it through. Just an idea that occurred to me as being rather easy
>>> to get running.
>>>
>>>
>>> On Thu, Nov 7, 2013 at 6:08 PM, Josh Berry <ta...@gmail.com> wrote:
>>>
>>>> To be fair, more iterations is a good idea. I'll try and take a look
>>>> this evening and see if i can figure something out.
>>>> On Nov 7, 2013 4:04 PM, "saadmufti" <sa...@gmail.com> wrote:
>>>>
>>>>> Yes, I tried that and that worked!!! So you were right. Also stepped
>>>>> throught
>>>>> the code and verified:
>>>>>
>>>>> 1) the authentication info getting cached is the hashed version
>>>>> 2) all the caching is saving is getting the info from disk, it is still
>>>>> hashing the passed in auth info all over again to compare to the info
>>>>> it
>>>>> gets from the cache
>>>>>
>>>>> So yes reducing the number of iterations immensely speeds this up, I
>>>>> vaguely
>>>>> remember now that I used 500000 a couple of months ago after reading
>>>>> some
>>>>> blog post that recommended upping the iterations for more security.
>>>>> Shows
>>>>> you the perils of following advice without completely understanding.
>>>>>
>>>>> What would be ideal would be if the caching would work like how you
>>>>> suggested, that is it would cache the plaintext after comparing and
>>>>> use that
>>>>> for the future as long as the cache entry existed. But right now it
>>>>> does the
>>>>> opposite, it caches the hashed info and hashes the plaintext
>>>>> username/password passed in and then does the comparison.
>>>>>
>>>>> Any quick ideas on how to tweak this to do what you suggested?
>>>>> Prefereably
>>>>> not involving heavy duty subclassing etc. :-)
>>>>>
>>>>> Thanks for all your help.
>>>>>
>>>>> ----
>>>>> Saad
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579346.html
>>>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>>>
>>>>
>>>
>
Re: Shiro Auth On REST API Killing CPU
Posted by Josh Berry <ta...@gmail.com>.
Is there an easy way to do that outside of just enabling short lived
sessions and not putting anything in them? (That is, only use them to
store a validated user?)
On Thu, Nov 7, 2013 at 9:30 PM, Jared Bunting
<ja...@peachjean.com>wrote:
> I believe that the common way for REST APIs to address this is to use
> short-lived auth tokens. This basically gives you the same thing as the
> sessions without the "stateful" part of sessions.
> On Nov 7, 2013 6:23 PM, "Josh Berry" <ta...@gmail.com> wrote:
>
>> One real quick suggestion, if you can, go ahead and enable sessions. I
>> believe that gets you basically what you want. When the user is
>> successfully authenticated, from that point on you will actually be relying
>> on the session cookie instead of the authentication cookie. If the
>> "session" is ever not found, you then create a new one and authenticate it.
>>
>> I realize this breaks the "stateless rest" backend, and I have far from
>> thought it through. Just an idea that occurred to me as being rather easy
>> to get running.
>>
>>
>> On Thu, Nov 7, 2013 at 6:08 PM, Josh Berry <ta...@gmail.com> wrote:
>>
>>> To be fair, more iterations is a good idea. I'll try and take a look
>>> this evening and see if i can figure something out.
>>> On Nov 7, 2013 4:04 PM, "saadmufti" <sa...@gmail.com> wrote:
>>>
>>>> Yes, I tried that and that worked!!! So you were right. Also stepped
>>>> throught
>>>> the code and verified:
>>>>
>>>> 1) the authentication info getting cached is the hashed version
>>>> 2) all the caching is saving is getting the info from disk, it is still
>>>> hashing the passed in auth info all over again to compare to the info it
>>>> gets from the cache
>>>>
>>>> So yes reducing the number of iterations immensely speeds this up, I
>>>> vaguely
>>>> remember now that I used 500000 a couple of months ago after reading
>>>> some
>>>> blog post that recommended upping the iterations for more security.
>>>> Shows
>>>> you the perils of following advice without completely understanding.
>>>>
>>>> What would be ideal would be if the caching would work like how you
>>>> suggested, that is it would cache the plaintext after comparing and use
>>>> that
>>>> for the future as long as the cache entry existed. But right now it
>>>> does the
>>>> opposite, it caches the hashed info and hashes the plaintext
>>>> username/password passed in and then does the comparison.
>>>>
>>>> Any quick ideas on how to tweak this to do what you suggested?
>>>> Prefereably
>>>> not involving heavy duty subclassing etc. :-)
>>>>
>>>> Thanks for all your help.
>>>>
>>>> ----
>>>> Saad
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579346.html
>>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>>
>>>
>>
Re: Shiro Auth On REST API Killing CPU
Posted by Jared Bunting <ja...@peachjean.com>.
I believe that the common way for REST APIs to address this is to use
short-lived auth tokens. This basically gives you the same thing as the
sessions without the "stateful" part of sessions.
On Nov 7, 2013 6:23 PM, "Josh Berry" <ta...@gmail.com> wrote:
> One real quick suggestion, if you can, go ahead and enable sessions. I
> believe that gets you basically what you want. When the user is
> successfully authenticated, from that point on you will actually be relying
> on the session cookie instead of the authentication cookie. If the
> "session" is ever not found, you then create a new one and authenticate it.
>
> I realize this breaks the "stateless rest" backend, and I have far from
> thought it through. Just an idea that occurred to me as being rather easy
> to get running.
>
>
> On Thu, Nov 7, 2013 at 6:08 PM, Josh Berry <ta...@gmail.com> wrote:
>
>> To be fair, more iterations is a good idea. I'll try and take a look this
>> evening and see if i can figure something out.
>> On Nov 7, 2013 4:04 PM, "saadmufti" <sa...@gmail.com> wrote:
>>
>>> Yes, I tried that and that worked!!! So you were right. Also stepped
>>> throught
>>> the code and verified:
>>>
>>> 1) the authentication info getting cached is the hashed version
>>> 2) all the caching is saving is getting the info from disk, it is still
>>> hashing the passed in auth info all over again to compare to the info it
>>> gets from the cache
>>>
>>> So yes reducing the number of iterations immensely speeds this up, I
>>> vaguely
>>> remember now that I used 500000 a couple of months ago after reading some
>>> blog post that recommended upping the iterations for more security. Shows
>>> you the perils of following advice without completely understanding.
>>>
>>> What would be ideal would be if the caching would work like how you
>>> suggested, that is it would cache the plaintext after comparing and use
>>> that
>>> for the future as long as the cache entry existed. But right now it does
>>> the
>>> opposite, it caches the hashed info and hashes the plaintext
>>> username/password passed in and then does the comparison.
>>>
>>> Any quick ideas on how to tweak this to do what you suggested?
>>> Prefereably
>>> not involving heavy duty subclassing etc. :-)
>>>
>>> Thanks for all your help.
>>>
>>> ----
>>> Saad
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579346.html
>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>
>
Re: Shiro Auth On REST API Killing CPU
Posted by Josh Berry <ta...@gmail.com>.
One real quick suggestion, if you can, go ahead and enable sessions. I
believe that gets you basically what you want. When the user is
successfully authenticated, from that point on you will actually be relying
on the session cookie instead of the authentication cookie. If the
"session" is ever not found, you then create a new one and authenticate it.
I realize this breaks the "stateless rest" backend, and I have far from
thought it through. Just an idea that occurred to me as being rather easy
to get running.
On Thu, Nov 7, 2013 at 6:08 PM, Josh Berry <ta...@gmail.com> wrote:
> To be fair, more iterations is a good idea. I'll try and take a look this
> evening and see if i can figure something out.
> On Nov 7, 2013 4:04 PM, "saadmufti" <sa...@gmail.com> wrote:
>
>> Yes, I tried that and that worked!!! So you were right. Also stepped
>> throught
>> the code and verified:
>>
>> 1) the authentication info getting cached is the hashed version
>> 2) all the caching is saving is getting the info from disk, it is still
>> hashing the passed in auth info all over again to compare to the info it
>> gets from the cache
>>
>> So yes reducing the number of iterations immensely speeds this up, I
>> vaguely
>> remember now that I used 500000 a couple of months ago after reading some
>> blog post that recommended upping the iterations for more security. Shows
>> you the perils of following advice without completely understanding.
>>
>> What would be ideal would be if the caching would work like how you
>> suggested, that is it would cache the plaintext after comparing and use
>> that
>> for the future as long as the cache entry existed. But right now it does
>> the
>> opposite, it caches the hashed info and hashes the plaintext
>> username/password passed in and then does the comparison.
>>
>> Any quick ideas on how to tweak this to do what you suggested? Prefereably
>> not involving heavy duty subclassing etc. :-)
>>
>> Thanks for all your help.
>>
>> ----
>> Saad
>>
>>
>>
>> --
>> View this message in context:
>> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579346.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
Re: Shiro Auth On REST API Killing CPU
Posted by Josh Berry <ta...@gmail.com>.
To be fair, more iterations is a good idea. I'll try and take a look this
evening and see if i can figure something out.
On Nov 7, 2013 4:04 PM, "saadmufti" <sa...@gmail.com> wrote:
> Yes, I tried that and that worked!!! So you were right. Also stepped
> throught
> the code and verified:
>
> 1) the authentication info getting cached is the hashed version
> 2) all the caching is saving is getting the info from disk, it is still
> hashing the passed in auth info all over again to compare to the info it
> gets from the cache
>
> So yes reducing the number of iterations immensely speeds this up, I
> vaguely
> remember now that I used 500000 a couple of months ago after reading some
> blog post that recommended upping the iterations for more security. Shows
> you the perils of following advice without completely understanding.
>
> What would be ideal would be if the caching would work like how you
> suggested, that is it would cache the plaintext after comparing and use
> that
> for the future as long as the cache entry existed. But right now it does
> the
> opposite, it caches the hashed info and hashes the plaintext
> username/password passed in and then does the comparison.
>
> Any quick ideas on how to tweak this to do what you suggested? Prefereably
> not involving heavy duty subclassing etc. :-)
>
> Thanks for all your help.
>
> ----
> Saad
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579346.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Shiro Auth On REST API Killing CPU
Posted by saadmufti <sa...@gmail.com>.
Yes, I tried that and that worked!!! So you were right. Also stepped throught
the code and verified:
1) the authentication info getting cached is the hashed version
2) all the caching is saving is getting the info from disk, it is still
hashing the passed in auth info all over again to compare to the info it
gets from the cache
So yes reducing the number of iterations immensely speeds this up, I vaguely
remember now that I used 500000 a couple of months ago after reading some
blog post that recommended upping the iterations for more security. Shows
you the perils of following advice without completely understanding.
What would be ideal would be if the caching would work like how you
suggested, that is it would cache the plaintext after comparing and use that
for the future as long as the cache entry existed. But right now it does the
opposite, it caches the hashed info and hashes the plaintext
username/password passed in and then does the comparison.
Any quick ideas on how to tweak this to do what you suggested? Prefereably
not involving heavy duty subclassing etc. :-)
Thanks for all your help.
----
Saad
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579346.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro Auth On REST API Killing CPU
Posted by Josh Berry <ta...@gmail.com>.
Even quicker than stepping through the code would be to simply set one of
the passwords to only have one interation. I'm assuming you used the
command line tool to make those passwords, `-i 1` will accomplish this.
On Thu, Nov 7, 2013 at 3:19 PM, saadmufti <sa...@gmail.com> wrote:
> Thanks for the feedback. I cloned the whole Shiro git repository into my
> workspace and will be exploring these ideas by stepping into the Shiro
> code.
>
> ----
> Saad
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579344.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Shiro Auth On REST API Killing CPU
Posted by saadmufti <sa...@gmail.com>.
Thanks for the feedback. I cloned the whole Shiro git repository into my
workspace and will be exploring these ideas by stepping into the Shiro code.
----
Saad
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579344.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shiro Auth On REST API Killing CPU
Posted by Josh Berry <ta...@gmail.com>.
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 <sa...@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.
>
Re: Shiro Auth On REST API Killing CPU
Posted by saadmufti <sa...@gmail.com>.
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.
Re: Shiro Auth On REST API Killing CPU
Posted by Josh Berry <ta...@gmail.com>.
Just stabbing in the dark, but my hunch would be that you will want to find
some way to keep from having to do 500000 iterations of the hash on every
request. Going by the comments on AuthenticatingRealm[1], it might be
worth looking at the second scenario in the Authentication Caching
section. A scheme I would think is to ultimately store the passwords as
the highly hashed versions, but somehow keep a plaintext in the cache,
where you know the cache will never spill out to anywhere else. (Or,
alternatively, a slightly less hashed version.)
Before trying anything complicated, I would make passwords that are not as
highly iterated in the hashing to see if that ramps you back down in the
cpu usage. Otherwise, everything I just said is pointless. :)
[1]
http://shiro.apache.org/static/current/apidocs/org/apache/shiro/realm/AuthenticatingRealm.html
On Thu, Nov 7, 2013 at 1:42 PM, saadmufti <sa...@gmail.com> wrote:
> Hi,
>
> I'm running a REST API on a quad-core CPU box and when I turn on Shiro
> authentication, the CPU's get maxed out pretty quickly. The main load is
> calls to the API /v1/selection as can be seen in the [urls] section below.
> Turn auth off and CPU utilization is very small. Reading through
> documentation, I thought turning on authentication caching was the key, but
> I have tried both the built in EhCacheManager and
> MeoryConstrainedCacheManager but it hasn't made any difference. I would
> appreciate any feedback, here is my shiro.ini file:
>
> [main]
> passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
> ;cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
> cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
> securityManager.cacheManager = $cacheManager
> iniRealm.credentialsMatcher = $passwordMatcher
> iniRealm.authenticationCachingEnabled = true
> ; TODO - enable ssl filter for real deployment
> ssl.enabled = false
>
> [users]
> admin =
>
> $shiro1$SHA-256$500000$o51Hv+79zLxE02waEHUCAg==$AE6rpoSmI1DmI0KTL0EUt/vU0IkhXCh3l0/8hN5Epvc=,
> admin
> BeOn =
>
> $shiro1$SHA-256$500000$yM3AZt2x3Ak0rKY+DGJSBA==$jqW+7W3wYd4LVcN9zFA5B40ElLsN/C1TKPXXH38SvRQ=,
> BeOn_update, BeOn_read
>
> [roles]
> admin = *
> aolupdate =
>
> selection:aol:update,collection:aol:update,partition:aol:update,promotion:aol:update,algorithm:aol:update
> aolread =
>
> selection:aol:read,collection:aol:read,partition:aol:read,promotion:aol:read,algorithm:read,algorithm:aol:read
> BeOn_update =
>
> selection:BeOn:update,collection:BeOn:update,partition:BeOn:update,promotion:BeOn:update,algorithm:BeOn:update
> BeOn_read =
>
> selection:BeOn:read,collection:BeOn:read,partition:BeOn:read,promotion:BeOn:read,algorithm:read,algorithm:BeOn:read
>
> [urls]
> /v1/collection = ssl, noSessionCreation, authcBasic
> /v1/collection/ = ssl, noSessionCreation, authcBasic
> /v1/partition = ssl, noSessionCreation, authcBasic
> /v1/partition/ = ssl, noSessionCreation, authcBasic
> /v1/algorithm_config = ssl, noSessionCreation, authcBasic, rest[algorithm]
> /v1/algorithm_config/* = ssl, noSessionCreation, authcBasic,
> rest[algorithm]
> /v1/algorithm_config/*/ = ssl, noSessionCreation, authcBasic,
> rest[algorithm]
> /v1/algorithm_config/*/BeOn/** = ssl, noSessionCreation, authcBasic,
> rest[algorithm:BeOn]
> /v1/selection/BeOn/** = ssl, noSessionCreation, authcBasic,
> rest[selection:BeOn]
> /v1/collection/BeOn/** = ssl, noSessionCreation, authcBasic,
> rest[collection:BeOn]
>
> Thanks in advance for any help and/or insight.
>
> ----
> Saad
>
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>