Re: scaling issues with security_tokens

Hi Paul!

Paul Lesniewski <[email protected]> writes:
> On Tue, Jan 24, 2012 at 1:22 PM, Micah Anderson <[email protected]> wrote:
>>
>> I am having a problem with scaling squirrelmail because of the update
>> frequency of the security_tokens. It seems as though a new
>> security_token is generated and put into the database (via a REPLACE
>> INTO userprefs) everytime a squirrelmail user does anything in
>> squirrelmail... perhaps with some exceptions (I did not look that
>> closely).
>>
>> This may not be a big deal when you only have a few users, but when you
>> have 39k users, this starts to really hammer the database. It also makes
>> replication a major pain because every single one of those userprefs
>> updates results in a query written to the binary log that then needs to
>> be replayed on the replication slave.
>>
>> I've set $max_token_age_days = 1; but that only affects how much data
>> accumulates in the security_tokens, but it doesn't affect the number of
>> updates.
>>
>> Besides turning these off, which does not seem like a good idea, could
>> there be a better way to handle these?
>
> You could turn it off and enable referrer checking.  Referrer checking
> is a good alternative safety mechanism as long as you understand that
> any users whose browsers do not send referrer information will not
> have the benefits of this security check (such users would be
> vulnerable to CSRF attacks, although it may be reasonable to argue
> that users who know enough to turn off referrer sending in their
> browsers are savvy enough to know such attacks when they see them).

Interesting. We do have referrer checking enabled, but it would be nice
to have both of these.

> Back to the security tokens, I had originally considered a
> configuration element to force the use of just a single token but
> didn't implement it at the time with the hopes that multiple tokens
> could add obscurity or at least confuse an attacker.  But I'm not
> convinced that having multiple tokens really adds concrete security,
> so I can propose the attached patch which makes SquirrelMail instead
> use just one token per user (with the option to revert to previous
> behavior by adding "$do_not_use_single_token = TRUE;" (without quotes)
> to config/config_local.php).  The single token will still rotate once
> per hour for active users, or at worst once every $max_token_age_days
> (default 2 days).
>
> See attached patch - if I can get feedback, I will add it for version 1.4.23.

We applied this patch to the version we have installed (from Debian
Squeeze), with only minor modifications to get things to line up
right. 

We did it about 5 days ago and have been monitoring the situation since,
and I am happy to say that it is completely solved our problem!  Our
disk space usage from the binary replication logs has gone away. We went
from 95% usage to 25% usage as the binary logs were rotated out
throughout the day. 

We also looked at the tokens that were added and can confirm its working
as expected with the patch. The number of token updates now is
significantly less, which has a pretty large impact on our resource
usage overall.

We did have some trouble with some users getting, 'The current page
request appears to have originated from an untrusted source.' error,
which is related to old tokens (the error message is really similar to
the one about referrer issues). We looked into the security tokens for
the users reporting the issue and they had a pretty large set, so
decided to clear out the security tokens for everyone and start things
from scratch, so we did:

update userprefs set prefval='' where prefkey='security_tokens';

which cleared things out, and then those users no longer had that issue.

So, all in all I'd vote for this patch to be included in 1.4.23!

thanks for the quick work on this!
micah


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel