On Mon, Dec 22, 2008 at 2:50 PM, Sergiu Dumitriu <[email protected]> wrote:
> Pascal Voitot wrote: > > 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. > >> > > Any HTTP authentication method is either not generic enough, or not safe > enough. The only solution is to use HTTPS. > - Digest auth requires that we store passwords in plaintext > - Basic auth and URL auth have no protection at all > - Cookie auth requires that the user/pass are sent at least once to the > server > - Client side encryption requires the use of a graphical browser, and > enabled javascript > > HTTPS is safe enough to make any of the above methods also safe. > > > 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 ;););) > > How do we make clients understand this? Javascript-powered browsers can > emulate this authentication method, but what about lynx and wget? > I was joking :) Basic auth will be good enough :) > > > > >> 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? > > +1 for Basic auth over HTTPS, or cookies over HTTPS. Basic auth should > be used by non-interactive clients (command line tools), since in a > browser it is hard to "logout". Cookies should be used for interactive > tools, which can keep an internal state. > +1 for this... > > > > > 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... > > No web application has safe authentication without HTTPS. > and even HTTPS can be attacked :) > > >> 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? > >>>>> > >>>>> > >>>> +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. > > GET (or POST) /authToken?user=..&pass=.. -> sets a cookie (deleting all > previous values set) > DELETE /authToken -> deletes the cookie > > The semantics seem correct IMO. You GET a token, this has the most > correct meaning. But since GET is defined as a simple resource > retrieval, and here we do a lot of processing behind the scenes, a POST > might be better suited (you send some parameters and expect a result > from the server). > > DELETE also is meaningful. We don't delete a resource with the same > value as a document or object. The difference is that this resource is > not stored on the server, but on the client. However, it is used on the > server, thus it is a correct computational resource that the server > sees, and which it can also DELETE. > > Now, since DELETE is not easy to access from all clients, to delete a > token without using a DELETE request, a client can simply POST or GET > the authToken without specifying user/pass, or using empty values for > them. By the mechanics of cookies, if the server sends an expired cookie > (i.e. an invalid token, or an invalidating token), it will be deleted > from the client. > > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
