[
https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501388#comment-13501388
]
Leonardo Uribe commented on MYFACES-3652:
-----------------------------------------
MS>> I did a quick test and while the SessionIdGenerator from tomcat creates a
much more unpredictable
MS>> value it is also much slower than XorShiftRandom. And currently we encrypt
that as well, so this looks
MS>> a bit like an overkill to me.
Encryption is handled using another flags, so the suggested way is disable
encryption if SecureRandom is used. Yes, it is overkill to use both, just one
is enough.
LU>> - the viewId hashcode protects against use one valid key for one view in
other view,
MS>> But an attacker can easily disable this vector by using the same view for
the hack. So this information is not of stellar use in practice.
No, because the viewId goes also in request path, and you compare that value
with the encoded value. Note encryption + mac protects against generate a mac
for a message, so even if you know the next number in the counter and the
target viewId, you can't guess the mac value (without do unfeasible ammounts of
computations). That's why it works, and the same reasoning applies for use the
full viewId.
I agree with you that a random number as a secret instead the viewId hashCode
is preferred.
I would say that encryption must be enabled by default, and the user should
decide if he/she disables it or not.
I like the idea of trim part of the random key to make it more difficult to
guess the sequence. The question is how far should we go in this purpose to
consider an generation of random numbers "safe" for our algorithm. I'm not sure
how to decide that (that's the reason why I prefer encryption+mac enabled by
default, because the computational complexity has been previously studied, and
we know it is a safe way).
> 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
