On Mon, Dec 22, 2008 at 12:14 PM, Eduard Moraru <[email protected]>wrote:
> Yes, but in both cases the security issue would be for someone to sniff > the network. > In this situation, both methods fail to provide security: > HTTP Auth: > - sniffer decodes username:password from the Base64 "Authorization: > Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" header and can authenticate whenever > he pleases. > Token: > - sniffer grabs the token and uses it himself to pose as the user. > + user can call log out and the sniffer's access will be blocked out > but the damage can already be done. > - the sniffer can catch the initial log-in which sends the GET > command with user name and password parameters which are in plain text. > + If the authentication process involves more than one step (at > least public/private keys or something stronger), the sniffer would not > be able to find the user/pass and authenticate whenever he pleases. > For sure, but it enforces the hacker to be just a bit more clever... But you're right!!! Basic and Digest authentication is a bit light :) We should do as Amazon S3 and define our own Authentication digest called AWS ;););) > > If we want good security, we need it done by an application on the > client side. > > Another idea would be to use HTTP:// for anonymous access and HTTPS:// > for authenticated access. Having HTTPS to secure the communication, the > authentication approach could be a relatively simple one(please correct > me), even token-based or basic auth. (seems curl handles HTTPS > http://curl.netmirror.org/docs/manual.html) > > We should provide a standard way accessible both to a browser and a > command-line tool like curl. > > WDYT? > Don't know if this is really needed... Currently, without REST, XWiki doesn't use HTTPS and has the same authentication risk, am I right? But if we want a strong security layer, HTTPS could be a solution... > > Pascal Voitot wrote: > > On Mon, Dec 22, 2008 at 10:56 AM, Eduard Moraru <[email protected] > >wrote: > > > > > >> Vincent Massol wrote: > >> > >>> On Dec 19, 2008, at 6:27 PM, Fabio Mancinelli wrote: > >>> > >>> > >>> > >>>> Vincent Massol wrote: > >>>> > >>>> > >>>> > >>>>> Does this mean I cannot open my browser and call the REST URL without > >>>>> specifying a user? > >>>>> > >>>>> > >>>>> > >>>> It should open up the authentication dialog where you type your > >>>> username > >>>> and password (or guest) the first time you request a resource. > >>>> > >>>> > >>> Is that right? It sounds cumbersome and bad for easy automation when > >>> you want guest access. > >>> > >>> Cannot we default to guest when no username/account is specified? > >>> > >>> Thanks > >>> -Vincent > >>> > >>> _______________________________________________ > >>> devs mailing list > >>> [email protected] > >>> http://lists.xwiki.org/mailman/listinfo/devs > >>> > >>> > >> +1 > >> > >> > > > > User as a resource seems quite logical... this is the same point of view > as > > OpenID... > > > > > > > >> I think it would be easier and more natural to have the default to guest > >> or anonymous user. > >> When an anonymous user tries to access restricted content -> 403 > >> If he wants to log-in, he just does: > >> http://user:[email protected]/space/X/page/Y > >> > >> > > > > for security issues, passing the user/password for each request is really > > not very good... I really prefer the authentication token approach... > > > > > > > >> We should mimic the basic auth and skip the pop`ul window that requires > >> user/pass in the browser. > >> > >> That is: Imply that the current user is exactly who he says he is and do > >> not assume he could be a user with rights to a resource until he > >> explicitly says so. > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > >> > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
