6 Mar
2013
6 Mar
'13
9:02 p.m.
Hello fellow developers,
So as to preserve security of our users, we do one small thing: the user-name and password
(and registration info) is submitted over https. All other communication is done over
http.
This works well for someone connected normally to the internet.
This works incorrectly for someone who is forced to use a proxy by its network conditions,
e.g. hotels, wifi hotspots and mobile devices' provided networks.
The reason it is the case, it the following
MyPersistentLoginManager.checkValidation checks a "validation" cookie which
computes a salted hash of the triple username, password, and IP. And in the cases above,
the IPs are different, so the validation fails, the login is unsuccessful, the console
says:
Login cookie validation hash mismatch! Cookies have
been tampered with
What our options?
Is it true that removing IP in this validation would make the system weak as anyone
stealing the cookie from another IP could become that user?
Would it be as simple as finding the right header "chain end" and replace it?
It seems that it would be possible.
paul
27 Mar
27 Mar
6:41 p.m.
Hello Paul,
The IP is indeed used to create the validation cookie. But in order to
fix issues with proxies the IP is "guessed" thanks to the
"X-Forwarded-For"
header of the request.
But I can't tell since which version it is done this way :). So what
version of XWiki were you using when you got these issues ?
Thomas
On Wed, Mar 6, 2013 at 9:02 PM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
Hello fellow developers,
So as to preserve security of our users, we do one small thing: the
user-name and password (and registration info) is submitted over https. All
other communication is done over http.
This works well for someone connected normally to the internet.
This works incorrectly for someone who is forced to use a proxy by its
network conditions, e.g. hotels, wifi hotspots and mobile devices' provided
networks.
The reason it is the case, it the following
MyPersistentLoginManager.checkValidation checks a "validation" cookie
which computes a salted hash of the triple username, password, and IP. And
in the cases above, the IPs are different, so the validation fails, the
login is unsuccessful, the console says:
Login cookie validation hash mismatch! Cookies
have been tampered with
What our options?
Is it true that removing IP in this validation would make the system weak
as anyone stealing the cookie from another IP could become that user?
Would it be as simple as finding the right header "chain end" and replace
it?
It seems that it would be possible.
paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:18 p.m.
Thomas,
this is based on xwiki 3.5 and the code to detect proxies is there but it isn't
correct, at least for the situations we detected, where the last value in the list should
be taken, and not the first as is done currently (details on
http://jira.xwiki.org/browse/CURRIKI-5937).
Do we know the spec paragraphs about this?
I am wondering if there are other authentication methods that would not help us in such
conditions, among others that of using a (server-generated) authentication certificate.
They could be a lot sturdier than the cookies-based authentication.
Thanks for hints.
Paul
On 27 mars 2013, at 18:41, Thomas Delafosse wrote:
Hello Paul,
The IP is indeed used to create the validation cookie. But in order to
fix issues with proxies the IP is "guessed" thanks to the
"X-Forwarded-For"
header of the request.
But I can't tell since which version it is done this way :). So what
version of XWiki were you using when you got these issues ?
Thomas
On Wed, Mar 6, 2013 at 9:02 PM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
Hello fellow developers,
So as to preserve security of our users, we do one small thing: the
user-name and password (and registration info) is submitted over https. All
other communication is done over http.
This works well for someone connected normally to the internet.
This works incorrectly for someone who is forced to use a proxy by its
network conditions, e.g. hotels, wifi hotspots and mobile devices' provided
networks.
The reason it is the case, it the following
MyPersistentLoginManager.checkValidation checks a "validation" cookie
which computes a salted hash of the triple username, password, and IP. And
in the cases above, the IPs are different, so the validation fails, the
login is unsuccessful, the console says:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Login cookie validation hash mismatch! Cookies
have been tampered with
What our options?
Is it true that removing IP in this validation would make the system weak
as anyone stealing the cookie from another IP could become that user?
Would it be as simple as finding the right header "chain end" and replace
it?
It seems that it would be possible.
paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
28 Mar
28 Mar
12:31 p.m.
Hello Paul,
As you said, one quick fix would be not to use the user IP anymore for
making the validation hash. You can achieve that simply by putting
xwiki.authentication.useip to false in xwiki.cfg. This is indeed a little
less secure but if someone succeed in stealing cookies he could anyway fake
its IP address to gain access nonetheless. So in my opinion it is better to
do it this way than having a manual login page using HTTP.
But in the long run, you're right, we should probably rethink our
authentication methods, or at least propose alternatives. I'm currently
going deeper and deeper in XWiki authentication code, and I would try to
make some proposals soon.
Cheers,
Thomas
On Wed, Mar 27, 2013 at 8:18 PM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
Thomas,
this is based on xwiki 3.5 and the code to detect proxies is there but it
isn't correct, at least for the situations we detected, where the last
value in the list should be taken, and not the first as is done currently
(details on http://jira.xwiki.org/browse/CURRIKI-5937).
Do we know the spec paragraphs about this?
I am wondering if there are other authentication methods that would not
help us in such conditions, among others that of using a (server-generated)
authentication certificate. They could be a lot sturdier than the
cookies-based authentication.
Thanks for hints.
Paul
On 27 mars 2013, at 18:41, Thomas Delafosse wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hello Paul,
The IP is indeed used to create the validation cookie. But in order
to
fix issues with proxies the IP is
"guessed" thanks to the
"X-Forwarded-For"
header of the request.
But I can't tell since which version it is done this way :). So what
version of XWiki were you using when you got these issues ?
Thomas
On Wed, Mar 6, 2013 at 9:02 PM, Paul Libbrecht <paul(a)hoplahup.net>
wrote:
>
> Hello fellow developers,
>
> So as to preserve security of our users, we do one small thing: the
> user-name and password (and registration info) is submitted over https.
All
> other communication is done over http.
>
> This works well for someone connected normally to the internet.
> This works incorrectly for someone who is forced to use a proxy by its
> network conditions, e.g. hotels, wifi hotspots and mobile devices'
provided
> networks.
> The reason it is the case, it the following
>
> MyPersistentLoginManager.checkValidation checks a "validation" cookie
> which computes a salted hash of the triple username, password, and IP.
And
> in the cases above, the IPs are different, so
the validation fails, the
> login is unsuccessful, the console says:
>> Login cookie validation hash mismatch! Cookies have been tampered with
>
> What our options?
>
> Is it true that removing IP in this validation would make the system
weak
> as anyone stealing the cookie from another IP
could become that user?
>
> Would it be as simple as finding the right header "chain end" and
replace
it?
It seems that it would be possible.
paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4190
days inactive
4212
days old
3 comments
2 participants
participants (2)
-
Paul Libbrecht -
Thomas Delafosse