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? > >> 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. > > 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. >> 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
