On Mon, Feb 28, 2011 at 7:10 AM, aspineux <[email protected]> wrote:
>
> I said
>
> > TG should handle this situation !
>
> because TG found the two identities ! Look this line
>
> 23:55:25,843 DEB [auth] identities found: [(<FriendlyFormPlugin
> 156451276>, {'login': u'[email protected]', 'password':
> u'secret'}), (<AuthTktCookiePlugin 156451244>, {'tokens': [''],
> 'timestamp': 1298847304, 'repoze.who.userid':
> u'[email protected]',
> 'userdata': 'userid_type:unicode'})]
>
You're right, it found an identity. To be precise, it found the identity
that your browser was telling it existed. That your configuration was saying
should be expected (since you were using the same cookie secret and session
secret between two different instances).
In other words, it was doing exactly what it had been told to do.
Give more priority to the FriendlyFormPlugin when expected.
>
That might be one of the more flippant statements that I've heard in a long
time. You were given answers to the problem, given explanations for those
answers, were given all of the above quickly, and you're asking for more
priority?
On Mon, Feb 28, 2011 at 7:34 AM, aspineux <[email protected]> wrote:
> Anyway I'm sure it should not be too difficult to avoid this problem
> with argument I used in previous post.
>
So far as I am aware, there is no mechanism that will prevent fraudulent
cookies from being accepted when all checks on those fraudulent cookies
match what is expected.
AuthTkt actually use SHA1 sums, combined with a secret that is only supposed
to be know to the instance being run, in order to secure the cookie. When a
cookie gets sent back that actually matches all of that data, what can be
done, on a general level, to prevent accepting a still fraudulent cookie?
And yes, the cookie from the wrong instance is, in fact, a fraudulent
cookie. It had sufficient information in it to get past the blocks that were
put up, even though it should not have gotten past them.
So, give me something. Hell, I'll settle for a link to a theoretical
research paper that tangentially references a possible solution using
experimental hardware only available to the NSA.
Right now, all I've got is someone saying "It should be easy! Go do it!"
That's not exactly a great way to get me interested in "fixing" something
that, from everything I can tell, is not actually a problem.
Yes, I said it: Not actually a problem. I gave two ways that would have
prevented it (the secrets and not using production for dev). Nil gave a
third that I didn't even consider. Until I've got something more to work
with, I'm going to have to decline to work on this further.
--
Michael J. Pedersen
My IM IDs: Jabber/[email protected], ICQ/103345809, AIM/pedermj022171
Yahoo/pedermj2002, MSN/[email protected]
--
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en.
