[
https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501142#comment-13501142
]
Mark Struberg commented on MYFACES-3652:
----------------------------------------
a few more thoughts:
The xorshiftrandom is _only_ predictable if we serialize the _full_ long number
to the client. So lets just cut off the two least significant bytes. Or even
from somewhere in the middle. In that case we still have 48 bits random which
is good enough as the sequencer is there as well. But an attacker doesn't have
the seed and thus is not able to generate the next number.
The hit ratio would be:
1 : 2^16 * threadcount * chance_of_other_user_request_inbetween
and a new game with even better ratio on each subsequent retry.
I think even unencoded this is superior to our current sequencer + viewid_hash
+ encoding +mac.
The reason is that any encoding which only generates a low number of bytes can
be cracked. And the entropy of the encoded values is really low:
* the viewIdHash is easy to predict
* the MAC is stable
* the sequencer is easy to predict too
did I miss something?
> Define default view key algorithm
> ---------------------------------
>
> Key: MYFACES-3652
> URL: https://issues.apache.org/jira/browse/MYFACES-3652
> Project: MyFaces Core
> Issue Type: Sub-task
> Components: JSR-344
> Affects Versions: 2.2.0, 2.1.9
> Reporter: Mark Struberg
> Assignee: Mark Struberg
>
> Currently we have a few different viewkey generator implementations. Those
> got added only in 2.1.9. Before that the only had a TicketCounter in each
> Session.
> The original implementation also had no viewId in the key.
> If you think about it, then it makes no sense at all to add the viewId.
> Despite it's an int hashCode we have 2 problems which completely trashes the
> purpose:
> a.) hashCode is not guaranteed to be unique
> b.) the hashCode is always the same for the same view.
> Think about an application with only one xhtml page. In that case the viewId
> would add no additional info.
> With 4 pages you would only reduce the collision rate to over 25%. Since the
> application will most times mainly hit by a few entry points like index.html
> you gain barely anything from adding this information.
> IF we have had problems with any collisions, then we shall add an XorShift
> random generator instead of the viewId. Leo, I didn't an issue report for
> such a problem. Do you have any tip for me where I can find that?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
